What happens when an auditor asks your team to prove that a workload in the cloud is compliant, and the only answer anyone can give is a screenshot of a settings page? That moment is where most cloud compliance programs quietly fall apart. The policies exist. The controls probably exist too. But the evidence is scattered across four consoles, two spreadsheets, and someone’s memory of a change made last spring.
A cloud compliance framework is the structure that prevents this. It maps legal and contractual obligations to specific technical controls, assigns ownership, and produces evidence on a schedule instead of in a panic. This article explains how the major frameworks fit together, where teams usually go wrong, and what a workable program looks like in practice.
What a cloud compliance framework actually is
It helps to separate three things people often blur together.
The obligation is what you must do: protect personal data, report incidents within a deadline, keep financial records for a set period. The framework is the organized set of controls that translates obligations into checkable requirements. The evidence is the artifact proving a control operated: a log export, a ticket, a configuration snapshot, a signed review.
A framework without evidence is a wish list. Evidence without a framework is a pile of files nobody can interpret. The useful definition of compliance maturity is simply how quickly a team can produce trustworthy evidence for any control on demand. (NIST Cybersecurity Framework)
It also helps to know where the underlying vocabulary comes from. The widely cited definition of cloud computing, with its five defining characteristics and three service models, comes from NIST SP 800-145, published in 2011. Almost every compliance mapping you will encounter assumes that model, which is why the split between infrastructure, platform, and software services matters so much when you decide who owns which control.
The frameworks most organizations end up juggling
No single framework covers everything. Most mid-sized and large organizations run a primary information security standard, one or two regulatory overlays, and a customer-driven scheme. The table below shows how the common ones differ in purpose.
| Framework | Primary purpose | Who it typically applies to | Evidence style |
|---|---|---|---|
| ISO/IEC 27001 | Certifiable information security management system | Any organization, any sector | Audited management system records |
| ISO/IEC 27017 | Cloud-specific security controls | Cloud service providers and cloud customers | Extended control statements |
| ISO/IEC 27018 | Protecting personal data in public clouds | Providers acting as data processors | Control statements plus public commitments |
| ISO/IEC 27701 | Privacy information management | Organizations handling personal data | Extension to 27001/27002 |
| SOC 2 | Independent attestation against trust criteria | Service organizations serving customers | Auditor report on controls |
| FedRAMP | Authorization for US federal cloud use | Providers selling to US agencies | Authorization package and continuous monitoring |
| NIS2 and DORA | EU regulatory obligations | Entities subject to NIS2; financial entities and their ICT providers | Supervisory reporting and registers |
A few practical notes on this list. ISO/IEC 27017 was first published in 2015 and has since been revised, so check the current edition before you build a control matrix around it. ISO/IEC 27018 dates from 2014 with a later revision, and ISO/IEC 27701 appeared in 2019 with a revision expected in the mid-2020s. Edition dates matter because auditors test against the edition named in your scope statement.
On the regulatory side, the EU NIS2 Directive (2022/2555) treats cloud services as digital infrastructure, with a transposition deadline of October 2024 that many member states missed, so national status varies. DORA (Regulation 2022/2554) has applied since January 2025 and puts ICT third-party risk rules on financial entities using cloud providers. The EU Data Act (Regulation 2023/2854) adds cloud switching obligations that largely apply from September 2025.
Where cloud compliance differs from traditional IT compliance
In a data center you control, the auditor can walk to the rack. In the cloud, you are renting someone else’s rack, and the boundary of your responsibility shifts with every service you adopt.
That boundary is the single biggest source of failed audits. A team assumes the provider handles patching, then discovers that a managed database service only patches the engine, not the schema permissions or the network rules around it. The fix is a written responsibility split per service, not a single document for “the cloud.” Practical teams build a matrix: service name, provider responsibility, your responsibility, control reference, evidence source. It is tedious work, and it prevents most nasty surprises.
The second difference is continuous change. Infrastructure defined in code can drift from its declared state without anyone touching a console. Compliance programs built on annual snapshots miss this entirely. What works in practice is automated drift detection tied to the same control identifiers the auditor uses, so a drift alert is already phrased in compliance language.
The third difference is shared evidence. A provider’s SOC 2 report or ISO certificate covers a slice of your control set, and you still need to review it, note the period it covers, and check that the services you use are inside its scope. Filing the PDF without reading the scope section is one of the most common mistakes in the field. More than one organization has discovered after an incident that a key service was excluded from the provider’s attestation.
Building the framework in a sensible order
The order of work matters more than the tooling. Teams that buy a compliance platform before defining scope usually spend a year configuring it and still fail the first audit.
- Define scope precisely. Name the accounts, regions, services, and data types in scope. Vague scope statements like “our production environment” invite arguments later.
- Write the responsibility split per service. Include the provider’s attestation reference and its coverage period for each one.
- Map obligations to controls. Start from your existing security standard and add regulatory overlays. Resist creating a separate control set for every regulation; map many obligations to one control instead.
- Assign a named owner per control. “The platform team” is not an owner. A person is.
- Automate evidence collection. Pull configuration state, access reviews, and log retention checks on a schedule into a store the auditor can read.
- Test controls before the auditor does. Run an internal sample of each control, record the exceptions, and fix the ones that fail.
- Review quarterly. Frameworks change, providers change, and your architecture changes. A quarterly review catches drift before it becomes a finding.
Steps two and five are where most of the real effort sits, and they are the two teams most often skip.
Getting the inventory right before anything else
You cannot scope what you have not listed. Before control mapping makes sense, someone has to know every account, every region, every data store holding regulated data, and every third party touching it. Teams that jump straight to control checklists usually discover halfway through that half their estate was never in scope.
A structured approach helps here. The guidance on what to inventory before a cloud migration covers the asset, data, and dependency lists that also serve as the backbone of a compliance scope statement. Doing that inventory once, properly, saves months of rework.
Region choice deserves its own line in the inventory. Data residency obligations attach to where data is stored and processed, and region launches change the options available. Reading a provider’s cloud region announcement carefully tells you whether a new region actually satisfies a residency requirement or merely adds latency options. Compliance teams that track region news alongside legal changes avoid the unpleasant discovery that a workload sits outside the jurisdiction their contract promised.
Making the framework survive contact with engineering
The most common failure mode is not a missing control. It is a compliance program that engineers route around because it slows them down without visible benefit.
Three practices tend to work. First, express controls as code checks wherever possible, so compliance is a pipeline gate rather than a quarterly email. Second, keep the control catalogue short enough that people can remember the top twenty. Third, make cost and compliance reviews share a forum, because both depend on the same inventory and the same ownership data. The approach in making cloud cost reviews useful to engineers transfers well: short, specific, owner-tagged findings get fixed, while long reports get archived.
Account structure is another lever. Splitting workloads across accounts creates natural control boundaries and limits blast radius, which auditors like. The trade-offs are covered in when to split workloads across cloud accounts, and the short version is that boundaries should follow data sensitivity and ownership, not org charts.
For teams running AI workloads, the compliance surface grows again: model inputs may contain personal data, outputs may be retained, and third-party inference endpoints sit in the supply chain. The material on enterprise AI and cloud security is a reasonable starting point for mapping those services into an existing control set rather than bolting on a parallel one.
Evidence, audits, and the questions that trip teams up
Auditors rarely ask whether a control exists. They ask to see it operating over a period. That means dated evidence, samples, and exceptions with remediation notes.
The questions that cause the most trouble are predictable. Who approved this access, and when was it last reviewed? What happens to logs when a service is decommissioned? How do you know the provider’s attestation still covers the service you use? Which policy covers this specific data store? Teams with automated evidence collection answer in minutes. Teams without it answer in weeks.
One more habit pays off: keep a single register of provider attestations with scope, period, and review date. When a certificate lapses or a report’s period ends, the register flags it before a customer does.
How the frameworks fit together in practice
Most organizations do not need every framework. A sensible pattern is one certifiable management system as the spine, cloud-specific controls layered on top, and regulatory overlays mapped onto the same control identifiers. That way one piece of evidence can satisfy several obligations.
The mapping work is where the value sits. A control that enforces encryption at rest may satisfy an internal standard, a customer contract clause, and a regulatory requirement at once. Frameworks that look unrelated on paper often collapse into a much smaller set of technical checks.
The broader discipline of cloud architecture and governance is worth studying alongside compliance, since the two share the same inventory and ownership foundations. The resources on cloud infrastructure and architecture cover the structural decisions that determine how easy compliance will be later. For a wider view of how compliance, cost, and architecture intersect, enterprise AI and cloud intelligence collects related material. (Cloud computing)
Conclusion
A cloud compliance framework is less a document than a habit: know what you run, know who owns it, prove it works on a schedule, and keep the proof where an auditor can find it. The standards will keep changing, and the edition dates in your scope statement will need updating. What does not change is the underlying discipline of mapping obligations to controls, splitting responsibility with providers in writing, and collecting evidence continuously rather than annually.
Teams that start with a precise inventory and a per-service responsibility matrix tend to sail through audits. Teams that start with a tool purchase tend to spend the next year catching up. The order of work is the whole game.
Frequently asked questions
What is the difference between a cloud compliance framework and a certification?
A framework is the structured set of controls and obligations. A certification is an independent body’s confirmation that your management system meets a standard, such as ISO/IEC 27001. You can adopt a framework without certifying against it, and many organizations do for internal governance before pursuing formal certification.
Which framework should a small company start with?
Start with the obligations that actually apply: customer contracts, sector rules, and data protection law. Then adopt one recognized control set as the spine rather than building a bespoke one. A single well-evidenced control set beats three half-maintained ones, and it scales as obligations accumulate.
Does using a certified cloud provider make us compliant?
No. Provider certifications cover the provider’s side of the shared responsibility model, and only for services inside the attestation’s scope. You still own identity management, data classification, configuration, access review, and much of the evidence. The provider’s report is an input, not an answer.
How often should controls be tested?
Most teams test high-risk controls quarterly and the rest annually, with automated checks running continuously in between. The right cadence depends on how fast your environment changes. Fast-moving platforms need faster cycles, because drift between tests is where findings come from.
What evidence do auditors usually ask for first?
Access reviews with named approvers and dates, change records tied to deployments, log retention proof, and the scope sections of provider attestations. These four cover a large share of typical findings, and all of them can be automated or at least scheduled.
How do regulatory changes get folded into an existing framework?
Through mapping, not replacement. When a new obligation arrives, identify which existing controls already address it, note the gap, and add the smallest control that closes it. Rebuilding the framework for each regulation multiplies evidence work and usually fails the next audit anyway.
