Compliance Frameworks in Cloud

Which frameworks apply to you?

The meta-question every practitioner asks first. The answer is the intersection of three forces - what your customers require to buy, what regulators require to operate, and what contracts you've already signed. The decision tree below covers most cases:

• Are you B2B SaaS selling to North American enterprises? → SOC 2 Type II is the default ask. Without one, deals stall in security review.
• Selling to EU enterprises, or operating outside North America? → ISO 27001 is more commonly preferred, often co-required with SOC 2 above ~$50k ACV. ISO 27017 (cloud) and ISO 27018 (PII in cloud) are often bundled.
• Do you store, process, or transmit payment card data? → PCI DSS v4.0 is non-negotiable. Scope-reduce aggressively via tokenization before you map controls.
• Do you touch Protected Health Information (PHI) in the US? → HIPAA, almost always backed by a HITRUST CSF assessment that healthcare customers accept as the unified audit deliverable.
• Selling to the US federal government? → FedRAMP Low / Moderate / High / LI-SaaS, plus FISMA for the agency itself. State and local governments often accept StateRAMP or a TX-RAMP equivalent.
• DoD contractor handling FCI or CUI? → CMMC 2.0 Level 1, 2, or 3 depending on data sensitivity, plus DFARS 252.204-7012 contractual requirements.
• US public company, or subsidiary of one? → SOX ITGCs over financial-reporting systems.
• Processing personal data of EU/UK residents? → GDPR (and UK GDPR), regardless of where your company is incorporated. EDPB-tested cross-border transfer mechanism required.
• Processing personal data of California residents (and revenue thresholds met)? → CCPA / CPRA. A growing number of US states (Virginia, Colorado, Connecticut, Texas, Utah, Oregon, Washington and more) have parallel laws - most converge on similar primitives.
• EU operator of essential / important services? → NIS2 (cybersecurity), and for financial services, DORA (operational resilience, in force January 2025).
• Regulated industry? → Add sector-specific frameworks (FERPA for education, GLBA Safeguards Rule for financial, CJIS for criminal-justice data, TISAX for automotive, ISO 13485 for medical-device QMS, NERC CIP for North American electric utilities).

The honest answer is that most companies eventually accumulate 3-5 frameworks. The order in which they arrive is almost always: first the framework that gates revenue (usually SOC 2 or PCI DSS), then the framework that gates a specific deal type (HIPAA, FedRAMP, ISO 27001), then the regulatory framework that becomes mandatory at a threshold (GDPR, SOX, CCPA), then the sector-specific overlay. Plan the sequence; don't pursue them ad hoc.

The 60-80% overlap reality

SOC 2, ISO 27001, PCI DSS, HIPAA, FedRAMP, NIST CSF, CIS Controls, and most other security frameworks all require the same foundational controls - they just describe them differently. Multi-factor authentication on privileged accounts is the same engineering work whether SOC 2 calls it CC6.1, ISO 27001 calls it A.5.17, PCI DSS calls it Requirement 8.4, NIST 800-53 calls it IA-2(1), or HITRUST calls it 01.j. The auditor needs to see the control in the format their framework expects; the underlying control runs once.

This is the single highest-leverage insight in multi-framework programs: maintain one internal control set, map every external framework to it, and only add framework-specific overlays where genuinely required. Building one control set per framework is the most expensive mistake any GRC program can make.

The mapping work itself is mostly solved by industry-standard crosswalks. The most useful:

• Secure Controls Framework (SCF) - a free, open meta-framework with ~1,100 controls mapped to ~150 external frameworks. Excellent starting point for unified-control-set design.
• Unified Compliance Framework (UCF) - commercial, exhaustive, the database that most GRC platforms license under the hood.
• OSCAL (Open Security Controls Assessment Language) - NIST's machine-readable format for controls, profiles, and assessments. FedRAMP is moving authorization packages to OSCAL; smart programs author internal control sets in OSCAL too.
• ComplianceForge - the team behind SCF; sells reference policy/procedure libraries pre-mapped to SCF.
• CSA Cloud Controls Matrix (CCM) - cloud-specific control framework with framework crosswalks; the basis for the CSA STAR program.

The remaining 20-40% is where frameworks diverge. PCI DSS has hard requirements for network segmentation, cardholder data flow diagrams, and quarterly ASV scans that other frameworks don't share. FedRAMP requires US-citizen-only personnel for some baselines. HIPAA requires Breach Notification Rule processes with specific timelines. GDPR requires data subject rights workflows. These are the overlays; build them once and don't pretend the underlying engineering work is different.

SOC 2

The de facto B2B SaaS attestation in North America. Authored by the AICPA and performed by licensed CPA firms. Not a certification - it's an attestation report describing the auditor's opinion on the design (Type I) or operating effectiveness (Type II) of your controls against the Trust Services Criteria.

Type I vs Type II

• Type I. Point-in-time. Auditor evaluates whether controls are designed appropriately on a specific date. Typically 4-8 weeks of fieldwork. Useful as a stepping stone, but enterprise buyers usually want Type II.
• Type II. Period-of-time, usually 6 or 12 months. Auditor tests whether controls operated effectively across the observation window. The procurement-acceptable deliverable.

The five Trust Services Criteria (TSC)

• Security - required. Sometimes called Common Criteria; the bulk of the control universe lives here (CC1-CC9 covering control environment, communication, risk assessment, monitoring, control activities, logical access, system operations, change management, risk mitigation).
• Availability - optional. Uptime commitments, capacity planning, environmental protections, DR. Common addition for infrastructure-heavy SaaS.
• Confidentiality - optional. Identification and protection of confidential data per agreement. Common for B2B with customer-data sensitivity.
• Processing Integrity - optional. Data is processed completely, accurately, timely, and authorized. Common for fintech and data-processing platforms.
• Privacy - optional. Personal information collection, use, retention, disclosure, and disposal. Less common because GDPR / CCPA already drive parallel work.

