PCI DSS 4.0 for product teams: scope reduction and the requirements that bite

01Scope is the whole game

PCI DSS applies to the cardholder data environment - every system that stores, processes or transmits cardholder data, plus anything connected to it that could affect its security. That last clause is what makes scope grow unexpectedly, because a shared network or a jump host pulls neighbouring systems in.

The correct instinct is to design so that card data never enters your systems at all. Hosted payment fields and redirect flows keep the card number in the payment provider's iframe or page, so your servers never see it. This is not a compliance trick - it genuinely removes the risk, which is why the assessment burden falls too.

02What 4.0 changed for engineering

Version 4.0 became the sole active standard after v3.2.1 retired in March 2024, with a set of future-dated requirements that became mandatory on 31 March 2025. Several of those land squarely on engineering rather than on policy.

The client-side script requirements are the ones that catch teams out. If you take payments in the browser, you now need to manage and monitor the scripts on your payment pages and detect unauthorised modification of the page - a direct response to digital skimming attacks that inject script into checkout flows.

• Inventory and justify every script on a payment page, with integrity assurance.
• Detect and alert on unauthorised changes to payment page content.
• MFA for all access into the cardholder data environment, not just administrators.
• Stronger password requirements where passwords remain in use.
• Targeted risk analyses documenting the frequency of periodic controls.
• Authenticated internal vulnerability scanning.

03The customised approach, and who it is for

Version 4.0 introduced a customised approach: rather than implementing the defined control, you may meet the stated objective by another means, supported by a documented risk analysis and validated by your assessor.

This is genuinely useful for mature organisations with strong alternative controls, and a trap for everyone else. It requires more documentation and more assessor engagement than simply implementing the defined control. If you are asking whether it applies to you, it probably does not.

04Storage: the requirement to avoid entirely

If you never store cardholder data, a large set of requirements becomes non-applicable. Almost no product genuinely needs to store card numbers - recurring billing, one-click checkout and refunds are all supported through provider-issued tokens.

Where storage is genuinely unavoidable, sensitive authentication data must never be retained after authorisation. That means no CVV, no full magnetic stripe, no PIN data, under any circumstances - including in logs, which is where it most often ends up by accident.

• Use provider tokens for anything requiring a stored payment method.
• Never log full card numbers or CVV, at any level, even temporarily.
• Mask PAN in any interface, retaining at most first six and last four.
• Check error tracking and log aggregation for accidental capture.

05A practical sequence

For most product teams the work is: reduce scope aggressively, confirm which SAQ applies, then implement what remains. Teams that start with the requirement list and work backwards do far more work than necessary.

• Map every path card data could take, including logs and support tooling.
• Move to hosted fields or redirect if anything touches your servers.
• Confirm SAQ eligibility with your acquirer before assuming it.
• Inventory and lock down scripts on payment pages.
• Enforce MFA into any remaining cardholder data environment.
• Establish quarterly scanning and a documented remediation path.