top of page
Search

What Is Cloud Compliance? Frameworks, Risks, Best Practices & Tools (2026)

5 hours ago
25 min read
Cloud compliance, data protection, and regulatory standards.

Moving a workload to the cloud does not move the obligation to prove that it is protected, lawful, and well run. Regulators, auditors, and enterprise customers still ask the same questions: where does the data live, who can reach it, what evidence shows the controls work, and who is accountable when they do not. Cloud compliance is the discipline of answering those questions continuously, on cloud infrastructure that changes by the hour and is shared with a provider. This guide explains how it works, which frameworks matter in 2026, where programs fail, and how to choose tools.


TL;DR


  • Cloud compliance means meeting the legal, regulatory, contractual, and standards-based requirements that apply to cloud-hosted systems and data, and proving it with evidence that stays current.

  • Provider certifications and audit reports cover the provider's side only. Customers still own configuration, identity, data, logging, and governance for their own workloads.

  • Frameworks overlap heavily. Map obligations once to a unified control set instead of running a separate program for each of ISO 27001, SOC 2, PCI DSS, HIPAA, and GDPR.

  • Several standards changed recently: ISO/IEC 27017:2026, ISO/IEC 27018:2025, CSA CCM v4.1, and FedRAMP's Consolidated Rules for 2026. Verify the current version before scoping any audit.

  • Automation collects evidence and detects drift, but accountability stays with named owners. Choose tools by the job: audit workflow, technical posture, or both.


What Is Cloud Compliance? (Quick Answer)


Cloud compliance is the practice of meeting the laws, regulations, standards, and contractual requirements that apply to data and systems hosted in cloud services, and proving it with evidence. It covers scoping, shared-responsibility ownership, control implementation, continuous monitoring, and audit readiness across providers and workloads.

Table of Contents



What Is Cloud Compliance?


Cloud compliance is the ongoing work of meeting the requirements that apply to systems and data hosted in cloud services, and being able to show an assessor that the controls behind those requirements exist and operate. The term covers several kinds of obligation, which is why it is easy to misuse.


What organizations are actually complying with


  • Laws and regulations, such as the GDPR for personal data in the EU, the HIPAA Security Rule for electronic protected health information, or DORA for EU financial entities.

  • Contractual and industry requirements, such as PCI DSS, which payment brands and acquirers enforce through contracts rather than statute.

  • Voluntary standards and assurance reports that customers request, including ISO/IEC 27001 certification and SOC 2 reports.

  • Internal policies and customer commitments, such as retention periods, encryption rules, or data-residency promises in a service agreement.


Control, evidence, scope, and operation


Four terms carry most of the weight. A control is a safeguard that satisfies a requirement, such as enforcing multi-factor authentication for administrators. Evidence is the record that the control works: a configuration export, a log, a ticket, or an access review. Scope defines which accounts, applications, data, and vendors an assessment covers. Operation means the control keeps working after the first audit, which matters most in cloud environments where resources are created and deleted constantly.


Because the cloud is software-defined, much of this evidence can come from provider APIs and configuration history instead of screenshots. That makes continuous compliance practical, a subject covered later in this guide. For the underlying technology, see Articsledge's overview of cloud computing.


Why Cloud Compliance Matters


Cloud compliance matters because obligations follow data wherever it is stored, and cloud adoption is now the default for most organizations. The practical stakes fall into five groups.


  • Regulatory exposure. Under Article 83 of the GDPR, the most serious infringements can draw administrative fines of up to €20 million or 4% of worldwide annual turnover, whichever is higher. Sector regimes add their own penalties.

  • Customer trust and procurement. Enterprise buyers commonly ask for a SOC 2 report, an ISO/IEC 27001 certificate, or a security questionnaire before signing. Missing evidence slows deals.

  • Contractual duties. Data processing agreements, service-level terms, and security addenda turn expectations into enforceable promises.

  • Market access. Selling to U.S. federal agencies requires FedRAMP certification, and accepting card payments requires PCI DSS validation. See also Articsledge's explainer on government cloud.

  • Risk reduction and resilience. Controls built for compliance, such as access control, logging, tested backups, and incident response, also reduce breach likelihood and recovery time.


Keep these claims proportionate. Meeting a framework lowers specific risks and produces evidence. It does not make an organization breach-proof, and the next section explains why.


Cloud Compliance vs. Cloud Security, Governance, and Risk Management


Cloud compliance asks whether required controls exist and can be proven. Cloud security asks whether systems are actually protected against threats. Governance sets the rules and ownership. Risk management decides which risks to accept, reduce, or transfer. They overlap, but none replaces the others.