Audit firm selection

The big four (Deloitte, PwC, EY, KPMG) audit large public companies expensively. Mid-market and cloud-native firms - Schellman, A-LIGN, Coalfire, Insight Assurance, Prescient Assurance, Sensiba, BARR Advisory, Johanson Group - dominate SaaS SOC 2 work and are usually a much better fit for the first audit. Pick the firm by the lead auditor's cloud literacy and prior engagements on your stack, not the brand on the report. Stable multi-year relationships drive cost down materially.

Typical cost and timeline

For a 20-50-person SaaS using a compliance-automation platform: $20k-$40k for a Type I, $40k-$80k for a Type II (Security only), $60k-$120k+ if you add Availability and Confidentiality. Add 6 months of observation period before the audit can be performed. Total elapsed from "we should do this" to a signed Type II report: 9-12 months realistic, 6 months aggressive. Large enterprises spend $200k+ on annual SOC 2s with broader TSC coverage and bigger control populations.

Cloud-specific gotchas

• Subservice organization carve-out vs inclusive method. Almost every SaaS uses AWS / Azure / GCP and carves them out as subservice organizations; you must document the controls you assume the cloud provider performs (the "complementary subservice organization controls" or CSOCs) and the customer must read both reports together.
• Evidence period gaps. A control that was changed mid-period needs evidence for the full period, not just the latter half. Plan turn-on dates carefully or accept that the next audit will cover the gap.
• Vendor management is a top finding. Auditors check subprocessor lists, signed DPAs, and reviewed security questionnaires. Underinvested vendor management generates findings disproportionate to engineering effort.

ISO/IEC 27001 (and 27017, 27018, 27701)

The international standard for an Information Security Management System (ISMS). Unlike SOC 2, ISO 27001 is a true certification - issued by an accredited registrar - and the standard prescribes the management system structure (risk-based, with management review, internal audit, continual improvement) in addition to the controls. ISO 27001 is more common than SOC 2 outside North America and increasingly co-required.

Structure

• Clauses 4-10 define the mandatory ISMS - context, leadership, planning, support, operation, performance evaluation, improvement. Skipping any of these is a non-conformity that blocks certification.
• Annex A (in the 2022 revision) lists 93 reference controls in four themes: Organizational (37), People (8), Physical (14), Technological (34). You select applicable controls in a Statement of Applicability (SoA), justifying inclusions and exclusions against your risk treatment.

Related ISO standards

• ISO/IEC 27017 - code of practice for cloud-services-specific information-security controls. Add-on to 27001 for cloud providers and consumers.
• ISO/IEC 27018 - code of practice for protection of PII in public clouds. The de facto standard cloud providers attest to for PII handling.
• ISO/IEC 27701 - Privacy Information Management System extension. Maps to GDPR articles; the privacy counterpart to ISO 27001.
• ISO/IEC 27017 + 27018 together - the cloud bundle most major providers and SaaS shops pursue alongside 27001.

Certification cycle

• Stage 1. Documentation review - does the ISMS exist on paper, with scope, SoA, risk register, policies?
• Stage 2. Operational audit - does the ISMS actually run? Sampling of evidence, interviews with control owners, observation of processes. The certification decision is made here.
• Surveillance audits. Year 1 and Year 2 after certification, reduced-scope audits to confirm the ISMS still operates.
• Recertification. Year 3 - full audit again. Cycle repeats.

Cost and timeline

Initial certification: $25k-$60k for the audit itself (3-year cycle), plus 6-12 months of internal work to stand up the ISMS, run an internal audit, and complete a management review. Surveillance audits typically run 40-60% of the initial cost. Pick an accredited registrar (BSI, DNV, BSI Group, TÜV, Schellman, A-LIGN, Coalfire ISO, Mastermind) - non-accredited certificates are not recognized.

Cloud-specific gotchas

• The 2022 revision restructured Annex A. Programs certified under the 2013 revision must transition by October 2025; mapping work is required.
• SoA discipline. Excluded controls must be justified; lazy SoAs are a top finding.
• Management review evidence. The ISMS must demonstrate top-management engagement - meeting minutes, decisions, action items. Programs run by security teams in isolation fail this clause.

PCI DSS v4.0

The Payment Card Industry Data Security Standard. Maintained by the PCI Security Standards Council on behalf of the major card brands (Visa, Mastercard, American Express, Discover, JCB). Required if you store, process, or transmit cardholder data, or if you can impact the security of cardholder data. v4.0.1 is current; v3.2.1 was fully retired in March 2024.

The 12 Requirements (grouped into 6 control objectives)

1. Install and maintain network security controls.
2. Apply secure configurations to all system components.
3. Protect stored account data.
4. Protect cardholder data with strong cryptography during transmission over open public networks.
5. Protect all systems and networks from malicious software.
6. Develop and maintain secure systems and software.
7. Restrict access to system components and cardholder data by business need to know.
8. Identify users and authenticate access.
9. Restrict physical access to cardholder data.
10. Log and monitor all access to system components and cardholder data.
11. Test security of systems and networks regularly.
12. Support information security with organizational policies and programs.

v4.0 changes that matter

• Customized Approach. Organizations can implement controls differently from the Defined Approach, with a Targeted Risk Analysis justifying the variation. Real flexibility for cloud-native architectures.
• Continuous monitoring expectations. Many controls now require frequency-based verification (e.g., authenticated scans, log reviews, key rotations) rather than annual sampling.
• MFA expanded. Required for all access into the CDE, not just remote and admin.
• Stronger requirements for service providers and TPSPs. Risk analyses, written agreements with explicit responsibilities.

Scope reduction is the highest-leverage move

