What Is Cloud Compliance? Frameworks and Controls

An auditor asks one question that ends most compliance programs: show me. Show me that the S3 bucket holding cardholder data was never public. Show me the access logs for the database under HIPAA scope, for the full retention window, unbroken. Show me that the encryption you claim is on was on last Tuesday at 3 a.m., not just on the day of the audit. The control on paper is easy. The evidence that the control held continuously, across hundreds of accounts that changed every hour, is where cloud compliance lives or dies.

Cloud compliance is the work of meeting regulatory, standards-based, and contractual requirements for the data and systems you run in the cloud, and being able to prove it. It is not a one-time certificate on a wall. It is a continuous claim about configuration and behavior that has to survive the next deployment, the next new account, and the next engineer who opens a port to debug something at midnight. This guide covers what cloud compliance actually means, the shared responsibility split that decides who owns which control, the frameworks you will be measured against, how teams achieve and maintain compliance in environments that never stop changing, and the honest limit: compliance is not security.

What is cloud compliance?

Cloud compliance is the process of ensuring that the data and workloads you operate in a cloud environment meet a defined set of external requirements, and that you can produce evidence the requirements are met. Those requirements come from three sources. Regulations are law: GDPR, HIPAA, and the like carry legal penalties for failure. Standards are industry frameworks you adopt or are contractually required to hold: PCI DSS, SOC 2, ISO 27001. Contractual obligations are the commitments in your customer agreements and data processing addenda, which often pull in one or more of the first two by reference.

The unit of compliance is a control. A control is a specific, testable requirement: encrypt cardholder data at rest, log every administrative action, restrict a storage bucket to named principals, retain audit records for one year. A framework is a structured set of controls plus a method for assessing them. Compliance is the state where every control that applies to you is implemented, operating, and evidenced. Not implemented once. Operating, now, with proof.

What makes cloud compliance hard is not the controls themselves. It is the rate of change and the scale. A traditional data center had a handful of servers that changed on a quarterly maintenance window. A cloud estate has thousands of resources spun up and torn down by automation, across multiple accounts and regions, by teams who do not think of themselves as touching compliance scope when they deploy. A control that was true at the last audit can be false within an hour of a routine change, and nothing tells you unless you built something to watch.

Compliance of the cloud versus compliance in the cloud

The single most consequential idea in cloud compliance is the cloud shared responsibility model, and the most common way programs fail is misreading it. The provider is responsible for the security and compliance of the cloud. You are responsible for security and compliance in the cloud. The line between those two is where audits go wrong.

Compliance of the cloud is the provider's territory: the physical data centers, the hypervisor, the hardware, the managed-service backplane. AWS, Azure, and Google Cloud each hold their own attestations for that layer. AWS publishes SOC reports, ISO 27001 certificates, and a PCI DSS Attestation of Compliance covering its infrastructure, and exposes them through portals like AWS Artifact. That is real, and it is useful: it means you do not have to audit the provider's data center to inherit the controls that live there.

Compliance in the cloud is yours, and it is everything the provider hands you the keys to. Your IAM policies. Your storage bucket permissions. Your encryption configuration and key management. Your network rules. Your application logic. Your data classification and retention. The provider's attestation says the floor is sound; it says nothing about whether you left the front door open. A provider's PCI AOC does not make your cardholder workload PCI compliant. It makes the layer underneath your workload compliant. The 12 PCI DSS requirements still apply to what you built on top, and the assessor will look there.

The trap is the word "inherited." Providers publish responsibility matrices that list controls as provider-owned, customer-owned, or shared. Read the shared row carefully, because shared does not mean handled. Encryption of data at rest is often shared: the provider offers the capability, you have to turn it on and manage the keys. Patching is shared by service: the provider patches a managed database, you patch the operating system on a raw virtual machine. Treating a shared control as inherited is how a bucket of regulated data ends up unencrypted with everyone assuming someone else owned it.

The frameworks that govern cloud workloads

You will rarely deal with one framework. A SaaS company processing health data for European customers and taking card payments can be in scope for SOC 2, HIPAA, GDPR, and PCI DSS at once, with heavy overlap between them. The practical move is to map controls once and satisfy many frameworks from a shared baseline. Here is what the major ones actually govern and why each touches the cloud.

A few facts worth pinning down, because vendor pages get them wrong. PCI DSS v4.0.1 is the only active version as of 2026; v4.0 was retired at the end of 2024 and the future-dated requirements became mandatory on March 31, 2025, so every 2026 assessment is judged against the full v4.0.1 control set. ISO 27001 is on its 2022 revision, whose Annex A reorganized the controls into four themes and added new ones for threat intelligence and cloud services. SOC 2 is built on the AICPA Trust Services Criteria (TSP Section 100), with security as the one required category and availability, processing integrity, confidentiality, and privacy added as scope demands. FedRAMP runs on NIST SP 800-53 Rev. 5 baselines at Low, Moderate, and High impact levels. GDPR penalties run to the higher of 20 million euros or 4% of global annual turnover for the most serious violations. HIPAA civil penalties are tiered by culpability and indexed to inflation every year, so any fixed dollar figure you read goes stale; check the current Federal Register amount rather than quoting an old maximum.

How compliance is achieved and maintained

Achieving cloud compliance is a project. Maintaining it is the actual job, and it is where cloud-native teams either build the right machinery or drown in screenshots. Five pieces do the work.

Controls mapping. Start by translating each framework requirement into a concrete, testable control on your actual stack. "Encrypt cardholder data at rest" becomes "every S3 bucket and RDS instance tagged pci has encryption enabled with a customer-managed KMS key." Map once to a unified control set, then tag each control with the frameworks it satisfies. One well-written encryption control can answer PCI, HIPAA, SOC 2, and ISO 27001 at the same time. This mapping is what turns four audits into one body of evidence.