How the four disciplines differ


  • Compliance is measured against external or contractual requirements. Its output is evidence and assurance reports.

  • [Cloud security](cloud-security) is measured against threats. Its output is reduced exposure and faster detection.

  • [Cloud governance](cloud-governance) defines policies, roles, guardrails, and accountability, usually through a cloud operating model.

  • Risk management prioritizes by likelihood and impact, including risks that no framework names.


Why passing an audit is not proof of security


A control can satisfy a requirement on paper and still leave a gap in practice. A framework may not cover a threat relevant to your architecture, and a point-in-time audit says little about the weeks that follow. The reverse also happens: a strong security team can defend well and still fail an audit because evidence, scope, or policy documentation is missing.


Treat compliance as a floor that produces proof, and security as the work that raises the ceiling. For runtime and architecture depth, see Articsledge's guide to cloud-native security.


The Shared Responsibility Model and Who Owns What


Under the shared responsibility model, the cloud provider secures the underlying cloud platform, and the customer secures what it configures, deploys, and stores on it. Where the line falls depends on the service model, so document it per service instead of assuming it. AWS, Microsoft Azure, and Google Cloud each publish their own version, and their wording differs.


The table below summarizes typical ownership across IaaS, PaaS, and SaaS. Treat it as a starting point and confirm each service in provider documentation.


Area

IaaS

PaaS

SaaS

Physical facilities and hardware

Provider

Provider

Provider

Guest OS patching and hardening

Customer

Provider for managed runtimes

Provider

Application code and its security

Customer

Customer

Provider

Identity, MFA, roles, and access reviews

Customer

Customer

Customer (tenant settings)

Data classification, encryption choices, key management

Customer

Customer

Customer, within provider options

Service configuration

Customer

Customer

Customer (tenant settings)

Logging, monitoring, and retention

Shared: provider offers services, customer enables and retains

Shared

Shared: customer exports and retains audit logs

Backup and recovery testing

Customer

Shared

Shared; confirm vendor terms

Incident response and vendor oversight

Shared

Shared

Shared


Two points matter most. Customer data, identities, and access remain the customer's responsibility in every model. And a provider's SOC 2 report, ISO certificate, or PCI DSS attestation covers the provider's controls within its stated scope. It does not certify the customer's configuration.


Customers inherit provider controls only for the services and regions in scope. Record which controls are inherited, which are shared, and which are yours, and name an owner for each. Auditors will ask.


Major Cloud Compliance Frameworks, Standards, and Regulations


Start with the vocabulary, because the terms are not interchangeable. A law or regulation is binding and enforced by authorities. A contractual requirement is binding through agreements. A standard or framework is guidance, and a control catalog lists safeguards. A certification is issued by an accredited body, an attestation or examination report is issued by an auditor, and an authorization or program certification is granted by a government program.


Name and type

Applies to

Focus and cloud relevance

Assurance status

ISO/IEC 27001:2022 (standard)

Any organization

Information security management system built on risk assessment

Accredited third-party certification

ISO/IEC 27017:2026 (guidance standard)

Cloud customers and providers

Cloud-specific controls and guidance on top of ISO/IEC 27002; edition 2 published July 2026

Guidance; ask your certification body how it is assessed

ISO/IEC 27018:2025 (guidance standard)

Public cloud providers acting as PII processors

Protecting personal data in public cloud; edition 3 aligned to ISO/IEC 27002:2022

Guidance; ask your certification body how it is assessed

SOC 2 (AICPA Trust Services Criteria)

Service organizations

Security, availability, processing integrity, confidentiality, privacy

CPA examination report, Type 1 or Type 2; not a certification

NIST CSF 2.0 (voluntary framework)

Any organization

Outcome-based cybersecurity risk management, including a Govern function

No certification

NIST SP 800-53 Rev. 5, Release 5.2.0 (control catalog)

Federal systems and many others

Security and privacy controls; basis of FedRAMP baselines

No certification; assessed under programs

FedRAMP (U.S. government program)

Cloud services sold to federal agencies

Standardized security assessment and continuous monitoring

Program certification under 2026 rules

CSA CCM v4.1, CAIQ, STAR (control framework and registry)

Cloud providers and customers

207 controls in 17 domains; CAIQ has 283 questions

STAR Level 1 self-assessment; Level 2 through third-party assessment

CIS Controls v8.1 (safeguards)

Any organization

Prioritized safeguards with a Cloud Companion Guide

No certification

PCI DSS v4.0.1 (industry standard)

Entities handling payment card data

Protecting cardholder data environments

Validation by assessor or self-assessment, per card brand rules

HIPAA Security Rule (U.S. regulation)

Covered entities and business associates

Safeguards for electronic protected health information