The Cardholder Data Environment (CDE) is the in-scope set of systems that store, process, transmit, or could impact cardholder data security. Anything you can remove from the CDE saves audit work for the life of the program. The standard mechanisms:

• Tokenization. Replace the PAN with a token; only the tokenization vault holds the PAN. The vault is in scope; everything downstream is not.
• Hosted payment pages / redirect. The payment form is served by a PCI Level 1 service provider (Stripe, Braintree, Adyen, Worldpay); your application never touches PAN. SAQ A becomes available - the lightest of all SAQs.
• Network segmentation. Cleanly separate the CDE from everything else, with controls verifying the segmentation works. Misimplemented segmentation is a top QSA finding.
• Card brand-specific volume thresholds. Level 1 (annual transactions ≥6M Visa/MC) requires an annual Report on Compliance (ROC) attested by a Qualified Security Assessor (QSA). Levels 2-4 can use a Self-Assessment Questionnaire (SAQ); pick the right SAQ for your scope (A, A-EP, B, B-IP, C, C-VT, D, P2PE).

Cloud-specific guidance

The PCI Cloud Computing SIG guidance (Information Supplement) covers shared-responsibility mapping for cloud workloads. AWS, Azure, and GCP each publish PCI DSS responsibility matrices that explicitly delineate which requirements they cover, which you cover, and which are shared. Use the matrix from your provider; do not let your QSA assume.

• AWS - PCI DSS Level 1 Service Provider, ~120 services in scope, AWS Artifact provides the AOC and responsibility matrix.
• Azure - PCI DSS Level 1 Service Provider, comparable scope, Service Trust Portal hosts the documentation.
• GCP - PCI DSS Level 1 Service Provider, Compliance Reports Manager hosts the AOC.

Cost

SAQ A is essentially free (engineering effort only). SAQ D self-assessed: $25k-$75k in tooling and consultant time. Level 1 ROC with QSA: $100k-$500k+ depending on scope, plus ongoing quarterly ASV scans, annual penetration testing, and continuous monitoring overhead.

HIPAA / HITECH (and HITRUST)

The Health Insurance Portability and Accountability Act (1996) and the HITECH Act (2009) together form the US federal framework for protecting health information. Applies to covered entities (providers, payers, clearinghouses) and their business associates (BAs) - including any cloud or SaaS that handles Protected Health Information (PHI) on a covered entity's behalf.

Three rules

• Privacy Rule. Governs the use and disclosure of PHI. Permissible uses, minimum necessary, individual rights (access, amendment, accounting of disclosures), Notice of Privacy Practices.
• Security Rule. Required safeguards for electronic PHI (ePHI). The technical part of the standard for cloud practitioners.
• Breach Notification Rule. Disclosure timelines and obligations when unsecured PHI is breached - 60-day notification to affected individuals, 60-day notification to HHS (annual roll-up for breaches under 500 individuals), media notification for breaches over 500 in a state.

Security Rule safeguards

• Administrative safeguards - security management process, workforce security, information access management, security awareness training, contingency plan, evaluation, BAAs.
• Physical safeguards - facility access, workstation use, device and media controls.
• Technical safeguards - access controls, audit controls, integrity, person/entity authentication, transmission security.

Note: HIPAA distinguishes "required" from "addressable" implementation specifications. Addressable does not mean optional; it means you implement, or document a justification for an equivalent alternative. This is a common misread.

BAAs with cloud providers

You must have a signed Business Associate Agreement with any subprocessor that handles PHI. Critically, the BAA does not automatically cover every service the provider offers - you must use a HIPAA-eligible service from the provider's list. Putting PHI in a non-eligible service is a violation regardless of the BAA being in place.

• AWS - ~150 HIPAA-eligible services; BAA signable through AWS Artifact.
• Azure - Microsoft BAA covers covered Azure services via the Online Services Terms.
• GCP - ~140 covered services; BAA signable for Google Workspace and Google Cloud.

HITRUST CSF

The HITRUST Common Security Framework is the de facto unified control framework healthcare customers ask for. It harmonizes HIPAA, NIST 800-53, ISO 27001, PCI DSS, COBIT, and more into one assessable control set. Three assessment types:

• e1 - Essentials, 44 controls, ~1-year validity. Entry-level.
• i1 - Implemented, 182 controls, 1-year validity. Threat-adaptive baseline.
• r2 - Risk-based, 200-2,000+ controls scaled to scope, 2-year validity with interim assessment. The audit healthcare enterprises actually require from vendors.

HITRUST r2 is expensive - $100k-$500k+ - but a single r2 satisfies most healthcare customer security reviews and crosswalks to many other frameworks.

FedRAMP

The Federal Risk and Authorization Management Program - the standardized authorization process for cloud services used by US federal agencies. Drawn from NIST SP 800-53 Rev 5, with FedRAMP-specific overlay (the FedRAMP Baselines).

Baselines

• Low - ~125 controls. Public-facing or non-sensitive data. Authorization process is the lightest.
• Moderate - ~325 controls. The most common baseline; covers CUI and most sensitive-but-unclassified government data. ~80% of FedRAMP authorizations are Moderate.
• High - ~425 controls. Data whose loss would have severe or catastrophic effect. Required for certain agencies and use cases (DoD, IRS, law enforcement).
• LI-SaaS (Tailored Low Impact SaaS) - ~125 reduced-scope controls. Lightweight track for low-impact SaaS that does not store federal data.

Authorization paths

• Agency ATO. A federal agency sponsors the authorization. Most common path. The agency's CIO/CISO issues the Authority to Operate; FedRAMP PMO reviews and posts to the Marketplace.
• JAB P-ATO (legacy). The Joint Authorization Board (DoD, DHS, GSA CIOs) granted Provisional ATOs. The JAB program is being wound down in favor of agency-led authorizations.
• FedRAMP Ready / In Process. Pre-authorization status flags. Useful for marketing while you pursue full authorization but not equivalent to ATO.

