In the cloud your provider secures the infrastructure and you secure what you put on it - and almost every publicised "cloud breach" happens on the customer side of that line. Understanding the shared responsibility model is the difference between assuming you are covered and knowing what you must actually control.
Who is responsible for what
The boundary shifts with the service model:
- Infrastructure as a Service (IaaS). The provider secures physical facilities, hardware and the hypervisor. You secure operating systems, patching, network configuration, identity, application code and data.
- Platform as a Service (PaaS). The provider adds the runtime and middleware. You still own identity, application logic, configuration and data.
- Software as a Service (SaaS). The provider runs almost everything. You still own your users, your permissions, your data classification, your sharing settings and your integrations - which is precisely where SaaS incidents occur.
In every model, identity and data remain your responsibility. A certified provider does not certify your configuration of it.
Why provider certifications do not transfer
Your provider's ISO 27001 certificate or SOC 2 report covers their controls. Two consequences follow:
- You must still implement and evidence your own controls for your workloads.
- Provider assurance reports include complementary user entity controls - an explicit list of things the report assumes you do. Most customers never read that section, and auditors increasingly ask about it.
The misconfigurations that cause most incidents
- Storage buckets or blobs exposed publicly.
- Over-permissive identity roles - wildcard permissions and long-lived keys.
- Management consoles or databases reachable from the internet.
- Logging disabled, or logs never reviewed.
- Encryption not enabled, or keys managed poorly.
- Unused regions and orphaned resources nobody monitors.
- Secrets committed to source code repositories.
None of these are provider failures. All of them are detectable automatically - which is why cloud posture belongs in continuous monitoring rather than an annual review.
Prove your side of the shared responsibility line
GRC Copilot connects to your cloud accounts, checks configuration against the controls your frameworks require, and keeps the evidence current across CSA CCM, NCA CCC, ISO 27001 and more.
Try GRC Copilot free Generate an AI-powered assessment Download checklist Book a demo
Cloud-specific frameworks worth knowing
- CSA Cloud Controls Matrix (CCM) - a cloud-specific control set, with the CAIQ questionnaire aligned to it. Widely used in vendor due diligence.
- NCA Cloud Cybersecurity Controls (CCC) - Saudi Arabia's cloud-specific controls, distinguishing responsibilities of cloud service providers and tenants.
- ISO/IEC 27017 and 27018 - cloud security and cloud privacy guidance extending ISO 27001.
- C5 and EUCS - German and European cloud assurance schemes.
Data residency and sovereignty
Where data physically sits increasingly determines whether you are compliant. Confirm and document:
- Which regions store your primary data - and your backups and replicas, which are often overlooked.
- Whether support staff access data from other jurisdictions.
- The transfer mechanism if data leaves a regulated region.
- What your regulator requires - several sectors and countries mandate in-country hosting for certain data.
Frequently asked questions
Does using AWS, Azure or Google Cloud make us compliant?
No. It gives you a compliant foundation. Your configuration, identity management, data handling and application security remain entirely your responsibility and are what auditors test.
What are complementary user entity controls?
They are the controls a provider's SOC 2 report assumes you operate on your side - for example, managing your own user access. If you do not perform them, the provider's assurance does not cover the gap.
How often should we review cloud configuration?
Continuously. Cloud environments change daily, so periodic manual reviews will always lag. Automated posture checks with alerting are the practical approach.
Is multi-cloud harder to govern?
Yes - each provider has different services, terminology and controls. Map to a common control framework such as the CSA CCM so you assess once and apply it consistently across providers.
Key takeaways
- Identity and data are always your responsibility, in every service model.
- Provider certifications do not transfer to your workloads.
- Read the complementary user entity controls in provider reports.
- Cloud configuration changes daily - monitor it continuously, not annually.