Scoping cloud environments for PCI DSS: shared responsibility guide

How do you scope a cloud cardholder data environment for PCI DSS?

If your team has moved card data or payment systems into a cloud platform, you remain ultimately responsible for payment data security, and that responsibility cannot be outsourced to the provider. Your scope therefore depends on which provider services were actually assessed, not on the fact that the provider is PCI DSS compliant. The PCI SSC's August 2021 guidance on scoping cloud environments is the baseline for that discussion, and it is the document a QSA will expect you to have read. The answer varies with your architecture, the services you use and whether you are a merchant or a service provider. Start by listing every cloud service that stores, processes or transmits cardholder data, or that could affect the security of that environment, including identity, logging, key management and administrative tooling. For each one, ask the provider which services its current attestation covers. Then record which party meets each requirement in a written responsibility matrix, which the PCI SSC recommends in its written agreements guidance. Confirm the exact provider evidence with the provider and the QSA, because the matrix is only as good as the documents behind it.

Roles need to be stated plainly in the scoping file. Your organization owns its controls and the scope decision. An implementation partner can prepare the cloud accounts, network segmentation, logging and evidence for each requirement, but it does not decide scope or sign for you. Only a Qualified Security Assessor can issue the Report on Compliance, and the Attestation of Compliance that goes with it, after testing the environment. A diagram or a configuration export from a partner is input to the assessment, not validation. Before the QSA visit, make three decisions and document them: which cloud accounts and regions hold the cardholder data environment, which provider services fall inside your assessment and which sit outside it, and which customer responsibilities you will evidence yourself, such as due diligence, monitoring of the provider's compliance status, tokenization or strong cryptography. Ask the QSA early which provider reports and attestations it will accept as evidence, since the scope conclusion depends on that answer.

How the split changes for IaaS, PaaS and SaaS payment flows

With infrastructure as a service, the provider runs the physical facilities, hardware, hypervisor and base network fabric, while the customer builds and operates almost everything above that. The customer's virtual machines, operating systems, container hosts, virtual networks and storage are inside its own assessment scope, so it must produce evidence for most technical requirements. The provider's assessment normally covers the facility and infrastructure it runs, which is why its attestation does not transfer to the customer's configuration.

Network controls: The customer defines security groups, network access control lists, firewall rules and segmentation that restrict traffic into and out of the cardholder data environment.
Access and identity: The customer manages cloud accounts, roles, administrator access, MFA for console and remote access, and service account permissions.
Encryption keys: The customer typically selects, rotates and controls keys for data at rest and in transit, or documents exactly which keys the provider holds.
Logging and monitoring: The customer enables audit logs for control plane and workload activity, protects them and reviews them.
Operating systems and application code: The customer patches guest operating systems, hardens images and owns all application code.

Ask the provider which of its services sit inside the assessed scope, and confirm the split for each in writing.

How to confirm which provider services were actually assessed

This sequence turns a general statement that a cloud provider is PCI DSS compliant into a service-by-service record of what your cardholder data environment depends on, what the provider's assessment actually covers, and which gaps you must close yourself. The output is a scoping record you can defend to your QSA.

