Cloud Security Compliance Guide

Why cloud compliance differs from on-premises

Cloud security compliance requires a fundamentally different approach than traditional on-premises compliance because the operating model has changed. When your infrastructure lived in a data center you controlled, compliance meant documenting controls over hardware you owned, networks you wired, and servers your team patched. In the cloud, you share control of the stack with the provider, infrastructure changes through API calls rather than change tickets, and resources spin up and down faster than quarterly audit cycles can capture.

Three structural shifts make cloud compliance distinct:

Shared ownership of controls. In a traditional data center, your team owns the entire stack from physical access to application configuration. In the cloud, the provider owns layers of the stack that you cannot directly inspect or modify. Your cloud security architecture must account for this split, and your compliance evidence must demonstrate that both sides are covered. An auditor asking about physical access controls gets pointed to the provider’s SOC 2 report; an auditor asking about IAM policies is looking at your implementation.

Infrastructure as code changes the evidence model. When infrastructure is defined in Terraform templates and deployed through CI/CD pipelines, the traditional evidence artifacts (screenshots of configuration panels, signed change request forms) no longer reflect how changes actually happen. Compliance evidence in cloud environments comes from version-controlled infrastructure definitions, automated policy evaluations, and API-generated audit logs. Your compliance program must collect evidence from these sources rather than relying on manual documentation processes designed for static environments.

Dynamic resources break point-in-time assessments. A compliance assessment that evaluates your cloud environment on Tuesday may not reflect the environment that exists on Thursday. Auto-scaling groups create and destroy instances. Developers provision new storage buckets and database instances through self-service tooling. Serverless functions execute and disappear. Continuous compliance monitoring replaces the annual assessment as the primary assurance mechanism, with periodic audits validating that the monitoring itself is comprehensive and accurate.

These differences do not make compliance harder or easier. They make it different. Organizations that try to force on-premises compliance processes onto cloud environments end up with compliance programs that are expensive to maintain, slow to adapt, and full of gaps that auditors find during the assessment.

The shared responsibility model across providers

Every cloud compliance program starts with understanding exactly where the provider’s responsibility ends and yours begins. Each major provider publishes a shared responsibility model, and while the general concept is consistent, the specific boundaries vary by service type and provider.

AWS shared responsibility

AWS frames responsibility as “security of the cloud” (AWS) versus “security in the cloud” (customer). AWS secures the global infrastructure, the hypervisor, and the managed service control planes. You secure IAM configuration, security group rules, encryption settings, operating system patching (for EC2), application code, and data classification. For managed services like RDS or Lambda, AWS takes on more operational responsibility, but you still own access control configuration, encryption key management, and data governance.

Azure shared responsibility

Microsoft uses a similar model with explicit delineation by service type (IaaS, PaaS, SaaS). Azure secures physical hosts, the network fabric, and the data center. For IaaS (Virtual Machines), you manage the OS, network controls, and applications. For PaaS (App Service, Azure Functions), Microsoft manages the OS and runtime while you manage applications and data. Azure’s compliance documentation through the Service Trust Portal provides the attestation reports (SOC 2, ISO 27001, FedRAMP) that cover Microsoft’s side of the model.

GCP shared responsibility

Google calls its version the “shared fate” model, emphasizing that Google actively helps customers configure their environments securely rather than simply drawing a line. GCP provides secure-by-default configurations, recommends organizational policies, and offers Assured Workloads for regulated environments. The practical boundary is similar to AWS and Azure: Google secures the infrastructure, you secure your configurations, identities, data, and applications. GCP’s Compliance Reports Manager provides the third-party attestations covering Google’s controls.

Where the model creates compliance gaps

The most common compliance gap across all three providers is the assumption gap. Teams assume the provider encrypts data at rest by default (sometimes true, but key management is always the customer’s responsibility). They assume the provider monitors for threats (providers offer the tooling, but operating it is the customer’s job). They assume provider certifications cover the customer’s compliance obligations (they cover the provider’s infrastructure, not how the customer uses it). A thorough cloud security risk assessment identifies these assumption gaps before an auditor does.

Major compliance frameworks in cloud

