Key Dimensions and Scopes of Cloud Compliance

Cloud compliance is not a single standard or a fixed checklist — it is a multidimensional regulatory and contractual obligation whose boundaries shift depending on the industry, the service model, the geographic reach of data processing, and the sensitivity of the information involved. Understanding how those dimensions interact determines which controls are mandatory, who is accountable for implementing them, and how auditors will measure conformance. This page maps the major dimensions and scope boundaries that define what cloud compliance actually covers in practice.

• Dimensions that vary by context
• Service delivery boundaries
• How scope is determined
• Common scope disputes
• Scope of coverage
• What is included
• What falls outside the scope
• Geographic and jurisdictional dimensions

Dimensions that vary by context

The scope of a cloud compliance obligation is not uniform across organizations. At least 5 independent variables shape the actual regulatory perimeter for any given deployment:

1. Industry vertical — Healthcare organizations processing protected health information (PHI) face HIPAA's Security Rule requirements under 45 CFR Part 164, while financial services firms fall under GLBA (Gramm-Leach-Bliley Act) Safeguards Rule obligations enforced by the FTC.
2. Data classification — The sensitivity tier of the data determines control depth. Payment card data triggers PCI DSS scope; federal controlled unclassified information (CUI) triggers NIST SP 800-171.
3. Regulatory jurisdiction — A US company that processes personal data of EU residents must comply with GDPR regardless of where its servers are located, per Article 3 of Regulation (EU) 2016/679.
4. Contract and customer requirements — Enterprise customers in regulated sectors routinely impose contractual compliance standards on their cloud vendors through data processing agreements and vendor questionnaires that exceed baseline legal minimums.
5. Cloud service model — The division of control between provider and customer differs structurally across IaaS, PaaS, and SaaS, which means the compliance obligations that fall to each party are model-dependent (addressed in detail below).

A misconception is that achieving one framework certification covers all regulatory obligations. SOC 2 Type II certification, for example, addresses trust service criteria defined by the AICPA but does not satisfy HIPAA's breach notification requirements under 45 CFR §164.400 or FedRAMP's control baseline for federal systems.

Service delivery boundaries

The shared responsibility model is the foundational boundary-setting mechanism in cloud compliance. Its structure determines which party — cloud service provider (CSP) or customer — controls the systems, and therefore which party owns each compliance obligation.

IaaS and PaaS compliance controls expose the largest customer-side control surface. In a SaaS environment, the CSP controls most infrastructure layers, but the customer retains accountability for data governance decisions — including which data enters the system, who has access, and how retention periods are enforced.

The SaaS compliance obligations layer is frequently underestimated. A SaaS vendor's SOC 2 report covers the vendor's environment; it does not extend compliance coverage to the customer's configuration choices, user provisioning decisions, or data export policies.

How scope is determined

Scope determination follows a structured process across major frameworks. The steps below represent the sequence recognized by frameworks including NIST SP 800-53 Rev. 5 (NIST CSRC) and the CSA Cloud Controls Matrix (CSA CCM):