Inventory every cloud service in the payment flow
Your architecture or platform team lists each cloud service that stores, processes or transmits cardholder data, or that could affect the security of the cardholder data environment. Include compute, managed databases, storage, load balancers, key management, logging, identity, container platforms, and any SaaS tool that touches payment data or administrative access. Name the owner of each entry and tie it to a diagram of data flows. The step is done when the list matches what is actually deployed, checked against cloud account resource inventories rather than memory.
Request the provider's current AOC and service description
Ask the provider for its most recent Attestation of Compliance as a service provider, along with the service description or scope document that the assessor used to define which services were included. Request the date of the assessment and confirm it is current. Your procurement and security teams should hold these documents in your third-party file. The step is complete when you have both documents in hand and know their assessment date. Confirm with the provider how it notifies customers of changes to its validated scope.
Check each service against the assessed scope
Compare every service on your inventory with the provider's assessed scope, one line at a time. A provider's own compliance does not show that each product it offers was assessed, so a service can be missing from the attestation even when the provider is listed as compliant. Mark each service as assessed, partly assessed, not assessed, or not listed. Where the provider's scope document is unclear, ask the provider in writing which services and regions were included. The output is a checked table with a reason recorded for every non-assessed line.
Record gaps as customer duties or service replacements
For each service that was not assessed or only partly assessed, decide between two paths. Either you accept the requirements that fall to you for that service and document how you will meet them, or you replace the service with one the provider has validated. Record the decision, the owner and the evidence you will produce. A gap with no owner or decision is a finding waiting to happen. The step is complete when every gap line has a named disposition and no service in the payment flow is left unexplained.
Enter the results in the responsibility matrix
Transfer the checked scope into your responsibility matrix, which states for each PCI DSS requirement whether the provider meets it, you meet it, or both share it, and what evidence supports that split. Written agreements should reflect the same division. The PCI SSC's position is that the use of a cloud provider does not transfer ultimate responsibility for payment data security, so the matrix is the record that shows who does what. The step is done when the matrix, the contract and the assessed-services table agree with each other.
Set a re-check trigger for architecture changes
Define the events that require you to repeat this sequence. These include adding or moving services, opening new regions or accounts, changing network paths, adopting containers or serverless platforms, and any change to the provider's validated scope. A significant change to the environment can alter scope and may require reassessment, so each change should be reviewed against the inventory before it reaches production. Assign an owner for the change review and keep a dated log of each re-check. The step is complete when the trigger list is written into change management and the first re-check has been logged.

What makes cloud scope larger or smaller

Several design choices decide whether a cloud environment falls inside the cardholder data environment (CDE) or outside it. Each card below names one driver, how to control it, and what to check, so scope decisions can be documented and defended to an assessor.

Shared multi-tenant services

Shared infrastructure, databases and SaaS applications can put your payment data in the same resources as other customers. Appendix A1 sets additional requirements for multi-tenant service providers whose customers share these resources, so confirm whether your provider is assessed as multi-tenant and which of its services carry that assessment. Ask the provider to show which services appear in its current AOC. Anything outside that list belongs in your own scope until you have evidence otherwise.

Ephemeral workloads and containers

Autoscaling groups, short-lived containers and serverless functions can start and stop inside the CDE between scans and reviews. The September 2024 information supplement on modern network architectures addresses inventories of ephemeral cloud systems, so your scope method has to find them. Use infrastructure-as-code tags, admission policies that block unapproved workloads in the CDE, and automated inventory exports that record what ran during the assessment period.

Encryption and tokenization

Tokenization and encryption can take systems out of scope only when the systems no longer hold or can reach cardholder data in a usable form. Hashing or encrypting the PAN does not automatically remove a system from scope, and the answer depends on how keys and tokens are managed. Document where clear PAN exists, who can reach the key store and which systems can call the detokenization service, then test those boundaries before you rely on them.

Third-party scripts and APIs

Payment pages and integrations often load JavaScript from outside parties or call external APIs that receive card data or influence the payment flow. Each script source and API endpoint that can affect the payment page or transmit account data must be known, justified and monitored. Build an inventory of scripts and integration points, record which provider is responsible for each, and confirm how changes to those third parties are detected and approved.

Multi-cloud and hybrid links

Connections between cloud accounts, on-premises data centers and other providers extend the CDE through network paths that are easy to overlook. VPNs, peering links, transit gateways and interconnects can carry cardholder data or let an attacker move between segments. Treat every link into the CDE as a boundary to document, restrict to named flows and test with segmentation checks, following the approach set out in the September 2024 information supplement.

Shared administrative access

Administrators who manage both the CDE and non-payment systems, or who use shared consoles and provider support accounts, can bring those systems into scope. Access to the cloud control plane can change configurations across every account, so it is often as sensitive as access to the data itself. Limit administrative roles to named individuals, require MFA for console and API access, separate production payment accounts from other accounts, and review who can assume privileged roles each quarter.

Multi-tenant provider requirements and the responsibility matrix