No government certification; OCR enforces

GDPR (EU regulation)

Controllers and processors handling EU personal data

Lawful processing, security, processor contracts, transfers

An obligation; approved codes or certifications may help demonstrate it

DORA (EU regulation)

EU financial entities and critical ICT providers

ICT risk, incident reporting, third-party risk

Supervisory regime; applies since 17 January 2025

NIS2 (EU directive)

Essential and important entities

Cybersecurity risk measures and incident reporting

National transposition and supervision


Version and status notes worth checking


FedRAMP. FedRAMP published its Consolidated Rules for 2026 on June 25, 2026. According to the Cloud Security Alliance's research note, the rules make FedRAMP 20x the standard path and mandatory for all stakeholders from January 1, 2027, with grace periods ending February 1, 2028. FedScoop reports that impact levels give way to certification classes A through D and that Rev5 stays available until June 11, 2027. Confirm details on fedramp.gov before planning.


HIPAA. HHS published a proposed update to the Security Rule on January 6, 2025, described on the HHS NPRM page. It is a proposal, not a final rule. The current Security Rule remains in effect, and HIPAA Journal reports that a final rule has been pushed to mid-2027. HHS also publishes cloud computing guidance for regulated entities.


Other changes. ISO/IEC 27017:2026 and ISO/IEC 27018:2025 are the current editions. CSA CCM v4.1 replaced v4.0.x, and the STAR transition timeline accepts both versions until December 2027. NIST SP 800-53 Release 5.2.0 added software-update controls in August 2025. PCI DSS v4.0.1 is the current version, and its future-dated requirements became mandatory after March 31, 2025, per the PCI Security Standards Council. SOC 2 uses the 2017 Trust Services Criteria with revised points of focus from 2022, per the AICPA.


EU law. The European Commission's Digital Omnibus package and its January 2026 NIS2 amendment proposal are proposals still moving through Parliament and Council. GDPR, DORA, and NIS2 remain the binding texts, and NIS2 obligations depend on each member state's transposition. Applicability turns on sector, size, and role, so confirm with counsel.


How Deployment and Service Models Change Compliance


Deployment and service models change three things: who owns each control, what evidence is available, and how large the audit scope becomes. The more infrastructure a customer controls, the more it must evidence.


  • [Public cloud](public-cloud). Providers supply attestations and reports for their services, and customers inherit what is in scope. Multi-tenancy makes tenant isolation and configuration the key evidence topics.

  • [Private cloud](private-cloud) and [hosted private cloud](hosted-private-cloud). The organization or its host owns more layers, so there is more to evidence but also more control over scope and data location.

  • [Hybrid cloud](hybrid-cloud) and [multi-cloud](multicloud). Each environment has different logs, identity models, and policy engines. Compliance effort grows with inconsistency, which is why a unified control set matters.

  • Containers, Kubernetes, and serverless. Resources are ephemeral, so evidence must come from configuration history, admission policies, and logs rather than from inspecting servers. See Articsledge's guides to Kubernetes, containerization, and function as a service.

  • SaaS. The customer's scope shrinks to tenant configuration, identity, data, and vendor management. SaaS management practices help find unapproved applications that fall outside any assessment.


Biggest Cloud Compliance Risks and How to Reduce Them


Most cloud compliance failures trace back to a short list of causes: configuration, identity, visibility, and ownership. The table maps each risk to its likely consequence and a practical mitigation.


Risk

Likely consequence

Mitigation

Misconfiguration and configuration drift

Exposed services and failed control tests

Secure baselines, policy as code, drift alerts

Excessive permissions

Unauthorized access and failed access reviews

Least privilege, role reviews, time-limited elevation

Credential compromise

Account takeover and data exposure

MFA, short-lived credentials, secrets vault

Exposed storage and data

Breach notification and regulatory action

Block public access, classify data, encrypt

Weak asset inventory and shadow cloud or SaaS

Systems outside scope and unmanaged data

Account governance, continuous discovery

Data residency and cross-border movement

Unlawful transfers and contract breaches

Region restrictions, data maps, transfer assessments

Insecure APIs

Data leakage and abuse

Authentication, rate limits, API inventory

Encryption and key management failures

Exposed or unrecoverable data

Managed key lifecycle, rotation, separation of duties

Logging gaps

Incidents that cannot be investigated or proven

Central, protected logs with defined retention

Unpatched workloads

Exploitable vulnerabilities

Scanning, patch timelines, hardened images

Third-party and supply-chain risk

Inherited control failures

Vendor tiering and evidence review

Insecure CI/CD

Tampered or noncompliant deployments

Pipeline access controls, signed artifacts, IaC scanning