Multiple compliance frameworks apply to cloud environments, and most organizations must satisfy more than one simultaneously. Understanding which frameworks apply and where they overlap is the foundation of an efficient compliance program.

SOC 2 in cloud environments

SOC 2 is the most common compliance requirement for SaaS companies and cloud service providers. In cloud environments, SOC 2 auditors evaluate your controls over the cloud infrastructure you manage, not the provider’s infrastructure. You reference the provider’s SOC 2 report (as a subservice organization) to cover the controls they own. The practical challenge is demonstrating that your cloud controls over access management, change management, logical security, and availability are designed and operating effectively throughout the observation period. Cloud-native logging (CloudTrail, Azure Monitor, GCP Cloud Audit Logs) becomes your primary evidence source.

ISO 27001 for cloud

ISO 27001 certification requires an information security management system (ISMS) that covers your cloud environments. Annex A controls must be implemented across your cloud infrastructure, with the Statement of Applicability mapping each control to the specific cloud implementation. ISO 27017 provides additional cloud-specific guidance, and ISO 27018 addresses protection of personally identifiable information in public clouds. The combination of 27001 + 27017 + 27018 provides the most comprehensive ISO-based cloud security compliance posture.

FedRAMP

FedRAMP (Federal Risk and Authorization Management Program) is mandatory for any cloud service offering sold to U.S. federal agencies. It is built on NIST SP 800-53 controls at three impact levels: Low (125 controls), Moderate (325 controls), and High (421 controls). FedRAMP authorization is resource-intensive, typically taking 12 to 18 months for the initial authorization with ongoing continuous monitoring requirements. Cloud services pursuing FedRAMP must demonstrate controls across 17 domains including access control, audit and accountability, configuration management, and incident response.

HIPAA in cloud

HIPAA compliance for cloud-hosted protected health information (PHI) requires a Business Associate Agreement (BAA) with the cloud provider, encryption of PHI at rest and in transit, access controls that enforce minimum necessary access, audit logging of all access to PHI, and documented breach notification procedures. All three major providers offer HIPAA-eligible services and BAAs, but not every service within each provider is HIPAA-eligible. Your architecture must confine PHI to eligible services and enforce access boundaries through IAM policies and network controls.

PCI DSS in cloud

PCI DSS applies when cardholder data is stored, processed, or transmitted through cloud infrastructure. Version 4.0 requires explicit documentation of cloud-specific controls including multi-factor authentication for all access to the cardholder data environment, network segmentation between in-scope and out-of-scope cloud resources, and targeted risk analysis for each requirement. The cloud-specific challenge is scoping: without clear network boundaries, defining where the cardholder data environment begins and ends requires careful architecture and continuous validation.

Cloud-specific controls that auditors evaluate

Regardless of which framework applies, auditors evaluating cloud environments focus on a consistent set of control categories. These are the areas where cloud-specific implementation differs most from on-premises.

Encryption at rest and in transit

Every major compliance framework requires encryption, but cloud encryption has nuances. At rest, the question is not just whether data is encrypted but who controls the keys. Provider-managed keys satisfy some frameworks; others require customer-managed keys (CMKs) in services like AWS KMS, Azure Key Vault, or GCP Cloud KMS. In transit, TLS 1.2 or higher is the minimum standard. Internal service-to-service communication within your cloud environment also needs encryption, not just external-facing traffic. Document your key rotation schedule, key access policies, and the specific encryption standards (AES-256 for at rest, TLS 1.2+ for in transit) in your compliance evidence.

Identity and access management

IAM is the most audited control domain in cloud compliance. Auditors evaluate least-privilege enforcement (are permissions scoped to what each role actually needs?), separation of duties (can a single user both deploy infrastructure and approve the deployment?), MFA enforcement (is it required for all human access, especially privileged accounts?), service account governance (are machine identities managed with the same rigor as human identities?), and access review cadence (how often are permissions reviewed and excessive access revoked?). Strong identity and access management practices prevent the most common class of cloud compliance findings.

Logging and monitoring

