Quick Answer: What is cloud compliance?
Cloud compliance means making sure the workloads, data, and configurations your organization runs in the cloud meet the laws, regulations, standards, and internal policies that apply to them. In practice, that work lands in a few places: data residency and privacy rules, security controls, audit evidence, and access management.
It is different from cloud security, though the two overlap heavily. Security asks whether your environment is defended; compliance asks whether you can prove it meets a specific external or internal obligation. A system can be secure and still fail an audit, and a system can pass a point-in-time audit and still be badly secured.
Before acting, check which regulations actually apply to you, which cloud service and deployment models you use, where your data physically sits, who owns which control under the shared responsibility model, what evidence your auditors will accept, and how often you can realistically re-verify all of it.
Why the Distinction Between Security and Compliance Matters
Plenty of teams treat compliance as a paperwork exercise that happens once a year, right before the auditor shows up. That approach survives until the first time an auditor asks for evidence from a Tuesday in March and nobody can produce it.
The more useful framing is that compliance is a continuous property of your environment, not a certificate on a wall. The controls you implement for security and the controls you document for compliance should be the same controls. When they diverge, you end up maintaining two realities: the one in your architecture and the one in your spreadsheet. That gap is where findings, remediation projects, and unpleasant surprises come from.
This is also why cloud compliance has become an engineering problem rather than a legal one. Most of the evidence auditors want now lives in configuration logs, identity policies, and provider attestation reports. Someone has to be able to pull it.
The Shared Responsibility Model: Who Owns What
Every major cloud provider publishes a version of the shared responsibility model, and it is the single most misunderstood concept in cloud compliance. The short version: the provider is responsible for security of the cloud, and you are responsible for security in the cloud. (Cloud computing)
In practice, the dividing line moves depending on the service model. A useful way to see it:
| Service model | Provider handles | Customer handles |
|---|---|---|
| IaaS | Physical facilities, hypervisor, network fabric | Operating system, patching, applications, data, identity |
| PaaS | Above, plus runtime and managed platform | Application code, data, access configuration |
| SaaS | Above, plus the application itself | Data classification, user access, configuration choices |
The common mistake is assuming a managed service transfers compliance obligations along with operational ones. It does not. If you put regulated data into a managed database, the provider secures the database engine, but you still own who can query it, where backups land, and whether encryption keys are yours or theirs. Auditors will ask about all three.
A second common mistake: treating the provider’s compliance certifications as your own. A provider’s report covers the provider’s controls, not yours. It is an input to your evidence file, not a substitute for it.
The Main Frameworks You Will Encounter
Cloud compliance is not one standard. It is a stack of overlapping obligations, and most organizations end up mapping several at once.
Privacy and data protection law
The General Data Protection Regulation (GDPR) is the reference point for most cloud privacy work. It applies to organizations outside the EU that offer goods or services to, or monitor, people in the EU, which means a great many cloud workloads fall inside its scope whether or not the company has an EU office. It imposes duties on both controllers and processors, and cloud providers typically act as processors for customer data. (NIST Cloud Computing Program)
Other jurisdictions have their own regimes, and they change. Data residency requirements in particular vary widely and are revised often enough that a policy written two years ago may no longer be accurate.
Healthcare and payment data
In the United States, HIPAA governs electronic protected health information, and cloud providers can act as business associates, which pulls them into HIPAA obligations through a business associate agreement. In payments, PCI DSS, maintained by the PCI Security Standards Council, sets requirements for any environment that stores, processes, or transmits card data. Version 4.0 introduced a set of future-dated requirements that became mandatory on 31 March 2025, so older internal documentation referencing 3.2.1 is likely out of date.
Management system and control standards
ISO/IEC 27001 is the international standard for an information security management system, with the current edition published in October 2022. ISO/IEC 27017 adds cloud-specific security control guidance on top of it. On the US side, NIST publishes both the canonical definition of cloud computing in SP 800-145 and a broad catalog of security and privacy controls in SP 800-53, which many organizations use as a baseline even when no regulation demands it.
Government authorization
FedRAMP standardizes security assessment and authorization for cloud services sold to US federal agencies. If you sell to government, it is not optional, and its evidence requirements are unusually detailed.
How to Build a Compliance Program That Survives Contact With Reality
The programs that work tend to share a few traits. They start with an inventory, they automate evidence collection, and they assign named owners to controls.
Start with an inventory, not a policy
You cannot scope compliance obligations without knowing what you run and where it lives. That means an accurate inventory of workloads, data stores, accounts, and regions, plus a classification of what data each one holds. Teams that skip this step end up applying the strictest controls everywhere, which is expensive, or the loosest, which is worse.
A structured approach to what to inventory before a cloud migration pays off twice: once for the migration itself and again when the auditor asks which systems touch regulated data.
Map controls once, reuse them everywhere
Most frameworks overlap heavily. A well-run access review satisfies requirements in several at once. The trick is building a control matrix that maps each of your actual controls to every framework that references it, so you implement once and cite many times.
Automate the evidence
Point-in-time audits are giving way to continuous monitoring, and the reason is practical: manual evidence collection does not scale past a few dozen systems. Configuration logs, cloud provider compliance reports, and third-party attestations such as SOC 2 reports can all be collected on a schedule. What matters is that the collection is reproducible and timestamped.
Give engineers something they can act on
Compliance work fails when it arrives as a document engineers cannot translate into a change. It succeeds when it arrives as a specific configuration requirement with a clear owner. The same principle that makes cloud cost reviews useful to engineers applies here: show the affected resource, the expected state, and the fix.
Where Cloud Compliance Breaks Down in Practice
A few failure patterns show up again and again.
Region assumptions. Teams assume a workload runs in a given region because it was deployed there, then discover a managed service replicates metadata or backups elsewhere. Reading a cloud region announcement carefully, including the fine print on data replication, prevents a lot of residency surprises.
Account sprawl. Compliance scope creeps when teams spin up new accounts for experiments and never decommission them. Deciding when to split workloads across cloud accounts is a security question and a compliance scoping question at the same time.
Cost and compliance reviewed separately. Data transfer and storage choices affect both bills and residency obligations, which is why a clearer way to track cloud data transfer costs is worth having alongside your compliance dashboards.
Stale documentation. Policies drift from reality within a quarter. If your documented architecture is not regenerated from your actual environment, it is fiction.
Ownership gaps. A control with no named owner is a control that will be found missing.
Cloud Compliance and Security Architecture Together
The strongest compliance programs treat architecture as the primary control. Segmentation, least-privilege identity, encryption with customer-managed keys, and centralized logging are all security decisions that happen to generate exactly the evidence auditors want. Building them in from the start is far cheaper than retrofitting them under audit pressure.
This is where a broader view of enterprise AI and cloud security helps: as AI workloads spread across cloud environments, the compliance surface grows with them, and the same architectural discipline applies.
What to Do First If You Are Starting From Zero
- List every cloud account and the workloads inside it, with an owner for each.
- Classify the data each workload handles and note where it physically resides.
- Identify which regulations and standards actually apply, and write down why the others do not.
- Map your existing controls to those frameworks and mark the gaps honestly.
- Automate collection of the evidence you already generate.
- Assign a named owner to every gap and set a review cadence you can keep.
That last point matters more than it sounds. A quarterly review that actually happens beats a monthly one that gets skipped.
Conclusion
Cloud compliance is the discipline of proving, continuously and with evidence, that your cloud workloads meet the obligations that apply to them. It is not a certificate and it is not a legal afterthought. It is an engineering practice that starts with an accurate inventory, runs on the shared responsibility model, and depends on controls that serve security and audit at the same time. Teams that treat it as architecture rather than paperwork spend far less time firefighting when the auditor arrives, and they end up with a cloud environment that is genuinely better secured as a side effect.
FAQ
Does cloud compliance mean my provider is responsible for it?
No. Providers are responsible for security of the cloud, meaning the underlying infrastructure. You remain responsible for what you put in it, including data classification, access configuration, and the evidence that your controls work.
How is cloud compliance different from cloud security?
Security is about defending your environment. Compliance is about demonstrating that you meet specific obligations. They overlap heavily, but a secure system can still fail an audit if the evidence is missing, and a system that passed an audit last year can be insecure today.
Which regulations apply to a company outside the EU?
GDPR can apply to organizations anywhere if they offer goods or services to people in the EU or monitor their behavior. Sector rules like HIPAA and PCI DSS follow the data rather than the company’s location, so a US healthcare workload and a payment workload may each bring their own obligations regardless of where the business is headquartered.
How often should compliance be reviewed?
Continuous monitoring is the goal, with formal reviews at least quarterly. The practical test is whether you could produce evidence for any given day in the past year. If the answer is no, the review cadence is too slow.
Do we need ISO 27001 if we already follow a regulation?
Not necessarily. ISO/IEC 27001 is a management system standard, and many organizations adopt it because it gives structure to controls that regulations only describe in fragments. If a customer or contract requires it, that settles the question. Otherwise treat it as a framework choice, not a legal obligation.
What is the biggest mistake teams make with cloud compliance?
Assuming that a managed service transfers compliance obligations along with operational ones. The provider secures the platform, but you still own who can access the data, where it resides, and whether you can prove any of it.
