PCI DSS 4.0 in the cloud: the only strategy that works is shrinking the scope

PCI DSS has around 300 requirements and they apply to every system component in the cardholder data environment, plus every system connected to it, plus every system that could affect its security. That last clause is what turns a payment feature into a company-wide project.

So the first and most valuable piece of work is not implementing controls. It is deciding what is in scope, and then making that set as small as possible.

The scoping question, precisely

A system is in scope if it stores, processes or transmits cardholder data; if it is on the same network segment as something that does; or if it can affect the security of the cardholder data environment — which includes your identity provider, your CI system, your monitoring, your bastion hosts and anything with administrative access.

That last category surprises people. Your CI pipeline deploys to the payment service, so your CI pipeline is in scope. Your SSO controls who can log in, so it is in scope. The monitoring agent running on the payment servers is in scope.

Once you see this, the strategy becomes obvious: get cardholder data out of your systems entirely, and isolate what remains.

Removing scope: the three moves that matter

A hosted payment page or hosted fields. If card data goes from the customer's browser directly to the payment provider and never touches your infrastructure, your validation drops to SAQ A — a handful of requirements about your website, redirect integrity and vendor management. This is the single largest reduction available and it is an architectural decision, not a security one.

Note that PCI DSS 4.0 added requirements 6.4.3 and 11.6.1 covering scripts on payment pages and change detection on them, driven by e-skimming attacks. Even SAQ A has more to do than it used to: you need an inventory of the scripts on the payment page, justification for each, and a mechanism to detect unauthorised changes.

Tokenisation. If you need card-on-file for repeat payments, store the provider's token, not the card. A token that is useless outside your merchant account is not cardholder data, and the database holding it is out of scope.

Network segmentation. For whatever remains, segment it properly — a separate cloud account or subscription, not a security group. Cross-account boundaries are easier to evidence to an assessor than intra-VPC rules, and they prevent the gradual scope creep that happens when someone puts a "temporary" service in the wrong subnet. If segmentation is used to reduce scope, it must be tested annually (every six months for service providers), so make it a boundary that is simple to describe and test.

What 4.0 changed that affects cloud teams

The 4.0 requirements became mandatory on 31 March 2025, after a long transition. The ones that reliably cause work:

Requirement 8.3.6 — minimum 12-character passwords with complexity, where passwords are used. Many legacy service accounts do not meet this.

Requirement 8.4.2 — MFA for all access into the cardholder data environment, not just administrative and not just remote. This is broader than 3.2.1 required and often means reworking service-to-service access.

Requirement 8.6 — accounts used by applications and systems need managed, rotated credentials with justification for interactive use. In cloud terms: workload identity federation rather than static keys.

Requirement 12.3.1 — a targeted risk analysis for every requirement that allows flexibility in frequency. If you choose to do something quarterly rather than monthly, you need a documented analysis justifying it. This is new paperwork attached to many existing controls.

Requirement 11.6.1 — change and tamper detection on payment pages, as above.

The customised approach. 4.0 allows meeting the objective of a requirement by a different means, with documented risk analysis and evidence of effectiveness, agreed with your assessor. This is genuinely useful for cloud-native architectures where the prescriptive control assumes a server you can log into. It also costs more assessor time, so use it where it matters rather than everywhere.

Shared responsibility, documented per service

Your cloud provider's PCI DSS Attestation of Compliance covers their infrastructure and specific services. You inherit those controls, but you must document which ones, for which services, and confirm the service is in the provider's PCI-compliant scope — not every service is, and the list changes.

Keep the provider's responsibility matrix alongside your own documentation, and re-check it at each annual assessment. An assessor will ask which controls you consider inherited and will expect the AOC to support the claim for the specific services and regions you use.

The practical sequence

Map the cardholder data flow first, on one diagram, including the browser. Then remove what you can: hosted fields, tokenisation, deleting historical card data you never needed. Then segment what is left. Then, and only then, work through the requirements for the much smaller environment that remains.

Teams that do it in the other order — implementing 300 requirements across the estate and then discovering they could have used a hosted payment page — spend a year on a project that could have been a quarter. The evidence discipline is the same as any other framework, so an existing ISO 27001 or SOC 2 programme makes the remaining work considerably lighter.