If your platform runs on shared provider resources, the first question is whether your own environment is a multi-tenant service provider under PCI DSS. Appendix A1 adds requirements for multi-tenant service providers whose customers share resources such as servers, infrastructure, applications (including SaaS) or databases, and PCI SSC FAQ 1221 is not a source you can cite here, so confirm the applicability of A1 against the standard itself and your assessor's reading. Once you know whether A1 applies, map which tenant isolation controls sit in your code and configuration and which sit in the provider's shared platform. Your responsibility matrix should record each one explicitly, because a shared resource does not transfer responsibility for the tenant separation you provide.

The responsibility matrix is the working record of which party meets which requirement, and it is the artifact that links your written agreements to your assessment. Requirement 12.8 covers management of third-party service providers, and 12.9 covers the written acknowledgment that a service provider gives to its customers. In practice, the matrix lists each requirement, the party that performs it, the evidence that proves it and the date that evidence was last reviewed. PCI SSC FAQ 1312 makes an important point for this record: the standard does not require a third-party service provider to be PCI DSS compliant, but it does require you to monitor that provider's compliance status as specified. A provider with no current assessment can still be used, provided you can show the monitoring you carried out and the controls you added.

Your assessor's independence and workload depend on the evidence you bring. PCI SSC FAQ 1290 states that a QSA does not need to go onsite at a validated provider or retest requirements already covered by that provider's current assessment. That relief only holds when the provider's Attestation of Compliance covers the specific services you use, so confirm the services listed in the AOC before you rely on it. Ask the provider for its current AOC, the list of services in scope, and any responsibility matrix it publishes, then compare each line against your own matrix. Gaps you find at this stage are cheaper to close than gaps an assessor finds during the audit.

Who is paid for what when scoping a cloud CDE

This table lists the cost components of scoping a cloud cardholder data environment, who is paid for each, whether it is one-time or recurring, and what drives it up. Read it as a checklist for requesting written quotes that separate assessor fees, implementation work, provider charges and the internal time that no outside party can take over. No amounts are given, because the cost of each component depends on the scope agreed in writing.

Cost component	Who is paid	One-time or recurring	What drives it
QSA assessment fee	Qualified Security Assessor, for testing and writing the Report on Compliance or validating scope	Recurring, at each annual assessment, with extra effort after significant change	Number of in-scope services and locations, how many provider evidence packages the QSA must review, and the quality of scope documentation
Implementation partner work on architecture and evidence	Implementation partner, for network segmentation design, configuration, and evidence preparation	Mostly one-time for the initial build, with periodic updates	Number of accounts, subscriptions and network paths, degree of existing automation, and how much evidence must be produced from scratch
Cloud provider fees for compliant services	Cloud provider, for the services the organization runs inside the CDE	Recurring, billed by usage or subscription	Choice of services, whether a service is in the provider's assessed scope, and extra logging, encryption or dedicated infrastructure needed to meet requirements
Tooling for inventory and monitoring	Tool vendors or open-source maintainers, plus staff or partner time to run them	Licenses or hosting recur; setup is one-time	Number of cloud accounts, ephemeral workloads, log volume, and whether inventory must cover every system in scope
Internal staff time for owner and matrix maintenance	Internal staff, paid through payroll or existing budgets	Recurring, tied to reviews and provider changes	Number of providers and services, frequency of provider AOC reviews, and how often the responsibility matrix changes
Re-scoping after significant change	QSA for validation, implementation partner for changes, and internal staff for impact analysis	One-time per change, recurring as the environment changes	Size of the change, new services or regions added, provider changes, and whether segmentation is affected

Who owns each part of cloud PCI DSS scoping

Your organization owns the cardholder data environment and every decision about it. The PCI SSC is clear that using a cloud provider does not remove your ultimate responsibility for payment data security, and that responsibility cannot be outsourced. Your team decides what is in scope, which requirements it meets directly, and how it monitors the parties it relies on.

Scope decisions: You define which accounts, subnets, clusters, databases and identities store, process or transmit account data, or could affect their security.
Responsibility matrix: You agree in writing with each provider which party meets which requirement, and you keep that record current.
Provider oversight: You perform due diligence before engagement and monitor each provider's compliance status over time.
Customer-side controls: You limit exposure to payment data, protect it with strong cryptography, tokenization and masking, and enforce MFA for your own users.
Resiliency assessment: You assess whether each provider can keep the payment environment available and recoverable.