FedRAMP 20x

FedRAMP 20x is the program's 2025 modernization initiative - automated continuous monitoring with key security indicators (KSIs), OSCAL-native authorization packages, reduced documentation overhead, and a more contemporary control-mapping approach. Early-adopter vendors are seeing materially faster authorizations; if you are starting FedRAMP now, evaluate the 20x path before defaulting to the legacy process.

3PAO assessment

A FedRAMP-accredited Third-Party Assessment Organization performs the security assessment. The 3PAO writes a Security Assessment Report (SAR) and Security Assessment Plan (SAP); the package includes a System Security Plan (SSP), continuous-monitoring strategy, and POA&M (Plan of Action and Milestones) for residual findings. Major 3PAOs: Coalfire, Kratos, A-LIGN, Schellman, BARR Advisory, Fortreum.

Cloud boundaries

• AWS GovCloud (US) - separate cloud, US-citizen personnel, FedRAMP High authorized at the platform level. Required for ITAR-controlled workloads and FedRAMP High for many agencies.
• Azure Government - separate cloud, similar profile, FedRAMP High authorized. DoD IL5 also available.
• Google Cloud Assured Workloads - overlay on commercial GCP that enforces FedRAMP / IL2-IL5 boundaries without requiring a separate cloud. Plus dedicated Government Cloud regions for High and beyond.
• StateRAMP and TX-RAMP - state-level analogs. StateRAMP reciprocates with FedRAMP authorizations for most state and local governments; TX-RAMP is the Texas-specific program.

Cost and timeline

FedRAMP Moderate: 12-18+ months from kickoff to ATO; $500k-$2M+ in first-year cost (3PAO fees, technical control implementation, consulting, internal headcount). Annual continuous monitoring adds ~$300k-$600k. Only pursue FedRAMP with named federal revenue. "Maybe federal someday" is a recipe for sunk cost.

CMMC 2.0

Cybersecurity Maturity Model Certification 2.0 - the US Department of Defense's framework for contractors handling Federal Contract Information (FCI) or Controlled Unclassified Information (CUI). Final rule effective December 2024; phased contract incorporation begins 2025 and continues over a 3-year rollout.

Levels

• Level 1 - Foundational. 17 basic safeguarding practices for FCI. Annual self-assessment with affirmation by a senior official.
• Level 2 - Advanced. 110 controls of NIST SP 800-171 Rev 2 (transitioning to Rev 3) for CUI. Most contractors are assessed by a C3PAO (Certified Third-Party Assessor Organization) every 3 years; a small subset of Level 2 contracts allow self-assessment.
• Level 3 - Expert. ~110 controls of NIST 800-171 plus a subset of NIST SP 800-172 (enhanced security for high-value CUI). Assessed by the DoD's DIBCAC (Defense Industrial Base Cybersecurity Assessment Center).

DFARS 252.204-7012 and friends

The contractual lever that put 800-171 in place; CMMC layers an assessment regime on top. The full clause set: 252.204-7012 (safeguarding covered defense information), 252.204-7019 (NIST 800-171 self-assessment), 252.204-7020 (supplier compliance), 252.204-7021 (CMMC requirements). SPRS score (Supplier Performance Risk System) reporting is the precursor most primes already require.

Cloud-specific implementation

CUI in cloud workloads must use a CSP that meets FedRAMP Moderate (or DoD IL4 for some scenarios) and implements 800-171 controls in the customer-managed portion of the stack. Common patterns:

• AWS GovCloud (US) or commercial AWS with the appropriate boundary plus Microsoft 365 GCC High for productivity.
• Azure Government + Microsoft 365 GCC High is the canonical Microsoft stack for CUI.
• GCP Assured Workloads for FedRAMP High / IL4 boundary.
• Enclave models - PreVeil, Exostar, Kiteworks - for organizations that don't want to move their whole IT footprint into a regulated boundary.

NIST CSF 2.0

The NIST Cybersecurity Framework, first published 2014, updated to 2.0 in February 2024. Voluntary framework, not an attestation, but the most-cited common-language reference in security programs worldwide. CSF 2.0 organizes work into six Functions:

• Govern (new in 2.0) - organizational context, risk management strategy, roles, policies, oversight, cybersecurity supply-chain risk management.
• Identify - asset management, business environment, governance, risk assessment, risk-management strategy.
• Protect - identity management and access control, awareness and training, data security, info-protection processes, maintenance, protective technology.
• Detect - anomalies and events, continuous monitoring, detection processes.
• Respond - response planning, communications, analysis, mitigation, improvements.
• Recover - recovery planning, improvements, communications.

CSF 2.0 underneath uses 22 Categories and ~106 Subcategories - the actual outcomes you implement. Each Subcategory maps to controls in 800-53, ISO 27001, COBIT, ISA/IEC 62443, and others via the Informative References.

Use CSF as the meta-framework for executive reporting and program structure, layered above whichever attestation frameworks you target. Boards and CISOs find the Function/Category vocabulary far more legible than SOC 2 Trust Services Criteria or ISO 27001 Annex A. Many regulators (NYDFS, FTC) reference CSF in expected practice.

NIST SP 800-53 & 800-171

NIST SP 800-53 Rev 5

The comprehensive US federal control catalog - ~1,000 controls organized into 20 families (Access Control, Audit and Accountability, Identification and Authentication, System and Communications Protection, etc.). The basis for FedRAMP baselines and many other federal frameworks. Rev 5 introduced privacy controls inline with security controls and added supply-chain risk management (SR family).