1. Identify the regulatory triggers — Determine which statutes, regulations, and contracts apply based on industry, data type, and customer base geography.
2. Classify data assets — Assign sensitivity tiers (e.g., public, internal, confidential, restricted) to all data processed in the cloud environment.
3. Map data flows — Document where data originates, which systems process it, which third parties receive it, and where it is stored. This is the technical foundation for cloud data residency and sovereignty decisions.
4. Define the system boundary — The system boundary is the formal perimeter within which controls must be implemented and assessed. FedRAMP, for instance, requires a defined authorization boundary in the System Security Plan (SSP) as a mandatory artifact (FedRAMP Authorization Guide).
5. Apply the shared responsibility layer — Determine which controls fall to the CSP and which fall to the customer for each layer of the stack.
6. Identify control inheritance — Many frameworks allow customers to inherit controls from CSP-side implementations, provided formal documentation (e.g., a CSP's FedRAMP authorization package or ISO 27001 certificate) substantiates the inheritance.
7. Document residual obligations — List all controls the customer must implement independently, without CSP inheritance.

A cloud compliance gap analysis operationalizes steps 1 through 7 by comparing current-state control implementation against the required baseline.

Common scope disputes

Scope disputes between CSPs and customers are among the most operationally disruptive compliance problems. The most frequent points of contention include:

Encryption key custody — Many CSPs offer default encryption at rest, but the question of who controls the key management layer is decisive for compliance under frameworks like FIPS 140-2 and HIPAA. Encryption and key management responsibilities must be contractually explicit.

Log ownership and retention — NIST SP 800-53 AU-9 and AU-11 specify audit log protection and retention requirements. Disputes arise when a CSP retains logs for 90 days by default but the customer's regulatory requirement (e.g., PCI DSS Requirement 10.7 mandating 12 months) demands longer retention. The gap is the customer's problem unless the contract addresses it.

Incident notification timelines — HIPAA's Breach Notification Rule requires notification within 60 days of discovery of a breach affecting PHI (45 CFR §164.412). If the CSP is the party that discovers the breach, the contract must specify that the CSP will notify the customer within a timeframe that allows the customer to meet statutory deadlines. The cloud provider BAA requirements framework exists specifically to address this gap for HIPAA-covered entities.

Third-party subprocessor chains — Cloud environments frequently involve subprocessors (CDN providers, database-as-a-service vendors, monitoring tools). GDPR Article 28 requires that subprocessors be bound by the same data protection obligations as the primary processor. Customers frequently discover that CSP subprocessor lists are updated unilaterally, creating retroactive scope expansions in the customer's GDPR compliance program.

Scope of coverage

The broadest scope definition for cloud compliance encompasses four domains:

• Technical controls — Encryption, access control, vulnerability management, network segmentation, and logging, as specified by frameworks such as NIST 800-53 cloud controls and the CSA STAR certification program.
• Operational controls — Change management, incident response procedures, backup and recovery testing, and vendor risk management processes addressed in third-party risk management.
• Administrative controls — Policies, training programs, risk assessments, and documentation requirements. HIPAA's Security Rule distinguishes administrative safeguards as a discrete category under 45 CFR §164.308.
• Legal and contractual controls — Data processing agreements (DPAs), business associate agreements (BAAs), and contractual SLAs that embed compliance obligations.

The intersection of all four domains constitutes the full compliance scope for any materially regulated cloud deployment.

What is included

The following elements are universally within scope across major cloud compliance frameworks:

• All systems, applications, and infrastructure components that store, process, or transmit regulated data
• All personnel with privileged access to in-scope systems
• All third-party integrations that touch in-scope data, including APIs, data pipelines, and analytics platforms
• Identity and access management systems that authenticate or authorize access to regulated data
• SIEM and logging infrastructure that captures audit trails for in-scope systems
• All contractual relationships with CSPs and subprocessors that involve regulated data

The cloud compliance documentation requirements framework details the artifact set required to evidence coverage of each element above during an audit.

What falls outside the scope

Equally important is what a compliance program does not cover. Common exclusions include:

• Systems that are fully air-gapped from regulated data, with documented and tested isolation controls
• Data that has been irreversibly anonymized in conformance with a recognized standard (e.g., NIST SP 800-188 de-identification guidance; note that pseudonymized data under GDPR Recital 26 is still in scope)
• Legacy on-premises systems that have been contractually scoped out of a cloud migration but that may still share identity federation with cloud environments — a common audit finding
• Employee personal devices used solely for non-work functions, absent a BYOD policy that routes work traffic through monitored infrastructure

A persistent misconception is that a private cloud compliance deployment automatically reduces scope. Private cloud reduces shared-tenancy risks but does not eliminate regulatory obligations for data classification, access control, or breach notification.

Geographic and jurisdictional dimensions

Jurisdictional scope is one of the most complex dimensions because it does not follow physical server location alone. Key principles:

Data subject location governs in privacy law — GDPR, CCPA, and Brazil's LGPD all extend jurisdiction based on the location of data subjects, not the location of the data controller's servers. A US-only cloud deployment that processes data of California residents falls within CCPA cloud data compliance scope regardless of whether the company is headquartered outside California.

Federal data residency requirements — FedRAMP High baseline systems processing federal data must physically reside within the continental United States, per FedRAMP requirements. This constraint directly affects public cloud compliance considerations for agencies and their contractors.

Export controls create cross-border cloud restrictions — ITAR and EAR cloud compliance obligations under 22 CFR Part 120 and 15 CFR Part 730 restrict where controlled technical data can be stored or accessed, including cloud storage. Non-US citizen employees of a CSP accessing defense technical data on a customer's cloud tenant may constitute a deemed export under ITAR.

Multi-jurisdictional stacking — A multinational organization may simultaneously face GDPR (EU data subjects), PIPEDA (Canadian data), and state-level requirements in California and Virginia. Multi-cloud compliance strategy must account for this stacking rather than treating each jurisdiction in isolation.

The regulatory context for cloud compliance covers the specific statutory frameworks underlying these jurisdictional obligations in greater detail. For a broader orientation to the compliance landscape, the cloud compliance frameworks overview provides comparative framework structure. The starting reference point for navigating all major topic areas on this property is the site index.