You inherit physical and environmental controls from a major cloud provider, share controls such as patching and configuration management, and own the controls specific to your application. To prove inheritance, cite the provider's own audit reports. Do not claim they cover anything above the infrastructure layer.
The three categories
AWS describes its model as security of the cloud versus security in the cloud. It also describes three control types:
| Type | AWS description | Example |
|---|---|---|
| Inherited | Controls a customer fully inherits | Physical and environmental controls |
| Shared | Controls that apply to both infrastructure and customer layers | Patch management, configuration management, awareness and training |
| Customer-specific | Solely the customer's responsibility based on the application | Routing or zoning data within specific security environments |
Other providers use similar ideas with their own wording. Check each provider's documentation.
How responsibility shifts with the service
AWS notes that customer responsibility depends on the services chosen. With a virtual machine service, the customer manages the guest operating system, including updates and patches, installed software and the firewall rules. With a storage or managed database service, the provider runs the platform and the customer manages data, encryption choices, classification and access permissions. When you move from one to the other, your control list changes.
Getting the provider's reports
Major providers publish compliance documents. AWS Artifact, for example, offers on-demand downloads of AWS security and compliance documents, including reports against ISO standards, PCI standards and SOC reports, and you can give them to auditors as audit artifacts. AWS also notes that customers are responsible for developing or obtaining documents that demonstrate the security and compliance of their own companies. Their report is not yours.
Steps for your evidence
- List the provider services you use.
- For each, mark controls as inherited, shared or yours.
- Download the provider's current reports and note the report period.
- In your narratives, state which controls rely on the provider and cite the report.
- For shared controls, write what you do, such as OS patching on virtual machines, with your own evidence.
- Review the reports' own notes on what customers must do, often called complementary controls.
- Re-download when new reports are issued and record the date.
What not to claim
- Do not say "we are covered by the provider's certification". The provider's reports describe the provider's scope.
- Do not rely on a report whose period or services do not match what you use.
- Do not skip the customer side. Misconfigured storage permissions are your control, not theirs.
Pitfalls for engineering leads
Teams often list the provider as a vendor and stop. Auditors expect to see both the vendor review, with reports read and noted, and evidence of your own configuration choices. Assign an owner to check provider reports at least annually.
Quick check
Does the provider's SOC report cover my application?
No. It covers the provider's services and scope. Your application controls need your own evidence.
Where do I get the reports?
From the provider's compliance portal. AWS Artifact is one example. Access terms vary.
Safeguard asset discovery and compliance and evidence automation help show which of your own controls and assets sit on top of the provider. Try a free scan.
Sources
Last reviewed: 19 October 2026.
