When you run cardholder data workloads in the cloud, PCI DSS responsibility is split between you and your cloud service provider. The provider covers the requirements it manages for the specific services you use, you cover everything else, and some requirements are shared. The split depends heavily on the service model, with infrastructure as a service (IaaS) leaving the most to you and software as a service (SaaS) the least. PCI DSS v4.0 expects that split to be written down, and a compliant provider doesn't make your environment compliant.
This post covers how to work out who does what, the evidence to get from your provider, and how containers, serverless and cloud segmentation affect scope.
What does shared responsibility mean for PCI DSS?
Under PCI DSS, a cloud provider that stores, processes or transmits your account data, or can affect its security, is a third-party service provider (TPSP). You manage it under Requirement 12.8, and the provider has its own obligations to you under Requirement 12.9.
The PCI Security Standards Council's (PCI SSC) Cloud Computing Guidelines, version 3.0 from April 2018, is the Council's main reference on this topic. It stresses defining clearly which party is responsible for each requirement. It also urges customers to ask the provider questions and verify the answers rather than assume.
A common mistake is treating "our cloud provider is PCI DSS compliant" as the end of the conversation. The provider's assessment covers the provider's part of the stack. Your configuration of its services, your applications and your access controls are yours to assess.
How does responsibility differ between IaaS, PaaS and SaaS?
The more of the stack a provider manages, the more PCI DSS requirements it can take on. The Cloud Computing Guidelines put it simply: IaaS gives the customer the most control, and SaaS gives the customer the least.
| Layer | IaaS | PaaS | SaaS |
|---|---|---|---|
| Physical data centers and hardware | Provider | Provider | Provider |
| Virtualization and host infrastructure | Provider | Provider | Provider |
| Operating systems | Customer | Provider (mostly) | Provider |
| Runtime, middleware and databases | Customer | Shared | Provider |
| Application code and configuration | Customer | Customer | Provider (you configure features) |
| Identity and access for your users | Customer | Customer | Shared |
| Account data and how it flows | Customer | Customer | Customer and provider |
Treat this as a starting point, not an answer. Every provider draws the lines differently, and the same provider may split responsibility differently between two services.
IaaS
With virtual machines and virtual networks, you own almost everything above the hypervisor. That includes operating system hardening, patching, malware protection, logging, network security controls, and access management for the systems you build. The provider handles physical security and the underlying infrastructure.
PaaS
With managed databases, application platforms and similar services, the provider takes on operating system and much of the runtime. You still own your code, your data, how the service is configured, who can access it, and whether its logs reach your monitoring. Settings such as encryption options, network exposure and authentication methods are usually your choice, and so your responsibility.
SaaS
With SaaS, the provider runs the application. You're still responsible for how your users access it, how you configure it, and which of your processes send account data to it. You also need the provider's compliance evidence to cover the service you're actually using.
What evidence should you get from your cloud provider?
PCI DSS v4.0 tightens expectations on both sides of the relationship. You need two things from each provider in scope: proof of its compliance and a clear split of responsibilities.
The provider's Attestation of Compliance
Requirement 12.8.4 asks you to monitor each TPSP's compliance status at least once every 12 months. For cloud providers, that usually means reviewing their Attestation of Compliance (AOC). When you get it, check:
- That it's a service provider AOC, and it's current.
- Which PCI DSS version it was assessed against.
- Which services were included in the assessment, and which were not. A provider can be compliant for some services and not others.
- Any requirements marked as not in place or not applicable that affect you.
If a service you rely on isn't listed as included, you'll need another way to show that it meets the requirements it covers, or you'll need to assess it as part of your own environment.
The responsibility matrix
Requirement 12.8.5 requires you to maintain information about which PCI DSS requirements each TPSP manages, which you manage, and which are shared. Its counterpart, Requirement 12.9.2, requires service providers to support customer requests for that information, along with their compliance status for the services they provide. Requirement 12.9.1 adds that providers acknowledge in writing their responsibility for the security of account data they handle or could affect.
Many large cloud providers publish a responsibility matrix for their services. Use it, but map it to your own architecture. A matrix that says "customer responsibility" for a requirement is a task on your list, not a note to file away.
How do containers and serverless affect PCI scope?
Containers and serverless platforms move more of the stack to the provider, but they don't remove the need to know where account data flows and what can affect it.
Containers and orchestration
In September 2022 the PCI SSC published an information supplement, Guidance for Containers and Container Orchestration Tools. It covers threats to containerized payment systems and best practices for addressing them. A few scoping points apply to almost any containerized payment environment:
- The orchestration control plane is security-impacting. Anything that can schedule workloads, change network policy or read secrets in a cluster running CDE workloads is in scope.
- Shared clusters widen scope. If CDE and non-CDE workloads share nodes or a cluster, you need to show that the non-CDE workloads can't affect the CDE ones. Dedicated clusters or node pools make that argument much easier.
- Namespaces aren't a boundary on their own. Isolation needs network policies, access controls and runtime restrictions that are actually enforced.
- The build pipeline matters. Registries and pipelines that produce CDE images can change what runs in the CDE, so they're security-impacting.
Short-lived workloads also complicate inventory. Requirement 12.5.1 calls for a current inventory of in-scope system components, so describe container workloads by image, function and cluster rather than by individual instance.
Serverless functions
The 2018 cloud guidelines don't address serverless platforms directly, so we apply the same principles. The provider manages the host and runtime. You own the function code and its dependencies, the permissions the function runs with, the events that trigger it, the secrets it uses and how its activity is logged.
A function that handles PAN is part of the CDE. Functions, roles and pipelines that can invoke it, change its code or change its permissions are security-impacting. Pay particular attention to logging. Requirement 10 still applies, and the default logs from a serverless platform won't necessarily capture everything you need or keep it for 12 months.
How does segmentation work in the cloud?
Segmentation isn't a PCI DSS requirement in the cloud any more than on premises, but without it your whole cloud environment is in scope. The Cloud Computing Guidelines set a high bar: segmentation in a cloud environment should give isolation comparable to physical network separation.
PCI DSS v4.0's move from "firewalls and routers" to "network security controls" helps here, because the term covers virtual and cloud-native controls as well as physical devices. In practice, cloud segmentation usually combines several layers:
- Separate accounts, subscriptions or projects for CDE workloads, which give a strong administrative boundary.
- Isolated virtual networks with default-deny security groups or equivalent controls.
- Private connectivity to managed services, so CDE traffic doesn't cross networks it doesn't need to.
- Tight identity boundaries. In the cloud, the management plane is a network in its own right. Any identity that can modify CDE resources, security groups or logging is security-impacting, wherever it sits.
Watch for the paths that quietly reconnect what you separated. Network peering, transit gateways, cross-account roles, shared CI/CD pipelines and centralized logging with write access can all bridge the boundary.
Validating cloud segmentation
If you use segmentation to reduce scope, Requirement 11.4.5 requires penetration testing of the segmentation controls at least once every 12 months and after any changes. Service providers must test at least every six months under 11.4.6. Testing has to cover all segmentation methods in use, so cloud security groups and identity boundaries belong in the test plan alongside any traditional firewalls. Check your provider's penetration testing policy before you start.
Multi-tenant service providers have additional obligations in Appendix A1. Requirement A1.1.4, which calls for penetration testing of logical separation between customer environments at least every six months, is a best practice until March 31, 2025.
What changes as PCI DSS v3.2.1 retires?
PCI DSS v3.2.1 retires on March 31, 2024. Assessments after that date must use v4.0. For cloud environments, the requirements to prepare for now are 12.5.2 (confirming scope at least every 12 months and after significant changes), 12.8.5, and 12.9.2. The future-dated v4.0 requirements become mandatory on March 31, 2025, so it's worth identifying the ones that touch your cloud estate this year.
Frequently asked questions
If our cloud provider is PCI DSS compliant, are we compliant?
No. The provider's compliance covers the requirements it manages for the services it assessed. You still have to meet your own responsibilities and validate them.
Does the provider's AOC cover everything we use?
Only if every service you use is listed as included in its assessment. Check the AOC against your actual architecture, including newer services your teams may have adopted since your last review.
Is a separate cloud account enough to segment the CDE?
It's a strong start. Cross-account roles, network peering, shared pipelines and shared identity can still create paths into the CDE, so the boundary has to be tested rather than assumed.
Who handles logging in the cloud?
Usually both parties. The provider logs its own infrastructure, while you configure, collect, protect and review logs for the services and resources you control.
Key takeaways
- Treat every cloud provider as a TPSP, and get a current service provider AOC that lists the services you use.
- Build and maintain your own responsibility matrix for 12.8.5, based on the provider's information under 12.9.2.
- Expect more responsibility under IaaS and less under SaaS, but never none.
- Treat control planes, pipelines and privileged cloud identities as security-impacting.
- Segment with accounts, networks and identity, then penetration test every segmentation method in use.
- Finish the move to v4.0 before March 31, 2024, and plan for the future-dated requirements that take effect a year later.