Ephemeral resources

Lost evidence of past state

Configuration history, snapshots, retention rules

Multi-cloud inconsistency

Duplicate effort and uneven coverage

One control set mapped to each platform

Weak exceptions, unclear ownership, incident-response gaps

Indefinite risk acceptance and slow response

Expiry dates, named owners, tested runbooks


Data exposure deserves special attention because it triggers notification duties. Articsledge's explainer on data leakage covers common causes, and network security fundamentals still apply inside virtual networks such as a virtual private cloud.


How to Build a Cloud Compliance Program


A cloud compliance program works best as a repeatable sequence: decide what applies, bound it, build controls once, assign owners, and keep evidence flowing. The steps below fit organizations of any size.


  1. Determine obligations. List the laws, contracts, customer commitments, and standards that apply, by jurisdiction, sector, data type, and role such as controller, processor, or business associate. Involve legal counsel.

  2. Define scope. Name the in-scope accounts, regions, applications, data stores, and vendors. A smaller, well-bounded scope costs less to assess.

  3. Inventory and classify. Build an inventory of accounts, cloud resources, workloads, applications, data, and vendors, then classify data by sensitivity.

  4. Map requirements to a unified control set. Write each safeguard once and map it to every framework it satisfies, using published crosswalks such as the NIST SP 800-53 mappings to ISO/IEC 27001 or the CSA CCM mappings.

  5. Assign owners and boundaries. Give every control a named owner and record whether it is inherited from the provider, shared, or implemented by you.

  6. Establish secure baselines. Define hardened configurations and guardrails, ideally through a cloud landing zone that new accounts inherit.

  7. Implement identity controls. Use SSO or federation, MFA, least privilege, separation of duties, and scheduled access reviews.

  8. Protect data, keys, and secrets. Apply encryption, key management, secrets management, retention, and residency rules based on classification.

  9. Centralize logging and monitoring. Collect logs from every in-scope account, protect them from tampering, and set retention to match requirements.

  10. Secure delivery. Put infrastructure as code, peer review, scanning, and approvals into the DevOps pipeline so changes carry their own evidence.

  11. Collect evidence and test controls. Automate collection where possible, define test frequency, and sample results the way an auditor would.

  12. Manage exceptions, remediate, and prepare. Time-box exceptions with compensating controls, track remediation to closure, run a readiness review, then monitor continuously.


If the program starts during a cloud migration, build these controls into each migration wave instead of retrofitting them afterward.


Cloud Compliance Best Practices


The practices below reduce both audit friction and real risk. They are grouped by the area they protect.


Identity and access


  • Grant least privilege, review privileged roles on a schedule, and remove standing administrator access where practical.

  • Use SSO or federation with MFA for every human user, and separate duties so no one person can request, approve, and deploy a sensitive change.


Data protection


  • Drive encryption and retention from data classification. Use provider-managed keys where risk allows, and customer-managed or HSM-backed keys where regulation, contracts, or custody requirements demand them. Plan for key loss and rotation.

  • Store secrets in a managed vault, never in code or tickets. Test backups and recovery, including for disaster recovery scenarios, because an untested backup is not evidence.


Configuration and change


  • Adopt hardened baselines such as the CIS Benchmarks, and manage them with configuration management so changes are recorded.

  • Run vulnerability and patch management with defined timelines, centralize logs with documented retention, and require change records for production.


Operations and oversight


  • Maintain tested incident response runbooks that include provider contacts and regulator notification steps.

  • Tier suppliers by risk and review their assurance reports. Articsledge's guide to vendor management software shows how teams track this.

  • Automate evidence collection, and still run periodic human control testing to catch what automated checks miss.


Continuous Cloud Compliance


Continuous cloud compliance means testing controls on an ongoing basis and collecting evidence as systems change, instead of assembling proof once a year.


Point-in-time versus continuous assurance


An annual audit samples a period, while cloud resources change daily. Configuration drift, such as a storage setting changed during an incident, can open a gap that no annual review would catch. Continuous monitoring shortens the time between a control failing and someone knowing.


How continuous compliance works


  • Cloud APIs and event-driven checks read configuration and react to changes as they happen.

  • Policy as code and compliance as code express rules in version control so they can be tested, reviewed, and enforced in pipelines and at runtime. See cloud automation and cloud orchestration for context.

  • IaC scanning blocks noncompliant templates before deployment.

  • Alerting and remediation guardrails route failures to owners. Reserve automatic remediation for low-risk, reversible fixes.

  • Exception handling and tuning record approved deviations with expiry dates and reduce false positives so teams trust the alerts.


Automation supports accountability but does not replace it


