PCI DSS v4: what changed, and the requirements that catch people out

PCI DSS v4 is the largest revision the standard has had, and the difficulty is not the number of requirements - it is that several of them require ongoing engineering work rather than a documented policy. Organisations that treated previous versions as an annual paperwork exercise feel this version most.

The customised approach

The headline structural change. Every requirement can now be met two ways:

• Defined approach - implement the requirement as written and be tested against the stated procedures. This is what everyone did previously, and it remains available.
• Customised approach - meet the stated objective by another means, provided you document how, perform a targeted risk analysis, and demonstrate effectiveness. The assessor then designs bespoke testing procedures.

This is aimed at mature organisations with modern architectures where the prescribed control does not map cleanly. It is deliberately demanding: you carry the burden of evidencing that your alternative achieves the objective, and assessors need more time, which costs more.

Do not confuse it with compensating controls, which still exist and are for cases where a requirement genuinely cannot be met due to a legitimate constraint. The customised approach is a design choice; a compensating control is a workaround for an obstacle.

Most organisations should stay with the defined approach for almost everything, and reserve the customised approach for the small number of requirements where their architecture genuinely conflicts.

Targeted risk analysis

Several requirements no longer state a fixed frequency - instead you determine it through a documented targeted risk analysis covering what is being protected, the likelihood and impact of failure, and why your chosen frequency is adequate. You then review that analysis periodically.

It is more flexible and more work. Every requirement where you set your own frequency needs an analysis on file, and assessors will ask for it. Organisations that ignore this and keep the old frequencies without documentation end up with findings against requirements they technically satisfy.

The changes that cost engineering effort

• Payment page scripts. You must manage and inventory every script on payment pages, justify each, and detect unauthorised change. This is the response to digital skimming, where the attack never touches your servers - and it usually requires new tooling, a Content Security Policy, and an owner for a script inventory nobody previously maintained.
• Client-side tamper detection on payment pages, checking HTTP headers and page content for unauthorised modification.
• MFA everywhere in scope. Previously focused on remote and administrative access, now required for all access into the cardholder data environment - including console access by internal staff. This is a substantial widening.
• Anti-phishing controls, both technical and awareness-based, called out explicitly.
• Automated log review. Manual daily log inspection is no longer realistic under the wording; automated mechanisms are expected.
• Authenticated internal vulnerability scanning - unauthenticated internal scans no longer suffice.
• Password length increased for accounts within scope, with alternatives where dynamic analysis of posture is used instead.
• Roles and responsibilities documented per requirement - a small change that touches everything, because each requirement now needs an assigned owner.

What did not change

The twelve top-level requirements and the fundamentals: segment to reduce scope, do not store what you do not need, encrypt what you do store, control access, log, test, and maintain a policy. If your programme is sound against v3.2.1, v4 is an extension rather than a rebuild - the delta is real but bounded.

Preparing sensibly

1. Re-confirm scope first. Scope reduction remains worth more than any control - tokenisation and hosted payment fields remove requirements outright.
2. Gap assess against v4 specifically, not against your last report.
3. Prioritise the engineering items - script management, tamper detection, MFA expansion, automated log review - because they have lead times.
4. Write the targeted risk analyses for every requirement where you set the frequency.
5. Assign a named owner to each requirement.
6. Decide deliberately where, if anywhere, the customised approach is justified - and budget the extra assessor time.

Key takeaways

• Customised approach is for architectural mismatch, not for avoiding effort.
• Every self-set frequency needs a documented targeted risk analysis.
• Script management, tamper detection and expanded MFA are the real engineering cost.
• Scope reduction still beats every control decision you will make.