You will rarely implement 800-53 directly as a private-sector entity unless you are pursuing FedRAMP. But 800-53 is the largest control vocabulary; crosswalks to almost everything else flow through it.

NIST SP 800-171 Rev 2 (Rev 3 transitioning)

Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations. 110 controls in 14 families, derived as a subset of 800-53 tuned for non-federal contexts. The technical baseline behind DFARS 252.204-7012 and CMMC 2.0 Level 2.

Rev 3, published in May 2024, restructured the families and updated some controls. Rev 2 remains the legally-cited baseline in DFARS as of early 2026; expect a transition timeline once the FAR / DFARS catches up.

NIST SP 800-172

Enhanced security requirements layered on top of 800-171 for environments holding particularly high-value CUI. ~35 enhanced controls focused on adversary-targeted attacks (advanced persistent threats, supply chain). The CMMC Level 3 control set draws from 800-172.

CIS Benchmarks & CIS Controls v8

The Center for Internet Security publishes two distinct things often confused: Benchmarks (per-platform configuration baselines) and Controls (a prioritized control framework).

CIS Benchmarks

Specific, configuration-level baselines per platform - CIS AWS Foundations, CIS Azure Foundations, CIS GCP Foundations, CIS Kubernetes Benchmark, CIS Docker, CIS Ubuntu / Windows / RHEL, plus dozens of application and database benchmarks. Not attestations; they are the implementation-layer baseline every modern CSPM scores against by default.

Aligning with the CIS AWS / Azure / GCP Foundations Benchmark produces evidence that crosswalks cleanly to SOC 2 CC controls, ISO 27001 Annex A technical controls, PCI DSS Requirements 1, 2, 7, 8, 10, and HIPAA Security Rule technical safeguards. For most cloud-native programs, "comply with CIS Foundations Benchmark" is the highest-leverage single starting goal.

CIS Controls v8

18 prioritized security controls with ~153 safeguards. Stratified into three Implementation Groups by organization profile:

• IG1 - essential cyber hygiene. ~56 safeguards. Small businesses with limited security resources and non-sensitive data.
• IG2 - ~74 additional safeguards (130 total). Mid-size with some regulatory exposure.
• IG3 - ~23 additional safeguards (153 total). Large enterprises with sensitive data and sophisticated adversaries.

CIS Controls v8 is a useful prioritization layer above your framework-of-record - it tells you which controls to implement first based on adversary realism, not just compliance order. Many regulators (FTC, state AGs in data-breach cases) reference CIS Controls as expected practice.

GDPR, UK GDPR, CCPA/CPRA

GDPR

The General Data Protection Regulation applies to processing of personal data of EU/EEA residents, regardless of where the controller or processor is located. Extraterritorial scope means most cloud services with EU users are in scope.

• Article 32 - Security of processing. Risk-appropriate technical and organizational measures: pseudonymization and encryption, confidentiality/integrity/availability/resilience, ability to restore availability, regular testing of effectiveness.
• DPIAs (Article 35). Data Protection Impact Assessment required when processing is likely to result in a high risk to rights and freedoms.
• DPO (Article 37). Data Protection Officer required for public authorities, large-scale monitoring, or large-scale processing of special categories.
• Breach notification (Article 33). 72-hour notification to supervisory authority; data-subject notification when high risk.
• Data subject rights. Access, rectification, erasure ("right to be forgotten"), portability, restriction, objection - workflows required.
• Sanctions. Up to €20M or 4% of global annual turnover. Real enforcement; not hypothetical.

Cross-border transfers

The hard part for cloud workloads. Personal data leaving the EEA requires a lawful transfer mechanism:

• Adequacy decisions. The European Commission has determined certain jurisdictions (UK, Switzerland, Japan, South Korea, Canada commercial, NZ, Argentina, Israel, others) provide adequate protection. Transfers to those countries are unrestricted.
• Standard Contractual Clauses (SCCs). The 2021 modular SCCs are the workhorse mechanism. Plus a Transfer Impact Assessment (TIA) documenting that the destination country's laws don't undermine the protections.
• EU-US Data Privacy Framework (DPF). Adopted July 2023, replacing Privacy Shield. US companies self-certify with the Department of Commerce. UK and Swiss extensions exist.
• Binding Corporate Rules (BCRs). Intra-group rules approved by a lead supervisory authority. Heavy lift; only worthwhile for large multinationals.

Schrems II implications still apply. The CJEU ruling invalidated Privacy Shield in 2020 over US surveillance concerns; the DPF is the response, and it is itself the target of ongoing legal challenge (Schrems III is anticipated). Mature programs use the DPF where applicable but maintain SCCs and TIAs as the defensible fallback.

UK GDPR and the IDTA

Post-Brexit, the UK has its own GDPR (substantially identical) and its own transfer regime. The International Data Transfer Agreement (IDTA) or the UK Addendum to the EU SCCs are the two mechanisms. UK adequacy for the EU is granted but periodically reviewed.

CCPA / CPRA and US state laws

The California Consumer Privacy Act (2020) as amended by the California Privacy Rights Act (CPRA, effective 2023) covers businesses meeting revenue or processing thresholds. Comparable but distinct privacy laws now exist in Virginia (VCDPA), Colorado (CPA), Connecticut (CTDPA), Utah (UCPA), Texas (TDPSA), Oregon (OCPA), Delaware, Iowa, New Jersey, Tennessee, Montana, and others. Most converge on similar primitives: consumer rights (access, delete, opt-out of sale/sharing, correction), opt-out of targeted advertising, sensitive-data protections, privacy notices, vendor / service-provider contracts.

Operate one privacy program tuned to the strictest standard (typically CPRA or GDPR), and overlay state-specific requirements where genuinely required.

SOX (ITGCs)