Before relying on any provider, confirm with your own team who signs the matrix and who receives provider evidence each year.

Scoping mistakes that delay assessments

Most delayed PCI DSS assessments trace back to a handful of scoping decisions made early and never revisited. The cards below cover the mistakes we see most often in cloud environments, and the check that prevents each one from reaching the QSA.

Assuming the provider's AOC covers everything

A cloud provider's own PCI DSS compliance as a service provider does not show that every service it offers was assessed. Check which services appear in the provider's Attestation of Compliance and responsibility documentation, and list every service your cardholder data environment touches. Any service missing from the provider's assessed list stays inside your scope and needs your own evidence.

Missing ephemeral cloud systems

Autoscaling groups, short-lived containers, serverless functions and build runners can hold or touch card data without appearing in a static inventory. Ask the team to generate inventory from cloud APIs and orchestration records rather than architecture diagrams, and reconcile that output against the CDE data-flow diagram at a fixed interval. The September 2024 information supplement addresses inventories of ephemeral cloud systems and is the reference to review.

No written responsibility matrix

Teams often assume the provider handles a requirement because the provider is compliant, and no one records who actually performs it. Build a responsibility matrix that assigns each requirement to the provider, the customer or both, and cite the provider evidence for each provider-owned item. Written agreements should match the matrix, so assessors do not find a requirement that nobody owns.

Logging and key management left out of scope

Centralized log stores, SIEM pipelines and cloud key management services often sit outside the diagram because they are administered by a separate team. Yet they protect and record access to cardholder data, so they usually belong in scope or in a documented, evidenced responsibility split. Confirm where audit logs are written, who can read or delete them, and which key service encrypts stored PAN, then include each component in the inventory.

Unmanaged vendor remote access

Support engineers, managed service staff and integration partners often connect into cloud consoles, bastion hosts or Kubernetes clusters through accounts that predate the current review cycle. Each vendor connection that can reach the CDE is in scope, so list every remote access path, require individual accounts with multi-factor authentication, and time-limit or approve sessions. Keep the access log with the matrix so the assessor can trace who connected and why.

Skipping re-scoping after architecture change

A new region, a new managed database or a migration to containers can move card data into systems nobody reviewed. Treat each significant change as a trigger for re-scoping, and record the date, the systems added or removed, and the segmentation test that confirmed the boundary. The PCI SSC's significant change guidance is the reference for deciding when a change requires this step.

Questions buyers ask about cloud PCI DSS scope

Does our cloud provider's PCI DSS attestation cover our environment?

Not automatically. A cloud provider's own PCI DSS compliance as a service provider does not show that every service it offers was assessed. Check the provider's Attestation of Compliance and confirm, service by service, which offerings fall inside it. Services outside that list still count toward your scope, and you need to treat them as in scope until the provider's evidence shows otherwise. Ask the provider for a written list of covered services, the date of its current assessment, and the responsibility matrix that maps each PCI DSS requirement to a party. The ultimate responsibility for payment data security stays with your organization either way.

Can we scope our cloud CDE ourselves without outside help?

Often yes, if your team understands where cardholder data flows and can document it. Scoping starts with an inventory of every system that stores, processes or transmits account data, plus every system that can affect their security, including identity, logging, network and management planes. Cloud environments change quickly, so the inventory must be repeatable and tied to your deployment tooling. Outside help becomes more valuable when accounts are shared, when infrastructure is ephemeral, or when the assessor will question your boundary. Whichever way you go, your assessor makes the final call on scope, so agree the method with them early.

How much effort does cloud PCI DSS scoping take from our team?

The effort depends on the size of the environment, how many accounts and services sit in the payment flow, and how well the existing architecture is documented. Expect the largest share of work in the first scoping cycle, when the team builds the data-flow diagrams, the system inventory and the responsibility matrix. Later cycles are smaller but recur, because each significant change, such as a new service or region, can alter scope. Ask any consultant to break the work into inventory, mapping, provider evidence collection, segmentation testing and assessor support, and to state which of those your staff must perform. No duration is fixed here, so request an estimate tied to your written scope.

What should we request from our cloud provider for PCI DSS?