Continuous compliance monitoring. Manual checks cannot keep up with cloud change, so the control state is watched continuously by tooling. Cloud Security Posture Management (CSPM) is the category that does this: it reads your cloud configuration through the provider APIs, evaluates it against framework and CIS benchmark rules, and flags every resource that falls out of policy. A public bucket, an unencrypted volume, an over-permissive IAM role, a security group open to the internet. Most cloud security assessment work in mature programs is automated this way, with the tool grading posture against the same benchmarks an auditor would use, every hour rather than once a year.

Evidence and audit. Compliance is proven, not asserted, so the system has to capture evidence as it runs. Provider audit logs (AWS CloudTrail, Azure Activity Log, GCP Cloud Audit Logs) record who did what and when. Configuration history services record what every resource looked like at every point in time. Together they answer the auditor's "show me" without a scramble: here is the access log for the full period, here is proof the bucket was never public, here is the encryption status across the retention window. The discipline is to retain that evidence for the period each framework requires, intact, before the audit window opens.

Infrastructure as code guardrails. The most durable fix is to stop non-compliant resources from being created at all. When infrastructure is defined as code (Terraform, CloudFormation), you can scan the definitions before they deploy and block the ones that violate policy. Policy-as-code engines fail a pull request that would create a public bucket or an unencrypted database, so the misconfiguration never reaches production. Provider guardrails (service control policies, Azure Policy) enforce the same rules at the platform level, so even a manual change in the console is denied. Prevention scales where detection alone does not.

The thread through all four is drift. A compliant configuration does not stay compliant on its own. Someone opens a port, a new account is created without the baseline, a deployment overwrites a setting. Continuous monitoring catches drift after the fact; IaC guardrails prevent it before it lands. A program that relies only on a point-in-time audit is compliant exactly once, on the day of the audit, and unknown every other day of the year. The misconfigurations these controls catch are the same AWS misconfigurations that show up as root cause in cloud breach reports.

Compliance is not security

This needs to be said plainly because programs forget it: passing an audit does not mean you are secure. Compliance is a floor, and often a lagging one. Frameworks are written by committee, revised on multi-year cycles, and aimed at a baseline that applies across thousands of organizations. They tell you the minimum a reasonable defender should do. They do not tell you what your specific attacker will do next week.

The gaps are concrete. A control can be technically satisfied and operationally useless: logging is "enabled" to meet the requirement, but no one reads the logs, no alert fires, and the breach runs for ninety days inside a fully compliant environment. A framework can lag the threat: a control set finalized two years ago does not anticipate the attack technique that emerged last quarter. And scope is a knife that cuts both ways. PCI DSS only covers the cardholder data environment, so the rest of your estate can be wide open and your PCI assessment still passes. The compliant boundary is not the secure boundary.

The right reading is that compliance and security overlap heavily but are not the same set. Compliance gives you a structured, auditable, externally validated baseline, which is genuinely valuable: it forces encryption, logging, access control, and review that many teams would otherwise skip. Security is the larger goal of actually resisting attackers, which extends past any framework into detection, response, threat modeling, and the controls no auditor asked for. Treat the certificate as evidence you cleared the floor, not proof you reached the ceiling. The teams that get breached while compliant are the ones that confused the two.

Where cloud compliance gets hard

The cloud compliance failure modes are predictable, and naming them is half the defense.

Multi-cloud multiplies everything. Each provider has its own services, its own configuration model, its own way of expressing the same control. A policy that blocks public storage in AWS does not translate automatically to Azure or GCP. Every framework now has to be satisfied on every platform, and the evidence has to be collected from each one's logs in each one's format. Teams that adopted a second cloud for resilience often discovered they doubled their compliance surface.

Shared responsibility confusion. Covered above, and worth repeating as a failure mode because it is the most common one. Controls fall through the gap between provider and customer because both assumed the other owned them. The fix is to read the provider's responsibility matrix line by line and assign an owner to every control, especially the shared ones.

Configuration drift. The compliant baseline erodes continuously through normal operations. Without continuous monitoring and IaC guardrails, drift is invisible until an auditor or an attacker finds it.

Audit burden. Evidence collection by hand does not scale to thousands of resources across multiple accounts. The teams that survive audits without a fire drill are the ones that automated evidence capture into the platform, so the audit is a report run, not a month of screenshots. The teams that scramble are the ones still treating compliance as an annual event instead of a continuous state. When that scramble ends in a finding that maps to a real exposure, the gap between a compliance failure and a data breach is often a single misconfigured resource that drift introduced and no one was watching for.

The bottom line

Cloud compliance is meeting the regulatory, standards, and contractual requirements for your cloud data and systems, and proving it continuously. The first thing to get right is the shared responsibility split: the provider owns compliance of the cloud, you own compliance in the cloud, and the controls marked shared are where audits fail because both sides assumed the other had it. The frameworks (PCI DSS, HIPAA, GDPR, SOC 2, ISO 27001, FedRAMP, and the CIS Benchmarks underneath them) overlap enough that you map controls once and satisfy many.

The work is continuous, not annual. Map requirements to testable controls, watch them with posture-management tooling, capture evidence as the system runs, and block non-compliant resources with infrastructure-as-code guardrails so drift never lands. And hold the honest line: compliance is a floor, not a ceiling. It forces a real baseline of encryption, logging, and access control, but a fully compliant environment can still be breached if no one reads the logs the framework made you keep. The same artifacts a sound compliance program produces, the logs, the configuration history, the access records, are the same artifacts an investigation needs. Build them for the auditor and the defender gets them for free.