The Sarbanes-Oxley Act (2002) governs US public companies. SOX Section 404 requires management to assess internal controls over financial reporting (ICFR) and the external auditor to attest. The cloud-security-relevant slice is IT General Controls (ITGCs) - controls over the IT environment supporting financial reporting systems.

The four ITGC domains

• Access to Programs and Data. Logical access, segregation of duties, privileged access, user-access reviews on a quarterly cadence. The single largest source of SOX findings in cloud environments.
• Program Change Management. Change requests, code review, approvals, segregation between developer and production access, deployment audit trail.
• Computer Operations. Job scheduling, backup and recovery, incident management for financial systems.
• Program Development. SDLC controls, testing, segregation between development and production.

Cloud-specific SOX work: tying IaC commits to Jira tickets to peer-reviewed pull requests to production deployments produces almost all the program-change evidence. Quarterly access reviews against your IdP (Entra ID, Okta, Google Workspace, AWS IAM Identity Center) covers the access slice. Cloud audit logs (CloudTrail, Activity Log, Cloud Audit Logs) cover the audit-trail requirement. The auditor wants a clean evidence chain; build it once with automation, present it every quarter.

Regional: NIS2, DORA, APRA, PIPL, LGPD

NIS2 (EU)

Directive (EU) 2022/2555 on the security of network and information systems. Applies to essential and important entities across ~18 sectors (energy, transport, banking, health, digital infrastructure, ICT service management, public administration, food, manufacturing, postal, water, space, etc.). Member-state transposition required by October 2024 - uneven in practice but enforceable now in most member states. Imposes risk-management measures, incident-reporting timelines (24h early warning, 72h notification, 1-month final report), and management-body accountability with potential personal liability.

DORA (EU)

Digital Operational Resilience Act - Regulation (EU) 2022/2554, in force January 17, 2025. Applies to ~22,000 EU financial entities (banks, insurance, investment firms, crypto-asset service providers) and their ICT third-party service providers including critical CSPs. Five pillars: ICT risk management, incident reporting, digital operational resilience testing (including threat-led penetration testing - TLPT), ICT third-party risk, information sharing. Critical Third-Party Providers (CTPPs) - designation pending - face direct oversight from the ESAs.

APRA CPS 234 (Australia)

APRA Prudential Standard CPS 234 - information security obligations for Australian regulated financial entities. Plus CPS 230 (operational risk management) and CPS 231 (outsourcing) for the broader risk landscape. AWS, Azure, and GCP have all published APRA-specific guidance.

PIPL (China)

Personal Information Protection Law (2021) - comprehensive personal-data law analogous to GDPR. Cross-border transfer mechanisms (security assessment by CAC, certification, SCC) required. Data Security Law (DSL) and Cybersecurity Law (CSL) sit alongside. Operating in China generally requires a local entity or in-country partner.

LGPD (Brazil)

Lei Geral de Proteção de Dados (2020) - GDPR-aligned Brazilian privacy law enforced by the ANPD. Most GDPR-compliant programs map cleanly with localization for legal bases and breach notification specifics.

Sector-specific: FERPA, GLBA, CJIS, TISAX, ISO 13485

• FERPA - Family Educational Rights and Privacy Act. US K-12 and higher education. Cloud vendors handling student records sign FERPA-compliant data-handling agreements (school-officials exception). EdTech adds state-level laws (SOPIPA in California, SOPPA in Illinois, NY Ed Law 2-d).
• GLBA Safeguards Rule - Gramm-Leach-Bliley Act. US financial institutions. FTC Safeguards Rule revised 2021 with explicit security requirements (designated qualified individual, written program, risk assessment, access controls, encryption, MFA, monitoring, training, incident response plan, board reporting).
• CJIS - Criminal Justice Information Services Security Policy. Required for any system handling FBI CJIS data - fingerprints, criminal history, NCIC records. AWS GovCloud, Azure Government, and GCP all have CJIS-compatible offerings. Personnel screening, advanced authentication, and audit logging are the heavy lifts.
• TISAX - Trusted Information Security Assessment Exchange. The German automotive industry's information-security assessment (managed by ENX). Required to participate in OEM supply chains (VW, BMW, Mercedes-Benz, Audi, others). Three assessment levels with prototypes / classified data driving the highest.
• ISO 13485 - quality management for medical devices. Adjacent to ISO 27001 but distinct; required for medical-device software (SaMD).
• NERC CIP - North American electric utility cybersecurity. 13 reliability standards (CIP-002 through CIP-014) covering Bulk Electric System cyber assets. Heavy compliance overhead; cloud adoption is constrained by personnel and connectivity requirements.
• FFIEC and NYDFS Part 500 - US financial services. FFIEC is the inter-agency examination handbook (not a regulation but supervisory expectation); NYDFS Part 500 is the binding New York cybersecurity regulation for covered entities including notification timelines and CISO certifications.

Framework crosswalks & mapping tools

The mapping work is mostly already done. Use these instead of reinventing the crosswalk:

• Secure Controls Framework (SCF) - free, ~1,100 meta-controls mapped to ~150 frameworks (SOC 2, ISO 27001/27002, PCI DSS, HIPAA, NIST 800-53, NIST 800-171, NIST CSF, CIS, GDPR, FedRAMP, CMMC, NIS2, DORA, and on). Maintained by ComplianceForge. The best free starting point.
• Unified Compliance Framework (UCF) - commercial, exhaustive, the database many GRC platforms license behind the scenes. ~1,200+ authority documents. Expensive but comprehensive.
• OSCAL - NIST's machine-readable XML/JSON/YAML format for controls, profiles, components, and SSPs. The future of compliance content interchange. FedRAMP authorization packages are migrating to OSCAL; smart programs author internal catalogs natively in OSCAL.
• ComplianceForge - reference policy and procedure libraries pre-mapped to SCF. Useful starting templates for organizations that want documentation faster than from scratch.
• CSA Cloud Controls Matrix (CCM) + CAIQ - cloud-specific control framework and the questionnaire vendors complete for the CSA STAR Registry. Widely accepted by enterprise procurement.
• NIST CSF Informative References - official mappings from CSF 2.0 Subcategories to 800-53, 800-171, ISO 27001, COBIT, ISA 62443, and others.
• CIS Controls Navigator - CIS's published crosswalks from CIS Controls v8 to other frameworks.

