Why do cloud customers still need their own controls even when the provider has a SOC 2 report?

Why This Matters for Security Teams

A SOC 2 report is useful, but it is not a blanket security warranty for a cloud customer’s environment. The report usually describes the provider’s control design and operating effectiveness for a defined scope, period, and set of services. It does not automatically cover customer-side identity design, data classification, workload hardening, key management, logging choices, or incident response readiness. That distinction matters because cloud risk is shaped by how services are configured and consumed, not only by the provider’s baseline.

Security teams often overread assurance language and assume that third-party validation reduces their own control burden. Current guidance from the ENISA Threat Landscape and cloud security practice both point to the same reality: shared responsibility creates shared exposure, and misconfiguration remains a common failure mode. A provider can attest to operating a secure platform while a customer still exposes sensitive data through broad access, weak secrets handling, or absent monitoring. That is why due diligence and control ownership have to extend beyond the audit report itself. In practice, many security teams encounter real exposure only after a configuration drift, identity misuse, or unmonitored data path has already been exploited, rather than through intentional assurance review.

How It Works in Practice

Cloud assurance works best when the SOC 2 report is treated as one input into a wider control model. The provider’s report can help validate the trustworthiness of the service, but the customer still needs controls that fit the specific deployment, data sensitivity, and threat model. In other words, the report supports vendor selection and ongoing oversight, while the customer’s own program must cover implementation and runtime security.

For most organisations, that means translating the provider’s attestation into customer-owned safeguards such as:

• Identity and access management with least privilege, strong authentication, and regular entitlement review
• Encryption design, including key ownership decisions and secure key rotation
• Logging, alerting, and retention policies that allow meaningful detection and investigation
• Workload hardening, patching, and secure configuration baselines
• Incident response procedures that define who investigates, contains, and notifies

Practitioners should also check the scope of the SOC 2 report carefully. It may cover only certain services, regions, or corporate controls, and it may exclude customer-managed configurations altogether. A strong operating model maps each provider control claim to a customer control dependency, then assigns an owner for evidence collection and continuous monitoring. For cloud-native environments, this often pairs with NIST CSF-style governance and detection discipline, and with attack-pattern awareness from MITRE ATT&CK so that teams can test whether the environment would actually detect abuse of valid accounts, exposed secrets, or privilege escalation paths. These controls tend to break down when customers assume inherited assurance covers unmanaged identities, cross-account access, or custom integrations because those areas sit outside the provider’s tested scope.

Common Variations and Edge Cases

Tighter control ownership often increases operational overhead, requiring organisations to balance assurance value against the effort of maintaining their own evidence, policies, and technical guardrails. That tradeoff becomes sharper in highly automated cloud estates, multi-account architectures, and shared platform teams where responsibility boundaries are easy to blur.

There is no universal standard for this yet across every cloud model, so guidance should be adapted to the service type. A SaaS customer may have limited infrastructure controls but still own identity governance, data retention, and user access reviews. A PaaS or IaaS customer usually carries far more responsibility for network segmentation, workload security, and logging. For regulated environments, mapping customer controls to frameworks such as CSA MAESTRO or cloud security control catalogs helps clarify what is inherited and what is not. The practical test is simple: if the customer can change it, consume it, or expose it through configuration, then the customer must control it. That includes non-human identities, API keys, and automation accounts, which are often forgotten until a review, audit, or incident exposes them. Strong providers reduce risk, but they do not remove the need for disciplined customer-side governance.

Related resources from NHI Mgmt Group

• Who is accountable for Google Workspace SOC 2 controls when Google already has its own SOC 2 report?
• How should security teams handle onboarding when customers bring their own identity provider?
• Why do backups still fail during cloud outages even when the data is intact?
• Why do role-based access controls still leave governance gaps in cloud environments?