Cloud Security Compliance: Mapping Controls to ISO, SOC 2, and GDPR

Cloud security compliance is the process of aligning your cloud environment controls, configurations, and documented evidence with the requirements of regulatory and industry frameworks such as ISO 27001, SOC 2, and GDPR. It is not a one-time audit exercise. Once you move workloads to AWS, Azure, or GCP, you inherit a shared responsibility model that makes compliance an operational discipline rather than a paperwork problem.

For most security teams, the friction starts here: each framework speaks a different language. SOC 2 talks about Trust Services Criteria. ISO 27001:2022 references Annex A controls and the ISO 27017/27018 cloud security extensions. GDPR uses the phrase appropriate technical and organisational measures without defining them. The practical result is that your team ends up maintaining three separate control libraries when a single well-designed control can satisfy all three simultaneously.

This article maps the major cloud controls to each framework, shows you where overlap exists, and explains how continuous compliance tooling changes the evidence collection burden you are probably still handling manually.

What Cloud Security Compliance Actually Requires Under Each Framework

The three frameworks serve different masters. SOC 2 is a client-facing attestation, produced for B2B trust. ISO 27001 is a certifiable management system standard you own internally. GDPR is a legal obligation tied to personal data rights. Conflating them leads to compliance programmes that satisfy auditors but leave genuine gaps in your cloud posture.

SOC 2 is organised around five Trust Services Criteria: Security (CC), Availability (A), Processing Integrity (PI), Confidentiality (C), and Privacy (P). Security is always in scope; the others are optional depending on your service commitments. The most demanding cloud controls cluster in CC6 (Logical and Physical Access Controls), CC7 (System Operations), and CC8 (Change Management). CC6.1 through CC6.8 address how access to cloud resources is restricted, monitored, and revoked, which maps directly to IAM policy governance in any cloud provider.

ISO 27001:2022 restructured its Annex A in the 2022 revision, collapsing 114 controls into 93 and adding 11 new ones that reflect cloud and threat-intelligence realities. The cloud-specific extensions live in ISO 27017 (controls for cloud services) and ISO 27018 (personally identifiable information in public clouds). ISO 27017 Clause 6.3.1 specifically addresses the division of responsibilities between cloud service providers and customers, which is the structural foundation of every cloud compliance programme. See the official standard at iso.org/standard/27001.

GDPR Article 32 requires controllers and processors to implement appropriate technical and organisational measures considering the state of the art, the costs of implementation, and the nature, scope, context and purposes of processing. In practice, for cloud environments this translates into encryption at rest and in transit, access control, incident response capability, and the ability to restore availability after an incident. The GDPR accountability principle under Article 5(2) means you must be able to demonstrate these measures exist, not merely assert they do. Full text at gdpr.eu.

Mapping One Cloud Control Across ISO 27001, SOC 2, and GDPR

The most efficient cloud security compliance strategy collapses parallel requirements into single controls with cross-referenced evidence. Consider encryption of data at rest, which every cloud compliance conversation eventually reaches.

This cross-referencing approach is what mature GRC platforms implement at scale. When your encryption-at-rest configuration is tested once and tagged to all three frameworks simultaneously, you stop answering the same question three times per audit cycle.

Where the Shared Responsibility Model Creates Cloud Compliance Gaps

Every major cloud provider publishes a shared responsibility matrix, and every compliance failure in cloud environments happens in the customer half of that matrix. The provider secures the physical infrastructure, the hypervisor, and the managed service layer. You are responsible for what runs on top: your data classifications, your IAM configurations, your network segmentation, and your runtime behaviour.

ISO 27017 Clause 6.3 formalises this division. It requires that the roles and responsibilities for both cloud service provider and cloud customer are clearly defined, documented, and communicated. Most organisations have the provider documentation. Few have documented their own side of the matrix in a form an auditor can interrogate without assistance.

The compliance gaps that appear most frequently in cloud audits fall into three categories:

• IAM sprawl: permissions granted at account inception that were never revoked, service accounts with administrator access to production, and no automated detection for privilege escalation paths.
• Logging gaps: services enabled after the initial CloudTrail or Audit Log configuration that were never added to the centralised pipeline, leaving intervals with no audit trail.
• Encryption inconsistencies: databases encrypted with provider-managed keys when a certification scope requires customer-managed keys with documented rotation schedules.

Each of these gaps looks like a configuration problem, but it is fundamentally an evidence problem. You cannot prove a control exists if you cannot produce the artefact that demonstrates it was active, tested, and reviewed during the audit period. Our cloud security best practices checklist covers how to systematically inventory these customer-side obligations before an audit window opens.

Continuous Compliance Versus Point-in-Time Auditing in Cloud Environments

Traditional compliance ran as an annual cycle: prepare evidence in Q3, host auditors in Q4, remediate findings in Q1, forget about it until Q3 again. That model was always inadequate for cloud environments, where a Terraform change or a misconfigured S3 bucket policy can invalidate a control you documented six months earlier.

Continuous compliance treats your control framework as a live assertion against your cloud configuration. Tools like AWS Security Hub with NIST 800-53 or CIS Benchmark standards enabled, or Azure Policy with regulatory compliance initiatives, evaluate your configuration state against defined controls on a near-real-time basis. When a control drifts out of compliance, an alert fires and the deviation is logged with a timestamp, which becomes part of your evidence record rather than a gap in it.

For SOC 2 specifically, this matters because your auditor is assessing the effectiveness of controls over a defined period, typically six or twelve months. A continuous monitoring posture lets you demonstrate that CC7.2 (system monitoring) was not just configured on day one but was operating continuously. That is a categorically different evidence package from a screenshot of a CloudWatch dashboard taken the week before the audit window closes.

From a practitioner standpoint, the shift to continuous compliance also changes how your team relates to policy exceptions. When every deviation is logged automatically, exceptions require explicit approval and built-in expiry dates. The informal agreement to fix things after the audit, which exists in almost every team running manual evidence collection, becomes structurally impossible to sustain.

Evidence Collection for ISO 27001, SOC 2, and GDPR: What Cloud Auditors Actually Need

Evidence collection is where cloud security compliance programmes either scale or collapse. The artefacts required across these three frameworks overlap substantially, but the framing differs enough that teams without a unified collection strategy end up duplicating effort.

For ISO 27001, your Statement of Applicability (SoA) must document which Annex A controls you have implemented, why you have excluded others, and reference the evidence for each. In a cloud environment, that evidence includes infrastructure-as-code repositories showing controls are codified rather than merely configured, access review logs, encryption key rotation records, and penetration test reports. The 2022 revision added Annex A 8.9 (Configuration Management), which directly requires documented baselines for cloud resource configurations, making your Terraform or CloudFormation state a compliance artefact. In practice, when we have worked through SOC 2 Type II readiness with teams that had already codified their infrastructure in Terraform, evidence preparation took roughly three weeks. Teams still managing resources through console clicks consistently needed eight to ten weeks for the same scope. The discipline of infrastructure-as-code pays back twice: once when you build the environment, again when you prove it to an auditor.

For SOC 2, your auditor needs population-level evidence: every user with access to the system, every change deployed during the period, every security event reviewed. Cloud environments generate this data automatically. The challenge is retaining it in a queryable form for the audit period and mapping it to the correct criterion. CC6.2 (prior to access, new users are registered) requires evidence from your identity provider, not your cloud console. The integration between your IdP, your cloud IAM, and your evidence collection platform is the operational problem worth solving before your audit window opens.

For GDPR, the accountability principle means your Records of Processing Activities (RoPA) must reflect where personal data actually lives in your cloud environment, not where you intended it to live when you designed the architecture. Data discovery tooling such as AWS Macie or Microsoft Purview should feed your RoPA updates, because manual classification does not survive the pace of cloud resource creation.

You can read more about building the foundational controls layer in our guide to cloud security best practices, which covers the technical configuration baseline your compliance evidence depends on.