AWS / Azure / GCP compliance programs

Every major cloud attests to dozens of frameworks at the provider layer. The native tooling, evidence portals, and assessment automation each provides differs meaningfully:

Three takeaways. One: attestation coverage at the provider level is roughly parity across all three; the differences that matter are at the customer-implementation layer and the regulated-boundary offerings. Two: the evidence portals - Artifact, STP, Reports Manager - are where you collect provider AOCs and SOC reports for your auditor. Bookmark all three early. Three: the customer-side assessment tools (Audit Manager, Purview Compliance Manager, Assured Workloads + SCC) are valuable but they don't replace a GRC platform - they instrument the cloud-native portion of evidence collection.

Continuous compliance & evidence automation

For the deep dive on this, see the GRC policy-as-code section and the continuous compliance with CSPM/CNAPP section - this page is about the frameworks themselves; the implementation pattern is the same regardless of which frameworks you target.

The short version: every modern framework now expects continuous monitoring evidence rather than point-in-time snapshots. PCI DSS v4.0, FedRAMP 20x, SOC 2 with revised TSC, and the trend across ISO 27001 audits all push toward "show me the rule, show me the evaluation log, show me the remediation workflow" instead of "send me a screenshot taken last Tuesday." Programs that have built compliance-as-code in CI/CD, CSPM/CNAPP rule packs aligned to their target frameworks, and a CSPM or GRC platform that pulls evidence on a schedule sail through audits; programs still on screenshot-driven evidence collection are about to face increasing auditor friction.

GRC platform landscape

The system-of-record layer that organizes evidence, framework mappings, exceptions, vendor risk, and audit readiness. Brief differentiation - see the GRC page for a deeper take:

• Vanta - fastest first SOC 2 in market; deepest integration breadth; expanding into ISO 27001, HIPAA, PCI DSS, GDPR, FedRAMP support. The default for SaaS startups.
• Drata - comparable to Vanta on coverage; somewhat heavier customization; strong on multi-framework programs.
• Secureframe - comparable; differentiating on AI features and FedRAMP support.
• Hyperproof - strong control-framework structure; geared toward larger compliance teams running 5+ frameworks.
• OneTrust - broad GRC suite, particularly strong on privacy (DSARs, ROPAs, cookies) and third-party risk; heavier than the compliance-automation-first tools.
• ServiceNow GRC / IRM - enterprise-grade; right when your organization is already on ServiceNow for ITSM and you have GRC team size to match.
• AuditBoard - strong on internal audit and SOX programs; expanding into broader IT GRC.
• LogicGate - workflow-driven; good for organizations that want to model bespoke risk and compliance processes.

The choice criterion that matters most: integration depth with your cloud(s), identity provider, and ticketing. The whole value proposition is automated evidence collection. A platform that pulls 80% of evidence automatically is worth 2-3× one that pulls 30%. Talk to your target auditor about which platforms they're efficient on before signing the contract - the same auditor on their preferred platform is a meaningfully cheaper engagement.

Common pitfalls

• Chasing every framework. Five frameworks is a real program; ten is a paperwork factory that compounds into duplicated controls and confused owners. Pursue frameworks against named revenue or regulation; defer the rest.
• Confusing compliance with security. The auditor will sign off whether the breach is coming or not. Risk-rank, then implement; do not let SOC 2 priorities crowd out the controls that close real attack paths. The Capital One breach was at a SOC-compliant company.
• Screenshot-driven evidence collection. A Stage 1 pattern. Past 20 controls it dominates program cost and goes stale immediately. Automate evidence collection from cloud APIs, IdP, code repo, MDM - this is what compliance-automation platforms exist for.
• No continuous monitoring. Frameworks increasingly expect continuous control verification, not annual sampling. PCI DSS v4.0 explicitly added frequency-based assurance requirements. Programs designed around the audit window are about to face increasing auditor friction.
• Treating PCI DSS scope as unavoidable. Tokenization and hosted payment pages collapse your CDE to almost nothing. Many companies pay for full PCI scope they could have eliminated with a Stripe Elements / Adyen / Braintree redirect.
• Putting PHI in non-BAA-covered services. The BAA covers eligible services. Using a non-eligible service with PHI is a HIPAA violation even if the BAA is signed. Check the provider's HIPAA-eligible services list every release.
• FedRAMP without revenue. "Maybe federal someday" has burned 18-month / $1M+ programs that never reached an agency contract. Get the sponsor first.
• Conflating data residency with data sovereignty. A region in the right country doesn't, by itself, address regulator concerns about cloud-provider personnel access, foreign legal subpoena, or sovereign-cloud requirements. Read the specific regulation (NIS2, DORA, BSI C5, Schrems II implications); pick the matching offering (EU Data Boundary, Microsoft Cloud for Sovereignty, GCP sovereign partners, AWS European Sovereign Cloud).
• Ignoring vendor / subprocessor risk. Top finding across SOC 2, ISO 27001, GDPR Art. 28 audits. The subprocessor list must exist, be reviewed, and tie to signed DPAs and security questionnaires. Underinvested vendor management produces findings disproportionate to effort to fix.
• Letting framework revisions sneak up. ISO 27001:2022, PCI DSS v4.0, NIST CSF 2.0, NIST 800-171 Rev 3 are all real transitions with deadlines. Track framework revisions on the same cadence you track product roadmap. Mapping debt is silent until it isn't.