Software can collect evidence and flag drift. It cannot decide scope, accept risk, or interpret a regulation. Every control still needs a human owner, and every automated test should itself be reviewed periodically to confirm it checks the right thing.


AWS, Microsoft Azure, and Google Cloud Compliance Capabilities


AWS, Microsoft Azure, and Google Cloud each offer compliance documentation, governance services, and posture tooling. None of them makes a customer workload compliant on its own, and service names and availability change, so verify them in current documentation.


Amazon Web Services


On Amazon Web Services, customers can download third-party audit reports through AWS Artifact. AWS Config records resource configuration, and AWS Security Hub CSPM runs standards-based checks that rely on AWS Config rules for most controls. One change deserves attention: AWS Audit Manager stopped accepting new customers on April 30, 2026. Existing customers can keep using it in configured accounts and regions, but AWS is adding no new features or frameworks, and its documentation points to AWS Config conformance packs as an alternative with different evidence handling.


Microsoft Azure


Microsoft's Defender for Cloud regulatory compliance dashboard shows which compliance standards are enabled, lets teams work through failing recommendations, and exports point-in-time reports. Per Microsoft's documentation, its compliance data integrates with Microsoft Purview Compliance Manager, including standards that monitor AWS and Google Cloud environments.


Google Cloud


Google Cloud's Compliance Manager uses software-defined cloud controls to assess support for compliance programs across an organization, with built-in frameworks and the option to create custom controls. Assured Workloads frameworks apply controls for data residency, access, and personnel to folders and projects, and some Compliance Manager frameworks within them require a Security Command Center Premium or Enterprise subscription.


Provider programs reduce the evidence customers must produce for inherited controls. They do not reduce the controls customers must run. Check every service against the provider's scope lists before relying on it, and see Articsledge's comparison of cloud market share and its overview of cloud platforms for context.


Cloud Compliance Tools: Categories and Representative Options


Cloud compliance tools do two broad jobs: they manage the compliance program and its audit evidence, and they assess the technical posture of cloud resources. Many organizations need both, and few single products do both equally well.


Tool categories


  • GRC and compliance management. Controls, policies, risks, crosswalks, and audit workflows.

  • Compliance and evidence automation. Connectors to cloud, identity, HR, code, and ticketing systems that test controls and collect evidence.

  • CSPM and CNAPP. Cloud security posture management scans configuration. A cloud-native application protection platform adds workload, identity, data, and code context.

  • Cloud-native governance and policy. Provider services such as compliance dashboards and policy engines.

  • Audit and evidence tools. Repositories and auditor portals for requests and sampling.

  • Policy-as-code and IaC scanning. Checks templates and pipelines before deployment.

  • SIEM and security analytics. Log collection, detection, and retention that support incident response and evidence.

  • DSPM and adjacent tools. Data discovery and classification where data location drives scope.


A representative, non-exhaustive comparison


The table reflects first-party descriptions reviewed in October 2026. Inclusion is not an endorsement or a ranking, and capabilities are the vendors' own statements, so confirm them in a trial. Pricing depends on scope and contract and requires vendor confirmation.


Tool

Category

Best-fit use case

Verified capability and buyer question

Vanta

Compliance automation and GRC

Teams pursuing SOC 2, ISO 27001, HIPAA, or GDPR

Vendor states 35+ frameworks and 400+ integrations. Ask how cloud tests map to custom controls.

Drata

Compliance automation and GRC

Multi-framework programs wanting automated control mapping

Vendor describes continuous monitoring, evidence collection, and a trust center. Ask about custom frameworks and exports.

Secureframe

Compliance automation

Teams wanting automation plus expert guidance

Vendor lists automated tests, continuous monitoring, and asset inventory. Ask about test customization.

Hyperproof

GRC and compliance operations

Programs with overlapping frameworks

Vendor states 160+ frameworks and 200+ integrations, including AWS and Azure. Ask about technical posture depth.

Wiz

CNAPP and CSPM

Multi-cloud posture with risk context

Vendor describes a graph connecting code, cloud, and runtime. It joined Google Cloud on March 11, 2026; confirm roadmap and framework coverage.

Prisma Cloud

CNAPP

Enterprises needing posture across clouds

Docs describe compliance dashboards and custom standards and checks. Ask how reports map to your frameworks.

Orca Security

CNAPP and CSPM

Agentless posture across cloud estates

Vendor materials describe agentless scanning and multi-framework reporting. Ask about framework versions.

Prowler

Open-source cloud security checks

Teams wanting transparent, inspectable checks

Vendor states an Apache 2.0 open-source core and 70+ frameworks. Ask about operating effort.

AWS Security Hub CSPM with AWS Config

