An inherited control is a security requirement that the customer satisfies by relying on controls already implemented by the cloud provider. The customer still has to document the inheritance, understand its scope, and prove that the control applies to the system boundary being assessed.
Expanded Definition
An inherited control is a requirement that the customer does not implement directly, but instead relies on a cloud provider, platform operator, or shared-service owner to satisfy it within a defined boundary. In practice, the control only counts if the shared responsibility model is explicit, the scope is documented, and the customer can show that the inherited safeguard covers the assessed asset or workload. That makes inherited controls a governance concept as much as a technical one, especially in cloud and SaaS audits where boundary clarity matters. The NIST Cybersecurity Framework 2.0 is useful here because it frames outcomes around governance, risk ownership, and control assurance rather than assuming a single implementation model. Definitions vary across vendors, but the core idea is consistent: the control exists outside the customer’s direct administration, yet still contributes to the customer’s compliance or risk posture. The most common misapplication is treating a provider attestation as automatic coverage, which occurs when teams fail to verify that the inherited control actually applies to the specific service, region, tenant, or configuration under assessment.
Examples and Use Cases
Implementing inherited controls rigorously often introduces evidence-management overhead, requiring organisations to weigh audit efficiency against the cost of documenting scope, exceptions, and residual risk.
- A SaaS buyer relies on the provider’s encryption at rest, but must still record which data classes and tenant boundaries are covered by that assurance.
- A cloud workload inherits physical security, data-centre access monitoring, and some environmental controls from the hyperscaler, while the customer retains responsibility for identity, configuration, and data handling.
- A regulated team maps shared logging and availability controls to an inherited control register, then validates that the provider’s commitments match the contract and assurance reports.
- An NHI-heavy application inherits platform authentication protections, but still needs the customer to document service account ownership, secret storage, and revocation procedures. That distinction is central to the governance guidance in Ultimate Guide to NHIs — Standards.
- A third-party assessment accepts the provider’s backup and disaster recovery controls only after reviewing the shared responsibility matrix and confirming the customer’s recovery objectives align with the service contract.
For organisations building cloud control libraries, inherited controls are often the difference between duplicating provider safeguards and focusing internal effort on what only the customer can manage. The NIST guidance on control outcomes supports that separation of duties, and the NHIMG research shows why it matters: Ultimate Guide to NHIs — Standards notes that 92% of organisations expose NHIs to third parties, which makes inherited trust assumptions especially sensitive when service accounts or API keys cross vendor boundaries.
Why It Matters for Security Teams
Security teams depend on inherited controls to avoid redundant implementation, but they also become exposed when ownership is vague or documentation is stale. If a provider’s assurance is overstated, the customer may mistakenly exclude critical risks from the scope of review, especially for identity, logging, and network protections in multi-tenant environments. That is where inherited controls intersect directly with NHI governance: service accounts, API keys, and other machine identities often operate across provider-managed and customer-managed layers, so control inheritance must be proven rather than assumed. NHIMG research highlights the scale of the problem, including that only 5.7% of organisations have full visibility into their service accounts, which makes inherited responsibility even harder to verify in practice. In mature governance programs, the real task is not just trusting the provider, but proving which outcomes are inherited, which are shared, and which remain customer obligations. Organisations typically encounter control gaps only after an audit finding, incident review, or contract dispute, at which point inherited control becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OV-01 | Governance and oversight require clear control ownership and assurance boundaries. |
| NIST SP 800-53 Rev 5 | CA-3 | Control assessments and interconnections depend on validating inherited safeguards. |
| ISO/IEC 27001:2022 | A.5.1 | Policies must define shared responsibility and supplier control assumptions clearly. |
Document inherited control scope, ownership, and residual risk in your governance register.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
