What is the difference between a cloud provider SOC 2 report and an organisation’s SOC 2 audit evidence?

A provider report documents the controls the cloud service operator runs for its own environment. An organisation’s audit evidence shows how it secures the systems, identities, data, and processes it controls within that cloud. The first supports due diligence and control inheritance. The second proves the customer has implemented the safeguards required for its own SOC 2 scope.

Why This Matters for Security Teams

The difference between a cloud provider SOC 2 report and an organisation’s own SOC 2 evidence is not just administrative. It determines what can actually be inherited, what must be proven locally, and where accountability sits when auditors ask hard questions. A provider report may support vendor due diligence, but it does not replace evidence for identity governance, configuration control, logging, incident response, or data handling inside the customer’s scope. That distinction maps closely to the control ownership model described in the NIST Cybersecurity Framework 2.0.

Security teams often get caught by assuming the cloud operator’s attestation covers shared-responsibility obligations. It rarely does. A cloud SOC 2 report can indicate that the provider has an acceptable control environment, but the customer still needs evidence that access reviews were performed, secrets were protected, workloads were configured securely, and monitoring was active across its own tenancy. For SOC 2, auditors care about how controls operate in practice, not only whether a supplier claims to have controls somewhere upstream.

In practice, many security teams encounter this gap only after an auditor requests tenant-specific evidence rather than through intentional control design.

How It Works in Practice

Cloud provider SOC 2 reports are typically used as third-party assurance artifacts. They help a customer understand whether the provider’s infrastructure, operations, and support processes meet the relevant trust criteria. That is useful, but it is only the starting point. The customer must still produce audit evidence for the systems it configures, the identities it grants, the data it stores, and the processes it runs on top of the cloud service.

Operationally, this means separating inherited controls from customer-controlled controls. Inherited controls may include physical security, baseline platform resilience, or some aspects of hypervisor management. Customer-owned evidence usually includes IAM reviews, PAM records, change approvals, secure configuration baselines, vulnerability remediation, backup testing, alerting, and incident handling. Where secrets are involved, auditors often expect proof that credentials, tokens, and API keys are inventoried, rotated, and restricted to the minimum required scope. The control model should also be aligned to the organisation’s own risk framework and the applicable NIST SP 800-53 Rev 5 Security and Privacy Controls catalogue, even if the organisation is not formally certified against it.

• Use the provider SOC 2 report to validate the shared-responsibility boundary, not to close your own audit population.
• Map each SOC 2 trust criterion to evidence owned by the provider, the customer, or both.
• Keep tenant-specific artifacts such as access reviews, logging screenshots, tickets, and exception approvals.
• Document how compensating controls work when a cloud service limits native reporting or control depth.

Security leaders should also account for the threat environment the cloud service sits in. Industry reporting such as the ENISA Threat Landscape remains useful for understanding the attack patterns that drive evidence expectations around identity abuse, misconfiguration, and detection coverage. These controls tend to break down when an organisation uses managed cloud services with sparse tenant-level telemetry because evidence cannot be reconstructed after the fact.

Common Variations and Edge Cases

Tighter audit evidence collection often increases operational overhead, requiring organisations to balance faster attestation reuse against the burden of proving control operation for every in-scope environment. Best practice is evolving here, especially where cloud marketplaces, SaaS layers, and outsourced security operations blur the boundary between provider and customer responsibility.

Some environments allow substantial control inheritance, while others require almost complete customer evidence because the organisation configures the service in a highly autonomous way. The distinction becomes especially important when the service handles regulated data, supports privileged administrative access, or sits inside a multi-account cloud estate with different business units and control owners. There is no universal standard for how much provider evidence is enough on its own. Auditors usually expect the customer to show how the provider report was assessed, what was relied upon, and what gaps were covered with local controls.

The most common failure mode is treating a SOC 2 report as a substitute for internal control operation. That is usually visible in areas such as joiner-mover-leaver reviews, MFA enforcement, workload logging, and exception management. In identity-heavy environments, the provider may secure the platform, but the organisation still has to prove that its own users, service accounts, and non-human identities are governed appropriately.

Related resources from NHI Mgmt Group

• What is the difference between Microsoft’s SOC 2 report and a tenant’s SOC 2 evidence in Microsoft 365?
• What is the difference between session logging and audit-ready evidence?
• What is the difference between shipping a proof of concept and operationalising a cloud provider check?
• What is the difference between a clean SOC 2 report and a qualified report?