A surprising number of cloud compliance failures have nothing to do with missing security tools. They come from a configuration change nobody documented, a log that stopped flowing three months ago, or a vendor whose security report expired last quarter. The controls existed. The evidence did not.
That gap is the whole game. Cloud compliance is not a product you buy or a checkbox you tick once. It is the ongoing practice of proving, with evidence, that your cloud environment meets a defined set of rules, and that it keeps meeting them as the environment changes. This article walks through what those rules actually are, where teams trip up, and what a workable compliance program looks like in practice.
What cloud compliance actually means
Cloud compliance means aligning your use of cloud services with external obligations and internal policies. Those obligations come from several directions at once:
- Regulations such as the EU’s General Data Protection Regulation, which has applied since 25 May 2018 and governs how personal data of EU residents is processed, including by cloud providers acting as processors.
- Industry standards such as ISO/IEC 27017 for cloud security controls and ISO/IEC 27018 for protecting personally identifiable information in public clouds.
- Government frameworks such as NIST SP 800-53, the U.S. federal control catalog whose Revision 5 was published in September 2020 and which is widely borrowed well beyond government.
- Contractual commitments made to customers, which are often stricter than any law.
The tricky part is that compliance is shared. Your cloud provider secures the physical data centers, the hypervisor, and the underlying network. You secure your configurations, identities, data, and access policies. Auditors do not care that the provider is compliant. They care that you are compliant on your side of that line, and most real findings land on the customer side.
The frameworks worth knowing
Different rules apply depending on who you are and what you sell. Here is a practical map of the major ones.
| Framework | Who it applies to | What it covers | Nature |
|---|---|---|---|
| GDPR | Anyone processing EU personal data | Privacy and data protection | Law |
| NIS2 Directive | Essential and important entities in the EU | Cybersecurity risk management | Law |
| EU Data Act | Cloud and data processing providers in the EU | Data access and cloud switching | Law |
| ISO/IEC 27017 and 27018 | Organizations using public cloud | Cloud-specific security and PII controls | Standard |
| NIST SP 800-53 | U.S. federal agencies and contractors | Security and privacy controls | Framework |
| FedRAMP | Cloud services sold to U.S. government | Authorization baseline | Program |
| SOC 2 | Service organizations | Trust Services Criteria | Attestation |
| PCI DSS v4.0 | Anyone handling card data | Payment data security | Standard |
A few notes that matter in practice. SOC 2 is an attestation report, not a law, and it is a point-in-time snapshot, so a report from eighteen months ago says little about today. PCI DSS v4.0 was published in March 2022, and its future-dated requirements became mandatory on 31 March 2025, which caught plenty of teams off guard. The NIS2 Directive entered into force on 16 January 2023 with a member-state transposition deadline of 17 October 2024, and how thoroughly each country has implemented it varies considerably.
Then there is the EU Data Act, Regulation (EU) 2023/2854, which entered into force in January 2024. Its cloud-switching provisions apply from 12 September 2025, and they push directly at something most teams have never tested: how quickly and cleanly they can move workloads and data out of one provider and into another.
Where cloud compliance actually breaks
Ask anyone who has sat through a third-party audit and they will tell you the same thing. Failures cluster in predictable places. None of them are exotic.
Configuration drift tops the list. Someone opens a storage bucket for a quick test, forgets to close it, and three months later an automated scanner flags public exposure. Infrastructure-as-code helps enormously here, because it turns configuration into something reviewable and versioned rather than something clicked into existence.
Identity sprawl is a close second. Orphaned accounts, over-privileged service roles, and access keys that outlived the project they were created for are the single most common route to a breach in cloud environments. Least privilege is easy to say and genuinely hard to maintain without automation.
Expired evidence is the quiet killer. A vendor’s SOC 2 report lapses, a penetration test goes stale, or a log retention setting silently changes and destroys the audit trail you needed. Compliance is a continuous evidence problem, not an annual one.
Unclear data residency causes grief too. Teams assume data stays in a region because they picked that region at setup, then discover that backups, replicas, or a support console route data elsewhere. Cloud sovereignty rules are fragmented and shifting, so there is no single global answer here.
Building a program that survives contact with reality
A workable cloud compliance program follows a recognizable arc. It is not glamorous, but it holds up.
- Map your obligations. List every regulation, standard, and contract clause that applies. Be honest about scope. A company selling only domestically has a very different burden than one with EU customers.
- Inventory your cloud estate. You cannot protect what you cannot see. Every account, subscription, region, and service should be known and owned.
- Translate rules into controls. Turn “protect personal data” into concrete, testable controls: encryption at rest, access reviews, logging, retention limits.
- Automate evidence collection. Manual screenshot gathering does not scale. Continuous monitoring that pulls configuration state and logs into a compliance dashboard is what makes audits survivable.
- Test continuously. Policy-as-code checks, regular access reviews, and periodic penetration tests turn compliance from a scramble into a routine.
- Review and adapt. Frameworks change. Regulations change. Your environment changes weekly. Build a quarterly review into the calendar.
For teams just getting oriented, understanding the fundamentals of what cloud storage is and how it works is a useful starting point, because storage misconfigurations account for a large share of real-world findings. Knowing the key differences between cloud storage and local storage also clarifies where your responsibility genuinely begins and ends. (NIST SP 800-145: The NIST Definition of Cloud Computing)
The multi-cloud wrinkle
Compliance gets harder the moment a second provider enters the picture. Each platform has its own identity model, logging format, and control vocabulary. A control that is native and automatic in one environment may require custom tooling in another.
When teams compare platforms, they usually focus on price and features. Compliance teams should be comparing control coverage, audit artifact quality, and regional footprint instead. A structured comparison of AWS, Azure, and Google Cloud helps frame those differences, and a side-by-side look at the best cloud storage services can reveal which providers make evidence export and access transparency genuinely easy rather than an afterthought.
Two practical tips from watching teams do this. First, standardize on one control framework internally and map each provider’s native controls to it, rather than letting each platform dictate its own vocabulary. Second, insist on consistent log schemas before you scale, because retrofitting normalization across three clouds is far more painful than designing for it up front.
Privacy, sovereignty, and the moving target
The hardest part of cloud compliance today is privacy architecture. Providers have started building confidential computing and private processing environments specifically to address regulator concerns, and the details matter. A look at how Apple’s private cloud compute intersects with Google Cloud shows why architectural guarantees are now part of compliance conversations and engineering discussions. (Cloud computing)
Security tooling choices carry compliance weight too. Web application firewalls generate logs that auditors want to see, and misconfigured ones create both exposure and evidence gaps. A practical comparison of Cloudflare WAF, AWS WAF, and Imperva is worth reading before committing, since logging depth and retention differ meaningfully between them.
The uncomfortable truth is that compliance frameworks lag behind the technology they govern. By the time a regulation is finalized, the architecture it describes has often already shifted. Teams that treat compliance as a living process rather than a project absorb that lag far better than those that treat it as a one-time gate.
Common mistakes worth avoiding
A few patterns show up again and again, and they are all avoidable.
- Treating the provider’s certification as your own. It covers their infrastructure, not your configurations.
- Assuming encryption defaults are enough. Key management and access to those keys matter as much as the encryption itself.
- Letting evidence collection stay manual. It works for ten controls and collapses at two hundred.
- Ignoring exit and portability requirements. With cloud-switching obligations now live in the EU, an untested exit plan is a compliance gap.
- Skipping the human layer. Policies nobody reads and training nobody attends fail quietly.
Conclusion
Cloud compliance is less about checklists and more about continuous proof. The organizations that handle it well share a few habits: they know exactly what rules apply to them, they automate evidence gathering instead of scrambling for it, and they treat configuration as code rather than clicks. They also accept that the target moves, because regulations, standards, and provider capabilities all shift on their own schedules.
Start with an honest map of your obligations and your cloud estate. Turn the biggest rules into testable controls. Automate what you can, review what you cannot, and test your exit routes before you need them. Do that consistently, and audit season stops being a crisis and becomes a routine.
Frequently asked questions
What is cloud compliance in simple terms?
It means following the rules that apply to your data and systems in the cloud, and being able to prove you follow them. The rules come from laws, industry standards, and contracts. The proof comes from logs, configuration records, and audit reports.
Is my cloud provider responsible for compliance?
Only partly. Providers secure the underlying infrastructure, but you remain responsible for your own configurations, identities, access policies, and data handling. Most real audit findings land on the customer side of that shared responsibility line.
Do I need SOC 2 if I am not a US company?
Not necessarily. SOC 2 is a voluntary attestation often requested by business customers. Whether you need it depends on what your customers demand and which markets you sell into, not on where you are headquartered.
How often should compliance evidence be refreshed?
Most evidence should be collected continuously or at least monthly, while formal audits happen annually. Vendor reports and penetration tests do expire, so track their dates and start renewals well before they lapse.
What is the biggest cloud compliance risk for small teams?
Configuration drift and identity sprawl. Small teams move fast, and a forgotten public bucket or an over-privileged service account is far more likely to cause a problem than a sophisticated attack.
Does the EU Data Act affect cloud switching?
Yes. Its cloud-switching provisions apply from 12 September 2025, and they require providers to make it easier for customers to move workloads and data elsewhere. Testing your own exit plan is now a sensible compliance habit and a matter of good hygiene.
One final point deserves emphasis: document your decisions as well as your controls. When an auditor asks why a particular region was chosen or why a control was implemented a certain way, a written rationale turns a difficult conversation into a short one. Decision records cost little to maintain and pay for themselves the first time a regulator or customer asks a pointed question. Compliance maturity is mostly the habit of leaving a clear trail behind you.