Cloud-native posture

AWS-centered estates

Standards-based checks built on AWS Config rules. Scope is AWS.

Microsoft Defender for Cloud

Cloud-native posture

Azure-centered estates, with multicloud views

Regulatory compliance dashboard and Purview Compliance Manager integration.

Google Cloud Compliance Manager

Cloud-native governance

Google Cloud estates

Software-defined controls, frameworks, and reports; some features need Security Command Center Premium or Enterprise.


Notice the split. Compliance automation platforms excel at policies, personnel evidence, and auditor workflows. Posture platforms excel at deep technical checks across cloud resources. Product sources for this table are listed under Sources & References, and for log-focused evidence see Articsledge's guide to audit trail software.


How to Choose a Cloud Compliance Tool


Choose by the job you need done, then test with your own environment. A feature list proves little until it runs against your accounts and your auditor's requests.


  • Coverage. Which frameworks and versions are supported? Does it cover AWS, Azure, Google Cloud, SaaS, and hybrid scope? Are crosswalks and custom controls available?

  • Evidence depth. What does it collect automatically, through which integrations: identity, ticketing, source control, CI/CD, endpoint, and HR systems? Does it detect drift continuously or on a schedule?

  • Scope of function. Is it workflow-only, or does it include CSPM or CNAPP posture checks? Do you need both categories?

  • Governance features. Look for role-based access, its own audit logs, exception workflows, false-positive tuning, and auditor collaboration.

  • Data handling and portability. How is tenant data protected, what permissions does it need in your cloud accounts, and can you export evidence and control history if you leave?

  • Cost and effort. Compare the pricing unit, such as per employee, account, or asset, and how it scales. Ask about implementation effort and the support model.


Run a proof of value


Run a time-boxed trial against one real account and one framework. Ask the vendor to connect read-only, show how a failed control becomes a ticket with an owner, export evidence for a sample audit request, and explain every permission it requires. Then compare the output with what your auditor expects.


Audit Readiness and Evidence


Audit readiness means any in-scope control can be explained, tested, and evidenced on request by someone other than the person who built it. It depends on evidence that is current, attributable, and easy to retrieve.


Evidence types


  • Policies and procedures that are approved, versioned, and acknowledged by the people they bind.

  • Configuration evidence such as exports, infrastructure-as-code definitions, and resource configuration history.

  • Operational records such as logs, tickets, change approvals, and incident reports.

  • Access reviews that show the reviewer, the date, and what changed as a result.

  • Vendor assurance such as provider audit reports and supplier questionnaires.


Machine evidence versus screenshots


Timestamped evidence pulled from cloud APIs is harder to dispute and cheaper to refresh than screenshots, which are static, easy to misdate, and hard to sample. Use screenshots only where no export exists, and record who captured them and when.


Working with auditors


  • Control owners. Name them in advance, and assign evidence duties to the CloudOps or platform team that owns the change.

  • Sampling. Auditors select samples from populations, so keep complete lists of users, changes, incidents, and assets ready.

  • Exceptions and remediation. Document each exception with its approver, compensating control, and expiry, and track every finding to closure with proof.

  • Access and retention. Give auditors read-only, time-limited access, keep evidence fresh, and retain it for as long as each requirement demands.


Cloud Compliance Metrics: KPIs and KRIs


Metrics show whether controls keep working between audits. Define each measure precisely, track the trend, and set thresholds with risk owners, because no universal benchmark fits every organization.


  • Percentage of in-scope assets inventoried and owned.

  • Percentage of controls with current evidence.

  • Time to remediate critical misconfigurations.

  • Completion rate of privileged access reviews.

  • Encryption coverage and logging coverage across in-scope resources.

  • Percentage of infrastructure-as-code changes scanned before deployment.

  • Exception age and number of overdue findings.

  • Repeat findings and control-test pass and fail trends.


Common Cloud Compliance Mistakes


  • Treating provider compliance as customer compliance. A provider's report covers the provider's scope, not your configuration.

  • Running compliance as an annual project. Evidence gathered once a year hides drift between audits.

  • Leaving scope unclear. Unbounded scope inflates cost and creates surprises.

  • Duplicating controls across frameworks. Separate control sets for each framework multiply work and contradict each other.

  • Granting overprivileged IAM roles. Broad roles fail access reviews and widen breach impact.

  • Keeping a weak asset and data inventory. You cannot protect or evidence what you have not found.

  • Ignoring unmanaged SaaS. Unapproved applications can hold regulated data outside any assessment.

  • Leaving out developers and CI/CD. Pipelines are where most cloud changes originate.

  • Using spreadsheets for evidence at scale. They go stale and lack provenance.

  • Automating poor controls. Automation makes a weak control fail faster and at greater volume.

  • Managing exceptions loosely. Open-ended exceptions become permanent risk acceptance.

  • Assuming a passed audit means risk is gone. An audit tests selected controls over a period.


