Inherited controls
Your cloud host has a SOC 2. Here is what that buys you.
A large cloud provider's SOC 2 report is a real asset: it covers the data centres, hardware and platform you cannot audit yourself. It covers nothing you configure. This page sorts your controls into inherited, shared and yours, and shows how to use the provider's report as evidence.
Back to SOC 2 services01 · What it covers
What the provider's report actually covers
Their system, described by their management, for their services.
The provider's report describes the provider's system: the physical sites, the hardware lifecycle, the hypervisor and the managed services listed in its description. Its controls are tested against criteria it chose, for a period it chose. Your account, your network rules and your application sit outside its boundary, because the provider does not run them.
- Check the services in scope: a provider may cover hundreds of services, but not every one you use.
- Check the regions or sites in scope, if the description lists them.
- Check the period: does it overlap your own observation period?
- Check the categories: a Security-only provider report gives nothing for your Availability claims beyond Security.
03 · In your report
How the provider shows up in your own report
Usually as a carved-out subservice organization.
Your description names the provider as a subservice organization, says what it does for you, and states that its controls are excluded from the examination (the carve-out method). It then lists the Complementary Subservice Organization Controls (CSOCs): the controls your system assumes the provider runs, such as restricting physical access to its sites.
Illustrative CSOC wording
- “The hosting provider restricts physical access to data centre facilities to authorized personnel.”
- “The hosting provider monitors environmental protections (power, cooling, fire suppression) at facilities that house the system.”
- “The hosting provider securely decommissions storage media before disposal.”
04 · Evidence the review
Evidencing that you reviewed the provider's report
Carve-out moves testing out, not monitoring.
- Obtain the current report. Download it through the provider's compliance portal and record the date.
- Match scope to use. List the services you use and confirm each appears in the description.
- Read the opinion and exceptions. Note any modified opinion or test exception that touches your CSOCs.
- Cover gaps in the period. If the report period ends well before your period ends, obtain a bridge letter or the next report.
- Act on the provider's CUECs. Map each user entity control the provider assigns to its customers to a control you run.
- Sign and file. A dated review record, with reviewer and conclusion, is what the auditor samples.
Auditors commonly test this under CC9.2, the criterion on managing risks from vendors and business partners. A review done once, years ago, does not cover a current period.
05 · The provider's CUECs
The provider's CUECs are now your controls
Their report assumes you do certain things. Your auditor will ask whether you do.
Every major provider's report lists Complementary User Entity Controls (CUECs) for its customers: managing your own console users, protecting your access keys, configuring encryption, backing up data that is not backed up by default. From your side these are not optional extras. They are controls inside your boundary, and they belong in your control list with an owner and evidence.
- “The cloud is SOC 2, so we are covered”. Its report covers its layer only. Your configuration has no opinion on it until your own examination.
- Skipping the provider's CUECs. If the provider assumes you rotate keys and you don't, the inherited assurance has a hole.
- Reviewing an out-of-date report. A report whose period ended long before yours offers little for your period.
Sources: AICPA description criteria DC section 200 (subservice organizations and complementary controls); AICPA Trust Services Criteria TSP section 100, CC9.2; AICPA Guide, SOC 2 Reporting on an Examination of Controls at a Service Organization.
Questions about inheriting from your host
Can we attach our cloud provider's report to a security review instead of our own?
As a supplement, not a substitute.
It tells the buyer the infrastructure layer is examined. It says nothing about your access, code, data handling or monitoring, which is what the buyer is actually trusting.
We use three cloud providers. Do all three appear as subservice organizations?
Each one that performs part of your service, yes.
List each provider whose services support the system in scope, with its role and method. A provider used only for an internal tool outside the boundary need not appear.
What if the provider's report has an exception on a CSOC we rely on?
Assess it and record your response.
Decide whether it affects your system, add a compensating control if it does, and keep the analysis with your vendor review. Your auditor will want to see you noticed.
Does serverless reduce what we have to evidence?
It moves it, rather than removing it.
Patching and capacity move toward the provider. Identity, permissions, deployment, logging and data handling stay with you, and often become more granular.
Inherit what you can. Own the rest clearly.
We map your cloud services to inherited, shared and owned controls and set up the provider review your auditor will sample.