Public Cloud Compliance Considerations: Risks, Controls, and Provider Evaluation

Public cloud deployments introduce a distinct set of compliance obligations that differ materially from on-premises or private infrastructure models. This page covers the regulatory scope of public cloud environments, the control mechanisms available to organizations operating within them, the most common compliance failure scenarios, and the decision criteria used to evaluate public cloud providers against applicable frameworks. Understanding these dimensions is foundational to any cloud compliance program operating at scale.

Definition and scope

A public cloud environment is one in which compute, storage, and networking resources are delivered over the internet by a third-party provider — such as Amazon Web Services, Microsoft Azure, or Google Cloud Platform — and shared across multiple tenants on common physical infrastructure. Compliance scope in this context refers to the set of regulatory, contractual, and framework obligations that apply to data processed, stored, or transmitted through that environment.

The regulatory perimeter for public cloud compliance is wide. Federal frameworks including FedRAMP (Federal Risk and Authorization Management Program, administered by the General Services Administration) govern cloud services used by US federal agencies. The Health Insurance Portability and Accountability Act (HIPAA), enforced by the HHS Office for Civil Rights, imposes specific requirements on covered entities and business associates handling protected health information in cloud systems. The Payment Card Industry Data Security Standard (PCI DSS), maintained by the PCI Security Standards Council, applies to any cloud environment processing cardholder data. State-level statutes such as the California Consumer Privacy Act (CCPA) extend obligations to cloud-stored consumer data regardless of where the provider's infrastructure is physically located.

A complete treatment of the regulatory landscape is available at /regulatory-context-for-cloud-compliance, which maps specific statutes and frameworks to cloud deployment types.

The scope boundary matters because public cloud compliance is not a single standard — it is an intersection of the organization's industry vertical, the data classifications involved, the geographies where data subjects reside, and the specific services consumed from the provider.

How it works

Compliance in public cloud environments operates through the shared responsibility model, a division of security and compliance duties between the cloud provider and the customer. NIST SP 800-145 defines cloud service models (IaaS, PaaS, SaaS), and each model shifts responsibility differently (NIST SP 800-145).

A structured breakdown of responsibility layers:

  1. Physical infrastructure and hypervisor layer — The provider is responsible for physical security, hardware lifecycle, and hypervisor integrity. Customers have no direct control or audit access here.
  2. Network controls — Providers supply network segmentation capabilities; customers must configure security groups, virtual private clouds, and egress filtering.
  3. Identity and access management — Customers are responsible for configuring role-based access, enforcing multi-factor authentication, and managing privilege escalation policies within their tenancy.
  4. Data classification and encryption — Customers determine what data enters the environment, apply classification tags, and configure encryption at rest and in transit using provider-supplied or customer-managed keys.
  5. Audit logging and monitoring — Providers generate infrastructure-level logs; customers must enable, retain, and analyze application and access logs against their specific compliance requirements.
  6. Compliance documentation — Customers must produce evidence of controls for audits; providers supply third-party attestations (SOC 2 Type II reports, ISO 27001 certificates, FedRAMP ATOs) that cover the provider's scope only.

The Cloud Security Alliance (CSA) Cloud Controls Matrix (CCM) maps 197 control objectives across 17 domains and is widely used to operationalize this division of duties. NIST SP 800-53 Rev. 5, available at csrc.nist.gov, provides the federal control baseline against which many public cloud deployments are assessed.

Common scenarios

Four compliance failure patterns recur consistently in public cloud deployments:

Misconfigured storage permissions. Publicly accessible object storage buckets — a documented pattern in AWS S3, Azure Blob, and Google Cloud Storage environments — expose regulated data without a breach in the traditional sense. The HHS Office for Civil Rights has issued guidance treating unsecured ePHI exposure as a HIPAA breach regardless of whether unauthorized access is confirmed.

Insufficient logging retention. PCI DSS Requirement 10.7 mandates at least 12 months of audit log history, with 3 months immediately available for analysis (PCI DSS v4.0, PCI Security Standards Council). Organizations frequently enable provider-native logging but configure retention windows that fall below this threshold.

Unvalidated provider scope. A cloud provider holding a FedRAMP Authority to Operate (ATO) covers only the services and configurations within that authorization boundary. Customers who deploy workloads using services outside the ATO boundary — or configure services in ways not covered by the provider's assessment — inherit compliance gaps the provider's attestation does not address.

Third-party subprocessor chains. Public cloud providers routinely use subprocessors for content delivery, support operations, and analytics. GDPR Article 28 requires documented subprocessor agreements, and the customer remains accountable for subprocessor compliance even when the primary provider holds adequate certifications (EUR-Lex GDPR Article 28).

Decision boundaries

Selecting a public cloud provider for a compliance-sensitive workload requires evaluation against at least 4 distinct criteria:

Attestation currency and scope. A SOC 2 Type II report older than 12 months provides limited assurance. The report must cover the specific services in use, not just the provider's core platform. The AICPA Trust Services Criteria define the scope boundaries for SOC 2 assessments (AICPA).

Data residency controls. For organizations subject to data sovereignty requirements — EU data subjects under GDPR, controlled unclassified information under NIST SP 800-171 — the provider must offer enforceable data residency guarantees, not best-effort regional defaults.

Contractual compliance support. HIPAA requires a signed Business Associate Agreement (BAA) with the cloud provider before any ePHI enters the environment. GDPR requires a Data Processing Agreement (DPA). Providers that do not offer these instruments cannot be used for the relevant data types regardless of their technical controls.

Incident notification SLAs. HIPAA's Breach Notification Rule requires covered entities to notify HHS within 60 days of breach discovery (45 CFR §164.404). The provider's contractual notification timeline to the customer must be shorter than that statutory deadline to preserve the customer's ability to comply.

The contrast between IaaS and SaaS deployments is particularly sharp here: in an IaaS model, the customer retains control over 70–80% of the compliance control stack; in a SaaS model, the provider controls the majority of the environment, and the customer's primary compliance levers are vendor assessment, contractual terms, and access governance rather than direct technical configuration.

References

Read Next

Private Cloud Compliance: When Isolation Requirements Drive Architecture Next in Cloud Architecture and Service Model Compliance SaaS Compliance Obligations: Vendor Assessment and Contractual Protections Previous in Cloud Architecture and Service Model Compliance