PCI DSS 4.0: What Changed and What It Means

PCI DSS applies to any organisation that stores, processes or transmits payment card data. Version 4.0 represents a substantial revision, with a transition period during which future-dated requirements progressively became mandatory. The changes reflect a shift in how the standard thinks about security — from prescribing specific controls toward accommodating different ways of achieving the same objective.

The customised approach

The most significant structural change is the introduction of a customised approach alongside the traditional defined approach.

The defined approach works as before: implement the control as specified. The customised approach lets an organisation meet the stated security objective differently, provided it documents the approach, performs a targeted risk analysis, and demonstrates to its assessor that the objective is genuinely achieved.

This offers real flexibility for mature organisations with modern architectures that do not map neatly onto prescriptive controls. It is not a shortcut — the evidentiary burden is higher, not lower, and assessors must be satisfied the objective is met.

What tightened

• Authentication — stronger expectations around multi-factor authentication for access into the cardholder data environment, and updated password requirements.
• Payment page scripts — new requirements to manage and monitor scripts on payment pages, responding directly to digital skimming attacks that compromise a third-party script rather than your own server.
• Phishing defence — explicit expectations around anti-phishing mechanisms, acknowledging it as a primary intrusion route.
• Targeted risk analysis — several requirements now let you set your own frequency, provided you justify it with a documented analysis. Flexibility with evidence attached.
• Roles and responsibilities — requirements now expect documented ownership, closing the familiar gap where everyone assumed someone else was doing it.
• Continuous validation — a broader emphasis on security as an ongoing state rather than an annual assessment.

Scope is still the biggest lever

The most effective PCI strategy has not changed: reduce what is in scope. Every system that stores, processes or transmits cardholder data, and every system connected to those, falls within the assessment.

Techniques that genuinely reduce scope include tokenisation, redirect or hosted payment pages so card data never reaches your servers, point-to-point encryption, and rigorous network segmentation. Segmentation must be validated by testing rather than asserted from a diagram — an assumed segmentation boundary that does not hold is a common and expensive assessment finding.

Testing obligations

PCI DSS is one of the few frameworks that explicitly requires penetration testing rather than merely implying it. Testing is expected at defined intervals and after significant change, covering both the network and application layers, from outside and inside the environment.

Where segmentation is used to reduce scope, that segmentation must itself be tested to confirm the boundary genuinely isolates the cardholder data environment. Vulnerability scanning requirements sit alongside this, including scans by an approved scanning vendor for external-facing systems.

Practical preparation

1. Confirm your merchant or service provider level and the validation route that applies, since obligations differ substantially.
2. Produce an accurate data flow diagram — where card data enters, where it travels, where it rests. Most scope surprises originate here.
3. Reduce scope aggressively before implementing controls; it is far cheaper than securing systems that need not be in scope.
4. Validate segmentation by testing it.
5. For any customised approach, prepare the documentation and targeted risk analysis early, and confirm your assessor is comfortable with it.
6. Assign named ownership for each requirement.
7. Build evidence collection into normal operations rather than assembling it before the assessment.

Related from TechBiz Security

• Compliance consulting
• Penetration testing
• Network security assessment

Sources & further reading

• PCI Security Standards Council — Document Library
• PCI Security Standards Council
• OWASP Web Security Testing Guide
• NIST SP 800-115 — Technical Guide to Information Security Testing

Frequently asked questions