Cloud Compliance Checklist


  • List applicable laws, contracts, standards, and customer commitments, and confirm current versions.

  • Define and document scope, including accounts, regions, applications, data, and vendors.

  • Maintain an inventory with owners, and classify data.

  • Map requirements to one unified control set with named owners.

  • Document inherited, shared, and customer-owned controls for each service.

  • Enforce SSO, MFA, least privilege, and scheduled access reviews.

  • Encrypt data by classification, manage keys, and keep secrets in a vault.

  • Centralize protected logs with defined retention.

  • Scan infrastructure as code and gate production changes.

  • Test backups, recovery, and incident response, including regulator notification.

  • Automate evidence collection and monitor drift, with named alert owners.

  • Time-box exceptions, track remediation, and review metrics monthly.


Future Considerations


These directions are supported by current publications, but timelines can shift.


  • Continuous assurance and machine-readable controls. FedRAMP's 2026 rules are published in a machine-readable format, and the CSA offers a machine-readable bundle of CCM v4.1 in JSON, YAML, and OSCAL.

  • Data sovereignty. Expect more questions about where data and administrators sit. See Articsledge's explainer on sovereign cloud.

  • Evolving privacy and resilience rules. EU Digital Omnibus proposals and NIS2 transposition may change reporting duties, so monitor adoption rather than acting on drafts.

  • Software supply chain. NIST SP 800-53 Release 5.2.0 added controls on software updates and integrity.

  • AI workloads. Data governance and model controls are entering frameworks. Articsledge covers AI security governance and the NIST AI Risk Management Framework.

  • Control normalization across clouds. Unified control sets will matter more as organizations follow cloud computing trends toward multiple platforms.


FAQ


What is cloud compliance?


Cloud compliance is the practice of meeting the laws, regulations, standards, and contractual requirements that apply to data and systems in cloud services, and proving it with current evidence. It spans scoping, control ownership under the shared responsibility model, monitoring, and audit readiness. It is an ongoing operating process, not a single audit.


Is cloud compliance the same as cloud security?


No. Cloud security aims to protect systems from threats, while cloud compliance shows that required controls exist and operate. They overlap, but a secure environment can still fail an audit for missing evidence, and a compliant one can stay exposed to threats a framework does not cover. Treat compliance as a floor and security as the work above it.


Who is responsible for cloud compliance?


Responsibility is shared. The provider secures the platform and its own facilities. The customer is responsible for configuration, identity and access, data, encryption choices, logging, and application security, with the exact split depending on whether the service is IaaS, PaaS, or SaaS. The customer stays accountable to regulators and clients for its own workloads.


Is AWS, Azure, or Google Cloud automatically compliant?


No. Major providers publish audit reports and attestations for their own services and scope, which customers can inherit. A customer workload is compliant only if the customer configures and operates its controls correctly and the services used are within the relevant scope. Moving to a certified provider does not transfer compliance.


What are the most important cloud compliance frameworks?


It depends on your obligations. Common ones are ISO/IEC 27001, SOC 2, NIST CSF and SP 800-53, FedRAMP for U.S. federal sales, CSA CCM and STAR, CIS Controls, PCI DSS for card data, HIPAA for U.S. health data, and GDPR, DORA, and NIS2 for EU obligations. Start with legal and contractual requirements, then add voluntary frameworks customers expect.


What is the difference between SOC 2 and ISO 27001?


ISO/IEC 27001 is a standard for an information security management system, and an accredited certification body issues a certificate. SOC 2 is an examination by a licensed CPA firm that produces a report against the AICPA Trust Services Criteria, in Type 1 or Type 2 form. Many organizations pursue both, and a unified control set reduces duplicate work.


Does HIPAA certify cloud providers?


No. HHS does not certify cloud providers or services as HIPAA compliant. Covered entities and business associates must meet the Security Rule themselves, and HHS cloud guidance describes arrangements such as business associate agreements when a cloud provider handles electronic protected health information. Check current HHS guidance and consult counsel for specifics.


What does GDPR mean for cloud services?


The GDPR applies to controllers and processors handling personal data of people in the EU. Cloud use requires a compliant processor agreement, appropriate security measures, and a lawful basis for any transfers outside the EU. There is no single universal GDPR certificate for a cloud service, and roles depend on the facts, so confirm with counsel.


What is continuous cloud compliance?