Compliance Automation: Where It Saves Time and Where Human Judgement Still Applies

Compliance automation platforms have matured significantly. Vanta, Drata, Secureframe, and similar tools connect to your cloud APIs, pull configuration evidence automatically, and map findings to SOC 2 criteria or ISO controls. They reduce the time spent on evidence collection from weeks to hours for well-configured environments.

What they do not replace is the control design work that happens upstream. A platform can verify that your S3 buckets have public access blocked and tag that as evidence for CC6.1. It cannot tell you whether your data classification policy is accurate, whether your retention settings match your GDPR legal bases, or whether your incident response runbooks have been tested in a realistic scenario. The automation handles the mechanical evidence lift. The security judgement is still yours.

The practical split is this: automate evidence collection for configuration-state controls covering encryption, access, logging, and patching; keep human review for process controls including access reviews, vendor risk assessments, change advisory approvals, and exception management. The former is where you eliminate toil. The latter is where your compliance programme either demonstrates real security or becomes a documentation exercise.

For cloud data classification and retention, the controls that feed GDPR compliance most directly, the deeper treatment is in our cloud data security coverage, which addresses how to structure classification schemes that hold up under data protection authority scrutiny.

Building a Cross-Framework Control Library That Scales Across Cloud Certifications

The most durable solution to multi-framework cloud security compliance is a unified control library your organisation owns, rather than a stack of framework documents maintained separately. This means writing controls in your own operational language, then mapping each to the relevant citations across ISO 27001, SOC 2, and GDPR.

A control entry in a well-built library reads something like this: all production database instances must use customer-managed encryption keys with annual rotation, documented in the KMS key policy and verified quarterly by automated scan. That single control maps to ISO 27001:2022 Annex A 8.24, SOC 2 CC6.1 and C1.1, and GDPR Article 32(1)(a). When you implement it, you implement it once. When you test it, you test it once. The evidence you collect satisfies all three frameworks simultaneously.

Building this library takes investment upfront. The return is that your next framework addition, whether PCI-DSS, DORA, or Cyber Essentials Plus, requires only a mapping exercise against controls you already operate, not a new implementation programme. The Cloud Security Alliance STAR programme provides mapping tables that can accelerate the initial library build, but the specificity of your implementation, the tooling you use, the thresholds you set, and the testing cadences you commit to, must come from your own environment.

ISO 27001 certification and SOC 2 Type II attestation issued by a credible auditor both signal to enterprise buyers that your cloud security compliance programme has been independently validated. For regulated industries and public sector supply chains in the UK, they are increasingly a precondition for contract award rather than a differentiator. Start with the control library, map it to frameworks second, and your audit readiness becomes a byproduct of how you operate rather than a separate project you run once a year.

Frequently Asked Questions

What is cloud security compliance?

Cloud security compliance is the process of aligning your cloud infrastructure controls, configurations, and operational processes with a regulatory or industry framework such as ISO 27001, SOC 2, or GDPR. It requires documented evidence that those controls were active and effective over a defined period, not just configured at a single point in time.

Who is responsible for cloud compliance?

Responsibility is split under the shared responsibility model. Your cloud provider secures the underlying infrastructure and managed services. Your organisation is responsible for data classification, identity and access management, application-layer security, and configuration of every service you deploy. Compliance failures almost always originate in the customer half of that boundary.

How do you automate cloud security compliance?

Automation platforms such as Vanta, Drata, or Secureframe connect to your cloud APIs to collect configuration evidence automatically and map it to framework controls. They handle mechanical evidence collection for configuration-state controls. Process controls, including access reviews, vendor assessments, and exception approvals, still require human judgement and periodic manual review.

What frameworks apply to cloud security?

The most commonly required frameworks for cloud environments are ISO 27001:2022 with its ISO 27017 and ISO 27018 cloud extensions, SOC 2 Trust Services Criteria, and GDPR Article 32. Depending on your sector you may also face PCI-DSS, DORA, NIST 800-53, or Cyber Essentials Plus requirements, many of which share significant control overlap with these three primary frameworks.