Further reading

Framework primary sources

• AICPA - SOC 2 Trust Services Criteria
• ISO/IEC 27001:2022
• PCI DSS v4.0.1 document library
• HHS HIPAA for Professionals
• FedRAMP Program · FedRAMP 20x
• DoD CMMC 2.0
• NIST CSF 2.0
• NIST SP 800-53 Rev 5 · 800-171 Rev 2 · 800-172
• CIS Benchmarks · CIS Controls v8
• GDPR official text · CCPA · EU-US Data Privacy Framework
• NIS2 Directive · DORA Regulation
• HITRUST Alliance

Mapping tools

• Secure Controls Framework (SCF)
• NIST OSCAL
• CSA Cloud Controls Matrix + STAR Registry
• Unified Compliance Framework

Cloud provider compliance portals

• AWS Compliance Center · AWS Artifact · Audit Manager
• Microsoft Compliance Offerings · Service Trust Portal · Purview Compliance Manager
• Google Cloud Compliance · Reports Manager · Assured Workloads

Related CSOH pages

• GRC for Cloud - the meta-program that runs frameworks.
• Shared responsibility - where provider attestation ends and yours begins.
• CSPM vs CNAPP - the live sensor that produces evidence.
• Cloud SOC - the detection/response counterpart.
• CI/CD - where compliance-as-code lives.
• Landing zones - the architectural foundation.
• Glossary - every framework acronym on this page, defined.

FAQ

Which compliance framework should I start with?

Start with the one your customers ask for. For most B2B SaaS in North America that's SOC 2 Type II. If you sell to EU enterprises, ISO 27001 is the more common ask and may be required co-equally. If you handle payment cards, PCI DSS is non-negotiable. If you handle PHI, HIPAA. If you sell to the US federal government, FedRAMP. Pick the one with revenue attached, run it as your primary, and map every other framework to it - they overlap 60-80% so a second framework is far cheaper than the first.

What is the difference between SOC 2 Type I and Type II?

Type I is a point-in-time assessment: the auditor evaluates whether your controls are designed appropriately on a specific date. It's faster (a few weeks of fieldwork) and cheaper, but enterprise buyers rarely accept it as the final answer. Type II covers an observation period - typically 6 or 12 months - and the auditor tests whether the controls actually operated effectively the whole time. Type II is what procurement teams want; Type I is a stepping stone or a stop-gap during the first observation window.

How do SOC 2, ISO 27001, and PCI DSS overlap?

They overlap by roughly 60-80% on the underlying technical controls - access management, encryption, logging, change management, incident response, vulnerability management, vendor risk. Where they diverge: SOC 2 emphasizes service-organization commitments and Trust Services Criteria; ISO 27001 requires a formal ISMS with management review and continual improvement; PCI DSS is highly prescriptive on network segmentation, cardholder data handling, and quarterly scanning. The pragmatic approach is to maintain one internal control set, map all frameworks to it, and add framework-specific overlays where needed. The Secure Controls Framework, the Unified Compliance Framework, and OSCAL exist specifically to make this mapping reusable.

Is FedRAMP worth pursuing for a commercial SaaS?

Only if you have an identified federal customer with budget. FedRAMP Moderate authorization typically takes 12-18 months and $500k-$2M+ in first-year cost, plus ongoing continuous-monitoring overhead. The path: choose a baseline (Low, Moderate, High, or LI-SaaS for the new lightweight track), build in a FedRAMP-aligned cloud (AWS GovCloud, Azure Government, GCP with Assured Workloads, or the commercial regions where the providers' attestation extends), engage a 3PAO, and pursue an Agency ATO or the legacy JAB P-ATO. FedRAMP 20x is the program's modernization effort and may shorten this materially for vendors who join early. "Maybe federal eventually" is not a business case.

Does using AWS, Azure, or GCP make my workload compliant?

No - it makes the provider's part of the stack compliant. Under the shared responsibility model, the cloud provider attests to the controls they own (physical security, hypervisor, managed-service internals); you attest to the controls you own (IAM configuration, data encryption decisions, application security, customer access). AWS Artifact, Azure Service Trust Portal, and Google Cloud Compliance Reports Manager give you the provider-side reports to share with your auditor; you still need to demonstrate your half. Inheriting a provider's FedRAMP authorization does not authorize your service - it just means the underlying platform is in scope of the authorization you'll pursue.

What is CMMC 2.0 and who needs it?

CMMC (Cybersecurity Maturity Model Certification) 2.0 is the US Department of Defense's framework for contractors handling Federal Contract Information (FCI) or Controlled Unclassified Information (CUI). Level 1 (Foundational) covers FCI and is self-assessed against 17 practices. Level 2 (Advanced) covers CUI and requires a C3PAO assessment against the 110 controls of NIST SP 800-171. Level 3 (Expert) is for the most sensitive CUI and is assessed by the government's DIBCAC against a subset of NIST SP 800-172. Phased rollout into DoD contracts is underway; any prime or subcontractor that touches CUI needs to be planning their level now.

What replaced Privacy Shield for EU-US data transfers?

The EU-US Data Privacy Framework (DPF), adopted in July 2023, replaced the Privacy Shield that Schrems II invalidated in 2020. US companies self-certify with the Department of Commerce. The DPF coexists with Standard Contractual Clauses (SCCs) and adequacy decisions as the lawful basis for personal-data transfers out of the EEA. The DPF is itself the target of ongoing legal challenge (Schrems III is anticipated), so most cloud-aware programs use the DPF where applicable but maintain SCCs and Transfer Impact Assessments (TIAs) as the defensible fallback. For UK transfers, the UK extension to the DPF and the UK International Data Transfer Agreement (IDTA) serve the same role.