IaaS and PaaS Compliance Controls: Responsibilities Across Service Models

Infrastructure-as-a-Service (IaaS) and Platform-as-a-Service (PaaS) deployments impose distinct compliance obligations that depend on how control is divided between the cloud provider and the customer. The division of that control — who patches the operating system, who configures the runtime, who manages encryption keys — determines which party bears accountability under frameworks such as HIPAA, FedRAMP, and PCI DSS. Understanding these boundaries is foundational to building an auditable, enforceable compliance posture, and sits at the center of what is covered across the Cloud Compliance Authority resource index.

Definition and scope

IaaS delivers virtualized compute, storage, and networking resources over the internet. The customer receives raw infrastructure — virtual machines, block storage, virtual networks — and retains control over operating systems, middleware, application stacks, and data. PaaS adds a managed runtime layer on top: the provider handles the operating system, patching, and often the database engine or container orchestration plane, while the customer controls the application code and data.

The compliance scope difference is material. Under IaaS, the customer is responsible for hardening the guest OS, configuring firewalls at the instance level, and managing identity and access within the workload. Under PaaS, the provider absorbs those controls into the managed layer, narrowing the customer's control surface but not eliminating compliance obligations — particularly for data classification, access governance, and logging.

The NIST Special Publication 800-145, the formal NIST definition of cloud computing, establishes these service model boundaries as the basis for control inheritance analysis. FedRAMP builds directly on SP 800-145 categorizations when assigning controls to providers versus agencies in its FedRAMP Authorization documentation.

How it works

Compliance control allocation across IaaS and PaaS follows a structured inheritance model. NIST SP 800-53 Rev 5 (csrc.nist.gov) organizes controls into families — Access Control (AC), Configuration Management (CM), Audit and Accountability (AU), and others — each of which must be assigned to an owner: the provider, the customer, or both as a shared responsibility.

The inheritance breakdown typically follows this pattern:

Physical and hypervisor layer — Always provider-owned in both IaaS and PaaS. This includes physical access controls, power and cooling, and the hypervisor. The customer has no audit rights over this layer in standard commercial IaaS; instead, the provider's third-party attestations (SOC 2 Type II, ISO 27001) serve as evidence.
Operating system and runtime patching — In IaaS, the customer owns this entirely. A customer running Amazon EC2 or Microsoft Azure Virtual Machines is responsible for applying OS patches within the timeframes required by frameworks like PCI DSS, which mandates critical patch application within one month of release (PCI Security Standards Council, PCI DSS v4.0, Requirement 6.3.3). In PaaS, the provider manages OS patching, and the customer must obtain and retain evidence of the provider's patch cadence as part of audit documentation.
Network controls — IaaS customers configure security groups, network ACLs, and firewall rules at the instance level. PaaS customers typically configure only application-level ingress/egress rules; lower-level network segmentation is managed by the provider.
Identity and access management — Both models require customers to manage IAM policies governing who can access workloads and data. The provider manages the IAM control plane (the API surface itself), but tenant-level permission structures are always customer-owned. NIST SP 800-207 on Zero Trust Architecture addresses this boundary explicitly in the context of cloud workloads.
Data encryption and key management — In both models, the customer typically controls encryption keys for data at rest and in transit, though the provider may offer managed key services. The distinction matters under HIPAA: under 45 CFR § 164.312(a)(2)(iv), covered entities must implement encryption and decryption mechanisms — the customer cannot delegate accountability for this to a PaaS provider.
Logging and audit trails — Both IaaS and PaaS customers must configure and retain logs sufficient to support incident response and audit. The regulatory context for cloud compliance across frameworks including SOX and FedRAMP specifies log retention minimums ranging from 90 days to 7 years depending on data type and industry.

Common scenarios

Healthcare workloads on IaaS (HIPAA): A covered entity running a patient portal on bare IaaS virtual machines must treat the entire OS and application stack as in-scope for HIPAA technical safeguards under 45 CFR Part 164. The provider's Business Associate Agreement (BAA) covers only the infrastructure layer; the customer is responsible for access controls, audit logging, and transmission encryption within the workload.

Financial application on PaaS (PCI DSS): A payment processor deploying a card-data application on a managed Kubernetes platform (PaaS) can inherit network segmentation and OS hardening controls from the provider's validated compliance posture — provided the provider holds a current Attestation of Compliance (AOC) under PCI DSS v4.0. The customer still owns cardholder data encryption, application-level access controls, and vulnerability scanning of custom code.

Federal workloads (FedRAMP): A federal agency consuming IaaS at a FedRAMP High authorization level can inherit the approximately 325 controls documented in the provider's System Security Plan (SSP), but agency-specific controls — user account provisioning, data classification, contingency planning — remain the agency's responsibility. FedRAMP's authorization documentation explicitly maps inherited versus customer-responsible controls in the Customer Responsibility Matrix (CRM).

Decision boundaries

Determining which service model imposes fewer compliance burdens is not a straightforward calculus. PaaS reduces the control surface a customer must directly manage, but it introduces dependency on the provider's compliance posture, audit evidence quality, and contractual commitments. IaaS preserves direct control but requires the customer to staff and operate a broader control set.

Four decision criteria determine the appropriate model for compliance-sensitive workloads:

Data sensitivity and regulatory mandate: Workloads subject to ITAR, CMMC, or FedRAMP High face strict requirements about where and how controls are implemented, often constraining PaaS use to providers with specific authorizations.
Auditability of inherited controls: A customer can only inherit controls they can evidence. If a PaaS provider does not produce a current SOC 2 Type II report or FedRAMP SSP excerpt, the customer bears the audit gap regardless of what the provider actually does.
Key management architecture: Regulations requiring customer-held encryption keys (common in financial services under GLBA and in HIPAA environments) limit the extent to which PaaS managed-encryption services can satisfy requirements without additional configuration.
Logging completeness: PaaS environments may restrict the granularity of available logs. If a framework requires host-level process logging — as NIST SP 800-53 AU-12 does — and the PaaS layer does not expose those events, the customer must evaluate whether compensating controls are sufficient.

The Cloud Security Alliance's Cloud Controls Matrix (CCM) v4 provides a cross-referenced control mapping across IaaS and PaaS layers, aligned to ISO/IEC 27001, NIST SP 800-53, and PCI DSS, and is a recognized tool for identifying and documenting these boundaries before deployment.

IaaS and PaaS Compliance Controls: Responsibilities Across Service Models

Definition and scope

How it works

Common scenarios

Decision boundaries

References

Read Next