Deployment Model

The deployment model is the operating location and ownership structure of a platform, such as SaaS, on-prem, air-gapped, or hybrid. It determines where data is processed, who administers the environment, and how much control the customer retains over access, logging, and recovery.

Expanded Definition

A deployment model describes where a platform runs, who operates it, and how responsibility is split between the customer and the provider. In security terms, it is not just a hosting label. It is a control boundary that shapes data residency, administrative privilege, logging access, backup ownership, incident response reach, and the practical limits of investigation.

The main patterns are straightforward: SaaS places most operational control with the provider; on-premises keeps control closer to the customer; air-gapped or isolated deployments constrain connectivity; hybrid models divide processing and administration across environments. The common misunderstanding is to treat these as equivalent technical choices. They are not. A deployment model can change whether a team can inspect logs directly, rotate credentials quickly, or recover data without waiting on a third party.

For security and identity teams, the boundary is often more important than the label. A “private” deployment may still rely on provider-managed tooling, while a “customer-hosted” environment may still send telemetry outward. That distinction matters when reviewing access paths, retention, and support obligations.

Examples and Use Cases

Deployment models show up in day-to-day architecture decisions, procurement reviews, and control design. The same application can create very different operational realities depending on where it runs and who holds administrative authority.

• A SaaS collaboration tool centralises patching and availability management with the vendor, but the customer may still need to govern tenant access, export permissions, and retention settings.
• An on-prem analytics platform gives the customer direct control over system administration, local logging, and backup recovery, but also makes patching and resilience a local responsibility.
• An air-gapped environment reduces external connectivity and can narrow attack paths, but it increases operational dependence on manual transfer, offline recovery, and tightly controlled maintenance windows.
• A hybrid deployment may keep sensitive records in one environment while sending workload orchestration or identity events to another, creating split ownership and more complex incident scoping.
• A private cloud can look like on-premises from a governance angle, yet still depend on shared infrastructure controls that affect visibility and recovery.

The main trade-off is control versus operational simplicity. More customer control usually means more security responsibility, especially for logging, backup validation, and access governance.

Security Implications

The security impact of a deployment model is easiest to see when something goes wrong. If the customer does not control the platform, it may not control the evidence needed to investigate suspicious activity. If the platform is highly isolated, it may be harder to patch quickly, restore services, or move logs and backups when an incident occurs. Those are not abstract concerns. They shape whether an organisation can detect abuse, prove what happened, and recover with confidence.

A poor fit between deployment model and data sensitivity can also create governance gaps. For example, a team may assume that because a workload is “in the cloud” it inherits strong logging, resilience, and segregation by default. In practice, those protections depend on configuration, contract terms, and shared responsibility. The observable symptoms are usually familiar: incomplete logs, slow access approvals, unclear support boundaries, or recovery steps that depend on a third party.

For identity-heavy systems, the deployment model can also determine where machine credentials live, who can rotate them, and how quickly compromised access can be revoked. That is especially important when administrative and operational roles are split across organisations.

Domain and Governance Relevance

Deployment model is a governance concept as much as a technical one. It defines the decision space for ownership, evidence, and assurance. In practice, the model shapes who is accountable for access control, who can audit the environment, and who must prove that logging, backup, and recovery controls actually work.

This matters directly in identity and NHI environments because the location of a workload often determines where service accounts, API keys, certificates, and other secrets are administered. A hosted model may simplify operations but reduce direct visibility into how non-human identities are created, stored, or revoked. A customer-controlled model can improve assurance, but it also places the burden of lifecycle discipline on the organisation itself.

For NHIMG, the key governance question is whether the deployment model preserves enough authority over identity, telemetry, and recovery for the organisation to meet its risk tolerance. The right model is the one that aligns operational control with the sensitivity of the data and the trust required for automated access.

Related resources from NHI Mgmt Group

• How should security teams evaluate a partner-led identity deployment model?
• Should AI model safety scores be used as the main approval criterion for deployment?
• How should security teams validate AI model files before deployment?
• What breaks when training data is poisoned before model deployment?