Compliance frameworks universally require audit logging, but cloud environments generate log volume at a scale that traditional SIEM approaches struggle with. CloudTrail, Azure Activity Log, and GCP Cloud Audit Logs must be enabled across all accounts and regions, configured for immutable storage (prevent tampering), retained for the period required by the applicable framework (typically 90 days to one year, longer for some regulated industries), and actively monitored for security-relevant events. The logging infrastructure itself must be secured against modification by the accounts it monitors.

Network segmentation

Cloud network segmentation uses VPCs, subnets, security groups, and network ACLs rather than physical firewalls and VLANs. Compliance frameworks require segmentation between environments (production vs. development), between trust levels (public-facing vs. internal), and between compliance scopes (PCI cardholder data environment vs. general infrastructure). In cloud, segmentation is defined in code and can drift if not continuously validated. Data security compliance requirements often dictate specific segmentation patterns based on data classification.

Compliance-as-code

Manual compliance processes do not scale in cloud environments. When your team can provision a new database or modify a security group in seconds, a compliance process that relies on quarterly reviews will always lag behind the infrastructure it governs. Compliance-as-code addresses this gap by encoding compliance requirements as machine-readable policies that evaluate automatically.

How compliance-as-code works

The approach treats compliance rules the same way you treat application code: written in a policy language, version-controlled, tested, and deployed through a pipeline. When a developer submits a Terraform plan that creates an S3 bucket without encryption, a policy evaluation tool blocks the deployment before it reaches the cloud. When an existing resource drifts out of compliance (someone disables logging on a production database), continuous scanning detects the drift and generates an alert or auto-remediates.

Common tooling includes Open Policy Agent (OPA) with Rego policies for cross-platform policy evaluation, HashiCorp Sentinel for Terraform-specific policy enforcement, AWS Config Rules and Conformance Packs for AWS-native compliance checks, Azure Policy for Azure resource governance, and GCP Organization Policy Service for GCP guardrails.

What compliance-as-code replaces and what it does not

Compliance-as-code replaces manual configuration reviews, spreadsheet-based control tracking, and screenshot-based evidence collection. It does not replace the judgment required to interpret framework requirements, the human review needed for access recertification, or the governance processes that determine which policies to enforce. Think of it as the enforcement and evidence layer, not the strategy layer.

The compliance-as-code artifacts themselves become audit evidence. Auditors can review the policy definitions (what you enforce), the evaluation results (what passed and failed), and the remediation records (how failures were addressed). This produces more comprehensive and reliable evidence than manual processes, and it generates that evidence continuously rather than during annual assessment sprints.

CSPM for continuous compliance

Cloud Security Posture Management (CSPM) tools provide the continuous monitoring layer that modern cloud compliance requires. Where compliance-as-code prevents non-compliant resources from being deployed, CSPM catches existing misconfigurations, configuration drift, and resources that were provisioned outside the standard pipeline.

What CSPM evaluates

CSPM platforms scan cloud infrastructure against compliance benchmarks (CIS, NIST, PCI DSS, HIPAA, SOC 2), identify misconfigurations (public storage buckets, overly permissive security groups, disabled logging), map IAM relationships to identify privilege escalation paths, and track compliance posture over time. The output is a continuously updated compliance dashboard showing which controls pass, which fail, and the trend of compliance posture across environments.

Selecting a CSPM for compliance

The choice depends on your environment. If you run a single cloud provider and need basic compliance monitoring, the provider-native tools (AWS Security Hub, Microsoft Defender for Cloud, GCP Security Command Center) may suffice. For multi-cloud environments or deeper compliance automation, third-party platforms (Wiz, Prisma Cloud, Orca Security, Lacework) provide normalized visibility across providers and more sophisticated policy engines. Evaluate CSPM tools against the specific compliance frameworks you must satisfy, not just their feature lists.

For a deeper comparison of CSPM capabilities and selection criteria, see the CSPM definition guide.

Multi-cloud compliance challenges

Operating across multiple cloud providers multiplies compliance complexity. Each provider implements security services differently, uses different terminology, and structures IAM, networking, and logging in provider-specific ways.

Inconsistent control implementations

