Customer responsibility covers the policies, procedures, configurations, and operational activities that the organisation itself must implement to meet compliance requirements. In cloud compliance programmes, this includes the parts of identity governance, monitoring, training, and response that cannot be delegated away.
Expanded Definition
Customer responsibility is the portion of a shared responsibility model that remains with the organisation when a third party, cloud provider, or platform vendor supplies the underlying service. It includes security policies, identity governance, logging, configuration hardening, data handling, and response actions that the customer must still own.
In practice, the term is most useful when the boundaries are explicit: some controls are inherited from the provider, some are shared, and some sit entirely with the customer. That distinction matters in cloud compliance, where teams sometimes assume a managed service automatically satisfies NIST SP 800-53 Rev 5 Security and Privacy Controls obligations. The same issue appears in identity and NHI programs, where customer-owned processes still govern secret rotation, access review, offboarding, and monitoring even when the platform provides tools.
Definitions vary across vendors on where “shared” ends and “customer” begins, so the safest interpretation is contractual plus operational: if the organisation can configure, approve, monitor, or revoke it, that responsibility has not been delegated away. The most common misapplication is treating provider documentation as proof of compliance, which occurs when teams fail to map controls to actual ownership boundaries.
Examples and Use Cases
Implementing customer responsibility rigorously often introduces administrative overhead, requiring organisations to weigh compliance assurance against the cost of continuous control ownership.
- In a cloud migration, the provider secures the infrastructure, while the customer configures identity policies, MFA enforcement, and alert routing for privileged actions.
- For NHI governance, the platform may offer secret storage, but the customer still owns rotation schedules, access reviews, and removal of stale API keys, a gap highlighted in NHIMG’s Ultimate Guide to NHIs.
- In a regulated SaaS deployment, the vendor may provide logs, yet the customer must decide what is retained, who can access it, and how quickly suspicious events are investigated.
- During incident response, the provider may restore service availability, but the customer remains responsible for internal triage, evidence preservation, and notifying affected stakeholders.
- For compliance attestations, teams often map inherited and customer-owned controls against NIST SP 800-53 Rev 5 Security and Privacy Controls to avoid assuming a feature equals a control.
Why It Matters for Security Teams
Customer responsibility is where many compliance failures become visible because teams discover too late that a control was never actually owned. NHIMG reports that only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer rotate them consistently, which shows how quickly “shared” security becomes customer debt when operational ownership is unclear. In NHI-heavy environments, that debt is especially dangerous because service accounts, API keys, and other secrets often survive long after the system that created them should have been retired.
This concept matters to security teams because it shapes control design, audit evidence, and incident readiness. If the customer cannot prove ownership of monitoring, key rotation, and access reviews, then the presence of a managed platform does not reduce risk in any meaningful way. The governance lesson is simple: compliance is not outsourced just because infrastructure is. Organisations typically encounter the consequences only after an audit exception, a secrets leak, or a compromised account reveals that the customer side of the shared responsibility model was never operationally enforced.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC, PR.AA | CSF defines governance and access control ownership in shared responsibility settings. |
| NIST SP 800-53 Rev 5 | CA-2, CM-6, IA-2 | Control families clarify assessment, configuration, and authentication duties that remain with the customer. |
| OWASP Non-Human Identity Top 10 | NHI guidance centers on customer-owned lifecycle, secret handling, and revocation responsibilities. |
Map each inherited service to customer-run assessments, hardened configurations, and strong authentication.
