PCI DSS applies in the cloud the same way it applies anywhere else: if a cloud service stores, processes, or transmits cardholder data, or can affect the security of the cardholder data environment, it can become part of PCI DSS scope. Moving payment systems to AWS, Azure, Google Cloud, or a SaaS provider does not move the compliance responsibility with them.
What changes is the ownership of the controls. The cloud provider may operate the physical infrastructure, hypervisor, managed database, or SaaS platform. The customer may still own identity, application security, network configuration, logging, card-data flows, retention, and the way the service is connected to the rest of the environment. In many setups, a control is shared rather than owned by one side.
Cloud PCI work gets easier once four questions are separated: what is in scope, what the provider covers, what the customer still owns, and what evidence proves the split. This table gives the short version.
| Question | Short answer | What to verify |
| Does PCI DSS apply in the cloud? | Yes. Cloud hosting does not create an exemption. | Data flows, CDE boundaries, connected systems, and security-impacting services. |
| Does a PCI-compliant cloud provider make us compliant? | No. The provider's validation covers its assessed services and responsibilities. | Current AOC/status, in-scope services, customer duties, and shared controls. |
| Can cloud reduce PCI scope? | Sometimes, especially when payment processing or PAN storage is outsourced. | What card data still reaches your systems and which systems can affect its security. |
| Who owns PCI controls? | It depends on the service model and contract. Some controls are shared. | A responsibility matrix tied to the actual service, not a generic IaaS/PaaS/SaaS diagram. |
| Are AWS, Azure, and Google Cloud usable for PCI workloads? | Yes, using their in-scope services and a compliant customer design. | Provider scope, service configuration, IAM, logging, network controls, data protection, and validation evidence. |
For the wider standard, see our PCI DSS requirements guide covering scope, validation, and all 12 requirement groups.
Yes. PCI DSS is concerned with the account-data environment and the systems that can affect it, not with whether those systems sit in a company-owned data center. PCI SSC also makes clear that outsourcing payment processing does not remove an organization's PCI DSS responsibilities. Its current FAQ on outsourced payment processing says merchants that outsource all processing still need to manage the provider relationship and validate their own applicable obligations.
That can produce a much smaller technical scope, which is often the goal. A merchant that redirects payment collection to a properly designed third-party payment page may have far less card data in its own environment than a company running payment APIs and databases in its cloud account. Smaller scope is useful, but it has to come from the actual data flow and system relationships.
For the transaction-level view, our payment processing security guide explains how hosted payment pages, browser-side code, payment APIs, processors, stored account data, and provider responsibilities fit together around the payment flow.
If the boundary is still fuzzy, our What Is the CDE in PCI DSS? guide explains the difference between the cardholder data environment, connected-to systems, and systems that can affect CDE security.
Usually, it means the provider has been assessed for a defined set of services and responsibilities. It does not mean every service the provider sells is automatically in scope for its PCI validation, and it definitely does not mean anything a customer deploys on top of those services becomes compliant by inheritance.
PCI SSC's current third-party service provider FAQ is helpful because it keeps the responsibility with the customer. Organizations using a third-party service provider must manage the relationship, perform due diligence, maintain appropriate agreements, understand which PCI DSS requirements are handled by which party, and monitor provider compliance status at least annually.
The wording matters here. Requirement 12.8 does not simply say "buy from a PCI-compliant vendor and you are done." In fact, PCI SSC notes that 12.8 itself does not require every TPSP to be PCI DSS compliant. What the customer needs is enough current information to understand the provider's status and whether the PCI DSS requirements assigned to that provider are actually met.
In practice, that means asking for the current Attestation of Compliance where one is available, checking which services are covered, confirming the assessment period, and mapping the responsibility split to your architecture. A logo on a trust page is not enough evidence for a serious assessment.
The older PCI SSC cloud supplement is still useful here because the basic responsibility pattern has not disappeared. The more of the technology stack the provider operates, the more controls it can perform on the customer's behalf. The customer still has to understand the exact boundary for the service it bought.
| Cloud model | Provider commonly handles more of | Customer commonly still handles |
| IaaS | Facilities, physical hardware, core networking, virtualization layer. | Guest OS, patching, IAM, applications, data, security groups, logs, secrets, workload configuration. |
| PaaS | Infrastructure plus more of the operating platform, runtime, and managed service layer. | Application code, identities, data, service configuration, integration, logging choices, access paths. |
| SaaS / payment service | Application platform and a larger share of infrastructure and application controls. | User access, account configuration, integrations, data sent to the service, third-party oversight, retained PCI duties. |
Those are starting assumptions, not a responsibility matrix. A managed Kubernetes service can leave very different work with the customer than a managed database. A SaaS payment platform can handle card data while the merchant still owns website scripts, administrator accounts, DNS, redirects, and the integration around the payment flow.
The useful document is a requirement-by-requirement responsibility matrix for the actual service. It should show provider-owned controls, customer-owned controls, shared controls, and the evidence available from each side. If a control is marked "shared," somebody still needs to explain the two halves.
Cloud does not automatically make PCI DSS cheaper. Provider coverage can remove some work, but customer-side configuration, evidence, testing, and remediation still affect the budget. Our PCI DSS compliance cost guide explains the main cost drivers.
Start with the card-data flow, then look outward. Cloud scope can include obvious systems such as payment applications and databases, but the less obvious components are where teams often lose time during an assessment.
Depending on the architecture, the scope can include cloud accounts and subscriptions, virtual networks, security groups, load balancers, API gateways, managed databases, object storage, containers, serverless functions, identity services, secrets stores, key-management services, logging pipelines, administrative jump paths, CI/CD systems, and security tooling that can change or affect CDE controls.
This does not mean the entire cloud estate is automatically in scope. It means scope has to be argued from connectivity, access, security impact, and data flow. A separate analytics account that receives only properly de-identified data may have a different status from a corporate IAM system that can create administrators inside the CDE.
Tokenization can also change the boundary. Our PCI DSS tokenization and encryption guide explains when token-only systems may sit outside the CDE and why de-tokenization paths, vaults, and security-impacting components still matter.
All three major platforms publish PCI DSS compliance material, but the useful answer is more specific than yes or no. The provider validation covers defined services and provider responsibilities. Your cloud workload still needs its own PCI DSS scope, configuration, controls, and validation route.
AWS publishes its PCI DSS compliance FAQs and lists services covered by its compliance programs. Microsoft publishes an Azure PCI DSS compliance offering with provider status and a shared-responsibility matrix. Google Cloud likewise publishes its PCI DSS compliance page and identifies services reviewed by its QSA.
The practical check is the same for AWS, Azure, GCP, or another provider: confirm the exact service you use is included in the provider evidence, then identify the controls the customer must implement. A PCI-validated storage service can still be configured with excessive public access. A compliant managed database does not fix an application that exposes PAN. A provider AOC and a customer assessment answer different questions.
Cloud storage is one of those areas where the platform can be secure and the implementation can still be a mess. The first question is whether PAN needs to be stored there at all. If it does, Requirement 3 applies to the stored account data, including retention, protection, access, and key-management decisions.
Object storage, managed disks, snapshots, database backups, exports, data lakes, and recovery copies all deserve the same scope discussion. Teams sometimes protect the production database and forget that yesterday's snapshot contains exactly the same card data.
Encryption helps protect stored PAN, but it does not automatically remove encrypted cardholder data from PCI DSS scope. Where possible, reducing PAN through tokenization or removing unnecessary copies is usually easier to reason about. The PCI DSS tokenization and encryption guide covers that decision in more detail.
Key access also matters. If administrators, workloads, or automation can read encrypted PAN and use the key-management service to decrypt it, the relevant identity and key paths belong in the security discussion. Our PCI DSS password and authentication requirements guide covers the identity side of that boundary.
Cloud platforms generate a lot of useful security data, but "the provider has logs" is not the same as having Requirement 10 covered. The customer needs the right sources enabled, collected for the required environment, protected, retained, reviewed, and tied to alert handling.
For a cloud CDE, that can mean identity and authentication events, administrative changes, control-plane activity, network and firewall changes, storage access, database activity, key-management events, workload logs, security-tool alerts, and changes to logging itself. Which sources matter depends on the architecture.
There is a mundane operational problem too: cloud logs can exist in different accounts, regions, subscriptions, projects, and provider consoles. If the investigation team cannot get to them during an incident, the logging design is only partly finished.
Our PCI DSS Requirement 10 guide covers logging, monitoring, review frequency, alert handling, retention, and the evidence an assessor is likely to ask for.
Cloud hosting does not remove Requirement 11 testing. What changes is the testing surface and, sometimes, the provider rules for how testing may be performed. The customer still needs to know which public endpoints, internal systems, applications, APIs, segmentation controls, and cloud services fall inside the testing scope.
External vulnerability scanning may require an Approved Scanning Vendor where PCI DSS calls for ASV scans. Internal scans still need to cover the applicable in-scope environment. Penetration testing is a different activity and should test the attack paths, segmentation, applications, and infrastructure required by the organization's PCI DSS scope.
For the scanning side, see our PCI DSS vulnerability scanning and vulnerability management guide. For the testing engagement itself, the existing PCI DSS penetration testing requirements guide covers Requirement 11.4 scope and evidence.
Prepare a cloud or hybrid CDE for Requirement 11.4 testing
Use the playbook to define the test scope, include cloud and hybrid attack surfaces, prepare segmentation evidence, and reduce avoidable rework before the assessment cycle.
Get the PCI DSS Penetration Testing PlaybookA good provider evidence pack should make the responsibility split easier to prove, not create another folder of PDFs nobody has read. The exact evidence depends on the service and validation route, but there is a fairly predictable core.
For each relevant provider, keep enough information to show what service is being used, how it affects the CDE, what PCI DSS responsibilities the provider performs, what remains with the customer, and whether the provider's compliance status is current.
In practice, that often means:
The assessment itself still needs to connect that provider evidence to the customer's controls. Our PCI DSS audit and assessment guide explains how scope, evidence, SAQs, ROCs, AOCs, remediation, and assessor review fit together.
The failures are usually less dramatic than people expect. Most come from responsibility gaps, scope assumptions, or cloud features that were enabled without anybody asking what they changed for PCI.
The patterns we would watch for are:
A useful review starts with architecture, not with the provider's compliance page. Once the actual environment is understood, provider evidence becomes much easier to use.
If the review identifies frequency or control-design decisions that depend on risk, our PCI DSS risk assessment guide explains targeted risk analysis and how to document the rationale without turning it into a generic risk register exercise.
Cloud can reduce a lot of operational work. It can also reduce PCI scope when the payment architecture genuinely keeps card data and security-impacting functions away from the rest of the business environment. Neither outcome happens just because the provider has a PCI page.
The workable model is more ordinary: know the card-data flow, know the exact services in use, write down who owns each control, keep the provider evidence current, and test the customer side as carefully as the provider side. If the two responsibility maps do not meet cleanly, the gap belongs to somebody. It just has not been assigned yet.
Build a cloud PCI scope that matches the real environment
Q-Sec supports PCI DSS readiness, scope and evidence work, penetration testing coordination, and ongoing security controls across cloud and hybrid environments.
Explore PCI DSS Compliance ServicesAWS maintains PCI DSS compliance for defined in-scope AWS services. That provider status does not make a customer workload compliant. The customer still owns its PCI DSS scope, configuration, applications, identities, data, and assigned controls.
Microsoft publishes PCI DSS validation for in-scope Azure services and a shared-responsibility matrix. Customers still need to build and validate their own PCI DSS environment on top of those services.
Google Cloud lists services reviewed by its QSA under PCI DSS v4.0.1. A customer using those services still has to meet the PCI DSS requirements that remain on the customer side.
Not automatically. It depends on what data it stores, what can access it, and whether it can affect CDE security. Storage holding PAN, backups, snapshots, or decryption paths usually needs close scope review.
No. Encryption protects PAN, but encrypted cardholder data can remain in scope when systems can decrypt it or otherwise affect its security. Scope depends on access, keys, architecture, and control boundaries.
Yes, although your technical scope may be much smaller. You still need to manage the provider relationship, understand shared responsibilities, and complete the validation route required by your acquirer or payment brand.
You need current information that supports the provider's compliance status and responsibility split for the services you use. An AOC is common evidence when available, but the exact documentation depends on the provider and your validation route.