A security group in AWS is not the same construct as a network security group in Azure or a firewall rule in GCP. Encryption key management works differently in KMS, Key Vault, and Cloud KMS. IAM policies use different syntax, permission models, and inheritance patterns. Your compliance program must map each framework requirement to the specific implementation in each provider, which means maintaining three sets of technical controls and three sets of evidence collection processes.

Unified compliance strategy

The practical solution is a control framework that abstracts provider-specific implementations behind a consistent set of compliance requirements. Map each framework requirement (for example, “encrypt data at rest with customer-managed keys”) to the specific service and configuration in each provider (AWS KMS CMK, Azure Key Vault customer-managed key, GCP Cloud KMS CMEK). Maintain this mapping in a single compliance matrix that auditors can review. CSPM tools with multi-cloud support help by normalizing findings across providers into a consistent format.

When multi-cloud is unavoidable

Multi-cloud is often a business reality rather than an architectural choice. Acquisitions bring different providers into the environment. Specific workloads require provider-specific services (GCP for ML, AWS for certain managed services). Regulatory requirements may mandate data residency in regions only available from certain providers. When multi-cloud is unavoidable, invest in the unified control framework rather than fighting the complexity. The cost of maintaining consistent compliance across providers is lower than the cost of compliance failures from ungoverned environments.

Preparing for a cloud compliance audit

Audit preparation in cloud environments differs from traditional audits because the evidence is generated differently and the scope is harder to define. These practices reduce audit friction and improve outcomes.

Define scope precisely

Scope creep is the most common source of audit cost overruns in cloud environments. Define exactly which cloud accounts, subscriptions, or projects are in scope. Identify which services within those accounts handle regulated data. Document the shared responsibility boundary for each service type. Provide the auditor with the cloud provider’s compliance reports (SOC 2, ISO 27001) that cover the provider’s side of shared responsibility. The clearer your scope documentation, the faster the audit proceeds.

Automate evidence collection

Cloud compliance audits require evidence across dozens of control domains: IAM policies, encryption configurations, network rules, logging settings, change management records, incident response documentation. Collecting this evidence manually is slow, error-prone, and produces stale snapshots. Automate evidence collection through CSPM dashboards, compliance-as-code evaluation reports, and API-generated configuration exports. An IT compliance audit runs significantly faster when the evidence is machine-generated and continuously updated.

Address the common findings proactively

Certain findings appear in nearly every cloud compliance audit. Overly permissive IAM policies (wildcard permissions, unused admin accounts). Unencrypted storage resources (S3 buckets, database snapshots, EBS volumes). Insufficient logging (CloudTrail disabled in non-primary regions, log retention below framework requirements). Missing MFA on privileged accounts. Network resources accessible from the public internet that should not be. Run your CSPM scans against the applicable compliance benchmark before the audit begins and remediate the findings the auditor will inevitably flag.

Maintain continuous readiness

The organizations that dread audits are the ones that sprint to prepare for them. The organizations that treat audits as routine have built continuous compliance into their operations. CSPM monitoring runs daily. Policy-as-code prevents non-compliant deployments. Evidence is generated automatically from cloud APIs and stored in a compliance evidence repository. Access reviews happen on schedule, not in the week before the auditor arrives. When compliance is continuous, the audit becomes a validation exercise rather than a remediation project.

How a fractional CISO navigates cloud compliance

Cloud compliance sits at the intersection of security architecture, regulatory interpretation, and operational execution. It requires someone who understands the technical details of cloud security controls, the specific requirements of each applicable framework, and the practical constraints of engineering teams that need to ship product without waiting for compliance approval.

A fractional CISO brings this cross-functional expertise without the cost of a full-time executive hire. For growth-stage companies pursuing their first SOC 2, Series B companies entering regulated industries, or mid-market organizations migrating production workloads to the cloud, a fractional CISO provides the strategic direction that keeps compliance on track: selecting the right frameworks, designing the control architecture, choosing tooling, building the compliance-as-code pipeline, preparing the team for audits, and translating audit findings into prioritized remediation plans.

The alternative is learning through audit findings, which is more expensive and slower than getting the architecture right the first time.