Around 94% of enterprises now run at least some workloads in the cloud, yet a large share of compliance failures still trace back to one simple misunderstanding: teams assume the provider’s certificate covers their data. It doesn’t.
Quick Answer: What is cloud compliance?
Cloud compliance is the practice of meeting laws, regulations, industry standards, and contractual obligations when data and workloads run on cloud infrastructure. In plain terms, it means proving that both your cloud provider and your own configuration choices satisfy the rules that apply to your data, and it plays out in contracts, control configurations, audit evidence, and continuous monitoring. (NIST SP 800-145: The NIST Definition of Cloud Computing)
It is broader than “the provider is certified.” A provider may hold an ISO certificate or a government authorization that covers only specific services or regions, leaving your custom workloads outside that scope. Frameworks like FedRAMP, ISO/IEC 27017, GDPR, HIPAA, and PCI DSS each define different obligations, and a single cloud environment often has to satisfy several at once.
Before acting, check the provider’s certification scope statement, the shared responsibility split for each service you use, your data residency requirements, your sector-specific rules, your logging and evidence-retention setup, and your contract’s breach-notification terms.
Why cloud compliance is harder than it sounds
On-premises compliance was mostly about physical control. You owned the building, the server, the network cable. In the cloud, that certainty dissolves. A database can be spun up in another region in minutes, a developer can misconfigure a storage bucket in seconds, and the evidence auditors want lives across two organizations at once.
The core difficulty is the shared responsibility model. Cloud providers secure the cloud itself: physical facilities, hardware, and the underlying network. Customers secure what they put in the cloud: identities, data, configurations, and access policies. That split shifts depending on whether you use infrastructure, platform, or software services. With infrastructure, you carry most of the operational burden. With software, the provider carries more, but you still own your users and data.
That is why the same certified provider can sit inside a fully compliant architecture and a badly non-compliant one. The certificate is the floor, not the ceiling.
The frameworks that actually show up in audits
Cloud compliance is not one rulebook. It is a stack of overlapping obligations. Here are the ones that appear most often in real audits.
| Framework | What it covers | Who it applies to |
|---|---|---|
| GDPR | Processing of EU personal data, including in cloud systems | Any organization handling EU residents’ data |
| HIPAA Security Rule | Protected health information | Healthcare covered entities and their business associates, including cloud vendors |
| PCI DSS | Cardholder data environments | Anyone storing, processing, or transmitting card data |
| ISO/IEC 27017 | Cloud-specific security controls | Organizations extending ISO 27001 to cloud services |
| ISO/IEC 27018 | Protection of personally identifiable information in public clouds | Cloud providers acting as PII processors |
| FedRAMP | Standardized security assessment for U.S. federal cloud use | Cloud providers selling to federal agencies |
| CSA STAR | Cloud assurance registry combining self-assessment and third-party audit | Cloud providers and their customers |
A few details matter here. ISO/IEC 27017 was published in 2015 and adds cloud-specific guidance on top of the general ISO/IEC 27002 controls. ISO/IEC 27018, published in 2014, focuses specifically on protecting personally identifiable information when a public cloud acts as a PII processor. FedRAMP was established in 2011, and the FedRAMP Authorization Act became law in December 2022, giving the program a statutory footing. PCI DSS v4.0 was published in March 2022, with future-dated requirements becoming mandatory on 31 March 2025.
The GDPR took effect on 25 May 2018 and governs processing of EU personal data. Notably, it never uses the word “cloud.” It applies to processing, wherever that processing happens. That is a useful mental model: most regulations regulate data and outcomes, not technology.
What cloud compliance looks like in practice
Compliance is not a document you file once. It is a set of habits that produce evidence continuously. In practice, healthy cloud compliance programs tend to share a handful of traits.
They start from data, not tools. Before anyone picks a framework, the team maps what data exists, where it lives, who can reach it, and which rules attach to it. A customer list with EU addresses triggers different obligations than anonymized analytics events. Skipping this step is the single most common mistake: teams buy a compliance tool, run a scan, and discover they cannot interpret the results because nobody defined the data classes.
They read the scope statement. A provider’s certification almost always lists which services, regions, and features are covered. Teams that assume “our provider is FedRAMP authorized, so we are covered” get surprised during audits. Check the scope, then check whether the specific service you use appears in it.
They treat configuration as a control. Public storage buckets, over-permissive identity roles, disabled logging, and unencrypted backups cause a large share of real incidents. Automated configuration scanning catches these before an auditor does. If you want a clearer picture of how storage choices affect control and risk, this breakdown of cloud storage vs local storage key differences is a useful starting point.
They keep evidence as they go. Screenshots taken the week before an audit are weak evidence. Logs, change tickets, access reviews, and policy acknowledgments collected continuously are strong evidence. Build the paper trail into normal operations rather than reconstructing it later.
They assign ownership. Compliance without a named owner drifts. Someone needs to own the control library, someone needs to own the technical implementation, and someone needs to sign off on exceptions.
How the major providers differ
The three hyperscalers all offer extensive compliance programs, but the emphasis differs.
Amazon Web Services publishes a broad set of certifications and a detailed shared responsibility page that spells out the split by service type. Microsoft Azure leans heavily on its government and regional compliance offerings, with an extensive catalog of audit reports available to customers. Google Cloud emphasizes its own transparency and control documentation alongside its certification portfolio. For a side-by-side view of how these platforms compare on capability and compliance posture, this comparison of AWS vs Azure vs Google Cloud is worth reading.
The differences matter less than the process. Whatever platform you choose, the customer side of the shared responsibility model is where most compliance risk lives. A useful primer on what cloud storage is and how it works helps teams understand exactly which layer they control.
Common mistakes that trip up cloud teams
Experienced practitioners see the same errors repeatedly. Avoiding them saves months.
- Confusing provider certification with customer compliance. The certificate covers the provider’s infrastructure, not your misconfigured database.
- Ignoring data residency. A service may be certified globally but store data in a region your regulator does not permit.
- Leaving logging off by default. Many services do not log everything unless you enable it, and auditors want historical evidence.
- Treating compliance as a one-time project. Controls drift. Without continuous monitoring, a compliant environment becomes non-compliant quietly.
- Skipping vendor due diligence. Your cloud vendors are often business associates or sub-processors. Their gaps become your gaps.
- Forgetting the contract. Data processing agreements, breach notification windows, and audit rights are compliance controls too.
That last point deserves emphasis. Contracts are where many cloud compliance obligations actually become enforceable. If a provider will not give you audit rights or a defined breach notification window, no certificate compensates for that gap.
Building a workable compliance program
A practical program follows a predictable sequence, and it does not require an enormous team.
Start with a data inventory and classification. Know what you hold and which rules attach to it. Then map obligations to controls: for each framework requirement, identify the technical or procedural control that satisfies it and who owns it. Next, implement the controls with automation wherever possible, because manual checks decay.
After that, build evidence collection into daily operations. Route logs to a central store, schedule access reviews, and document exceptions with expiry dates. Then test: run tabletop exercises, sample your own controls, and fix gaps before an auditor finds them. Finally, review quarterly. Regulations change, providers add services, and architectures evolve.
Teams that follow this sequence generally find that compliance becomes a byproduct of good engineering rather than a separate burden. That is the real goal. When security hygiene is solid, evidence collection gets easier, audits get shorter, and the compliance posture holds up under scrutiny.
It also helps to understand where the underlying platforms are heading. New architectures such as Apple private cloud compute on Google cloud raise fresh questions about where processing happens and who can access data, and those questions feed directly into compliance scope. Similarly, security controls at the edge, such as the differences covered in this comparison of Cloudflare WAF vs AWS WAF vs Imperva, increasingly count as compliance-relevant controls because they protect regulated data in transit. (Cloud computing)
Conclusion
Cloud compliance is not a product you buy or a box you tick. It is the ongoing discipline of matching your legal and contractual obligations to the way your cloud environment is actually built and operated. The provider’s certifications give you a foundation, but the customer side of the shared responsibility model is where compliance is won or lost.
The teams that do this well share a pattern: they start with their data, they read the scope statements, they automate their controls, and they collect evidence continuously instead of scrambling before audits. None of that requires heroics. It requires clarity about who owns what, and the discipline to keep it current as the environment changes.
FAQ
Does my cloud provider’s certification make me compliant?
No. A provider’s certification covers its own infrastructure and only the services and regions listed in its scope statement. Your configurations, access policies, data handling, and contracts remain your responsibility under the shared responsibility model.
What is the difference between cloud security and cloud compliance?
Security is about protecting data from threats. Compliance is about proving to a regulator or auditor that you meet defined obligations. They overlap heavily, since most compliance frameworks require security controls, but compliance adds documentation, evidence, and reporting requirements that security alone does not cover.
Which framework should a small team start with?
Most small teams start with a data inventory and then adopt ISO/IEC 27001 as a baseline, extending it with ISO/IEC 27017 for cloud-specific controls. Sector rules like HIPAA or PCI DSS apply on top if relevant. Starting with the data map prevents wasted effort on frameworks that do not apply.
How often should cloud compliance controls be reviewed?
Quarterly reviews work well for most organizations, with continuous automated monitoring in between. Access reviews are typically quarterly, and full control testing annually. Any significant architecture change, new service adoption, or regulatory update should trigger an out-of-cycle review.
What role do contracts play in cloud compliance?
A large one. Data processing agreements, breach notification windows, audit rights, sub-processor lists, and data deletion terms are enforceable obligations. A provider that will not grant audit rights or define notification timelines creates a gap no certificate can close.
Does GDPR apply if my cloud servers are outside the EU?
GDPR follows the data, not the servers. If you process personal data of people in the EU, GDPR obligations generally apply regardless of where your infrastructure sits. Data residency rules may add further restrictions depending on your sector and jurisdiction.