Request evidence that lets you verify the provider's compliance and your own responsibilities. The core items are:

The current Attestation of Compliance and the list of services it covers.
A responsibility matrix that assigns each PCI DSS requirement to the provider, to you, or to both.
Confirmation of the provider's status as a service provider and the dates of its assessment.
The provider's process for notifying you of material changes to covered services.
Documentation of the controls you must configure yourself, such as encryption, tokenization, multi-factor authentication and logging.

If the provider cannot show evidence for a service you use, treat that service as a gap until it can, and record the decision in your scope documentation.

Does our QSA have to visit the cloud provider onsite?

No, not in every case. The PCI SSC does not require a client's QSA to go onsite to a validated third-party service provider and retest requirements already covered by that provider's current assessment. The QSA still needs enough evidence to rely on the provider's work, and it decides how much to review. Expect the QSA to examine the responsibility matrix, the provider's AOC scope and the controls you own. Where the provider's evidence does not cover a requirement, the QSA may need to test it directly, which can mean reviewing configurations or interviewing staff. Confirm the approach with your assessor before fieldwork begins.

Is a SOC 2 report enough to show PCI DSS coverage for a cloud provider?

A SOC 2 report can be useful evidence, but it does not replace PCI DSS validation on its own. The PCI SSC's guidance on relying on SOC 2 reports, FAQ 1567, leaves the decision to the QSA, who determines whether the report covers the relevant PCI DSS requirements, the services in scope and the time period tested. Bring the report's system description, the list of controls and any exceptions to your assessor. Gaps in the SOC 2 scope, such as payment-specific controls like cardholder data handling, will still need evidence from elsewhere. Treat the SOC 2 report as one input to the responsibility matrix, not as proof of compliance.

What does a cloud scoping engagement need from our organization?

A scoping engagement needs access, accurate information and named decision-makers. Expect to provide cloud account structure and architecture diagrams, network and data-flow documentation, a list of identity providers and administrative paths, the provider contracts and their AOCs, and the ticketing or change records that show how the environment evolves. Someone with authority must agree the scope boundary and accept the responsibility matrix. Where DeployOpen is engaged, the written scope will name the systems, deliverables and timelines, and your organization keeps ownership of its controls and final sign-off. Confirm with any partner which items they need before work starts.

How DeployOpen prepares cloud scope and evidence for your assessment

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own cloud accounts, so the scope record and evidence set are built from the systems you actually run. Before any build, we can help you produce the component inventory, the architecture documentation that shows where cardholder data enters, is stored, is processed and leaves, and the segmentation design that separates the cardholder data environment from everything else. The work is scoped in writing before it starts, and the outputs are yours: the inventory, the data-flow and network diagrams, the segmentation rules and their test results, and a draft responsibility matrix that lists which party meets each requirement for each component in the environment. The draft matrix is where the shared responsibility question becomes concrete. For every cloud service in the payment path, we can record which provider services are named in the provider's own assessment, which are not, and which controls you must run yourself, such as key management, access reviews, logging configuration and file integrity monitoring. Where a provider cannot show evidence for a service, the draft marks that gap as open rather than assuming coverage. You should confirm the provider's current Attestation of Compliance and service list directly with the provider, and ask your QSA to agree the matrix before it is treated as final.

DeployOpen does not issue Reports on Compliance, Attestations of Compliance or certificates. Those are issued only by independent assessors, such as a Qualified Security Assessor, after they test your environment. Your organization owns its controls and its scope decisions, and your QSA decides what is in scope for validation. Our role is to prepare the systems, documentation and evidence so the assessor can test them efficiently, and to hand over a scope record and matrix draft for your team and your QSA to review. Hiring an implementation partner does not guarantee an assessment outcome. Scope can change as the environment changes, and a significant change to the cardholder data environment may require the scope to be revalidated. Plan for that by assigning an internal owner for the scope record, deciding who reviews the matrix each time a provider or architecture changes, and asking your QSA early which evidence they expect to sample. Ask any partner, including DeployOpen, for the written scope, deliverables, acceptance criteria and the handover list before work begins.

Scoping cloud environments for PCI DSS: shared responsibility with providers