Continuous cloud compliance means testing controls and collecting evidence on an ongoing basis, using cloud APIs, event-driven checks, and policy as code, instead of preparing once a year. It detects configuration drift quickly and keeps evidence current, while named people stay accountable for decisions and exceptions.


Can cloud compliance be fully automated?


No. Automation can collect evidence, test technical settings, detect drift, and route alerts. It cannot define scope, interpret regulations, approve exceptions, or cover procedures such as training and governance decisions. Responsibility stays with people, and automated tests should be reviewed periodically to confirm they check the right thing.


What should a cloud compliance tool do?


A useful tool supports your frameworks and versions, integrates with your clouds, identity, code, and ticketing systems, collects evidence automatically, detects drift, supports custom controls and exceptions, and lets auditors review evidence. Decide whether you need audit workflow, technical posture, or both, and confirm you can export your data.


How does multi-cloud make compliance harder?


Each cloud has its own identity model, logging, policy engine, and service names. Controls must be implemented and evidenced several times, and gaps appear where teams assume equivalence. A unified control set mapped to each platform, central logging, and consistent baselines reduce the burden.


What evidence is needed for a cloud audit?


Typical evidence includes approved policies, configuration exports and history, access review records, logs, change tickets, incident records, vendor assurance reports, and training records. Auditors sample from complete populations, so keep lists of users, changes, and incidents. Machine-generated, timestamped evidence is preferred to screenshots.


How often should cloud compliance be reviewed?


Review continuously through automated checks and monthly through metrics, then formally at least annually and whenever scope, regulations, architecture, or providers change. Also check standard versions, since several, including ISO/IEC 27017 and FedRAMP's rules, changed in 2025 and 2026. Your frameworks may set required review intervals.


Key Takeaways


  • Cloud compliance spans laws, contracts, standards, and commitments, and each carries different consequences and assurance paths.

  • Scope and ownership decisions drive cost more than any tool choice.

  • Customer data, identity, and configuration stay with the customer in every service model.

  • One unified control set mapped to many frameworks beats parallel programs.

  • Misconfiguration, excessive permissions, and missing logs are recurring causes of avoidable findings.

  • Status changes matter: HIPAA's Security Rule update is still proposed, FedRAMP is mid-transition, and ISO/IEC 27017 and CSA CCM have new editions.

  • Evidence should be machine-generated, timestamped, and owned by a named person.

  • Tools split into audit workflow and technical posture. Run a proof of value before buying.


Actionable Next Steps


  1. Confirm applicable obligations and current framework versions with legal and compliance leads.

  2. Define scope, inventory accounts, data, and vendors, and name an owner for each.

  3. Document shared responsibility for every service in scope using provider documentation.

  4. Build a unified control set and map it to your two most important frameworks.

  5. Fix identity first: SSO, MFA, least privilege, and a scheduled privileged access review.

  6. Centralize logs and enable baseline posture checks in each cloud's native tooling.

  7. Add infrastructure-as-code scanning and change approvals to the delivery pipeline.

  8. Choose tool categories, run a proof of value, then set a readiness review and monthly metrics.


Glossary


  • Attestation. An independent auditor's written conclusion about controls, such as a SOC 2 report.

  • CNAPP. Cloud-native application protection platform combining posture, workload, identity, data, and code security.

  • Cloud compliance. Meeting and proving the requirements that apply to cloud-hosted systems and data.

  • Compliance as code. Expressing compliance requirements as machine-checkable rules kept in version control.

  • Configuration drift. Unplanned divergence of a live configuration from its approved baseline.

  • Continuous compliance. Ongoing control testing and evidence collection instead of periodic preparation.

  • Control. A safeguard that satisfies a requirement.

  • CSP. Cloud service provider.

  • CSPM. Cloud security posture management: scanning cloud configuration for misconfigurations and policy violations.

  • Data residency. The requirement or choice to store data in a specific geography.

  • Data sovereignty. The principle that data is subject to the laws of the jurisdiction where it sits or the entity that controls it.

  • Evidence. Records showing that a control exists and operates.

  • GRC. Governance, risk, and compliance.

  • IaaS. Infrastructure as a service: rented compute, storage, and networking.

  • IaC. Infrastructure as code: defining infrastructure in version-controlled files.

  • IAM. Identity and access management.

  • Least privilege. Granting only the access needed for a task.

  • PaaS. Platform as a service: a managed runtime for building and running applications.

  • Policy as code. Rules written in code and enforced automatically in pipelines or runtime.

  • SaaS. Software as a service: applications delivered and operated by a provider.

  • Shared responsibility model. The division of security duties between provider and customer.

  • SIEM. Security information and event management: log collection, correlation, and alerting.


Sources & References


bottom of page