PCI-DSS v4.0: What Changed
and How to Prioritise
Remediation

PCI-DSS v4.0 is not just an incremental update to v3.2.1 — it represents a fundamental shift in how the standard approaches security. The move from prescriptive requirements to an outcomes-based customised approach, combined with 64 new or modified requirements, means organisations that simply "mapped over" their v3.2.1 programme to v4.0 have likely missed significant gaps.

This article focuses on the changes that matter most in practice — particularly for Indian payment processors, fintech companies, and merchants handling cardholder data — and how to sequence your remediation work.

The Structural Change in v4.0: Defined vs Customised Approach

PCI-DSS v4.0 introduces two compliance paths for each requirement:

The Defined Approach is essentially the same as v3.2.1 — you implement the specific controls as written in the standard. Most organisations will follow this path for the majority of requirements.

The Customised Approach allows an organisation to implement controls differently, provided they can demonstrate the stated security objective is being met. This requires significantly more documentation, assessor involvement, and technical justification. It's not a shortcut — it's actually more work. Most mid-sized organisations should stick with the Defined Approach for now.

The Most Significant Changes by Requirement Area

Requirement Area	Key Change in v4.0	Status
Req 3 — Account Data Protection	Disk-level encryption now explicitly insufficient for PAN protection — file-level or database-level encryption required for stored cardholder data	Immediate
Req 4 — Transmission Security	Inventory of all trusted keys and certificates now required; certificate management process mandated	Immediate
Req 5 — Anti-Malware	Anti-phishing mechanisms required; all payment pages must be reviewed for skimming threats periodically	Immediate
Req 6 — Secure Systems	Web application firewall (WAF) or automated technical solution now required for public-facing web applications; manual code review no longer sufficient without automated supplement	Immediate
Req 8 — Authentication	MFA required for ALL access into the CDE (not just remote access); password complexity requirements increased; shared/group accounts prohibited without compensating controls	Immediate
Req 10 — Logging	Automated mechanisms to detect and report failures of critical security controls; log review frequency must be defined based on risk	Immediate
Req 11 — Security Testing	Penetration testing must now explicitly test for business logic vulnerabilities; e-commerce skimming (Req 11.6) requires change detection mechanism on payment pages	Future deadline
Req 12 — Policies	Targeted risk analysis now required for requirements where frequency is left to the organisation to determine; documented and approved by management	Immediate

Three Changes That Catch Organisations Off Guard

1. MFA is now required for all CDE access

Under v3.2.1, MFA was required for remote access to the CDE. Under v4.0, MFA is required for all non-console administrative access and all user access into the CDE — whether from inside or outside the network. This is a significant operational change for organisations where internal staff accessed CDE systems with just a username and password. Implementing MFA across all CDE access points is typically a multi-month infrastructure project.

2. Payment page security (Req 11.6) — the skimming requirement

This is one of the most discussed new requirements. Organisations with e-commerce payment pages must implement a mechanism that detects and alerts on unauthorised modifications to the payment page's HTTP headers and page content. The intent is to detect Magecart-style card skimming attacks. Technically, this means either a content security policy implementation, an integrity monitoring tool for your payment page scripts, or a dedicated anti-skimming service. This requirement has a future deadline but should be in your 2025 roadmap.

3. The targeted risk analysis requirement

Several v4.0 requirements allow organisations to set their own frequency for certain activities — but now require a documented, management-approved risk analysis to justify whatever frequency is chosen. For example, if you choose to run log reviews weekly rather than daily, you need a documented risk analysis explaining why weekly is sufficient given your specific environment. This is new overhead that many organisations haven't built into their compliance processes.

How to Sequence Your Remediation

A Note on Scope Reduction

Before investing in remediation, it's worth revisiting your CDE scope. PCI-DSS v4.0 has updated scoping guidance that may allow some organisations to reduce their scope — particularly those that have moved to hosted payment pages or tokenisation solutions that significantly limit the cardholder data that touches their own infrastructure. A scoping review before your next QSA assessment can materially reduce both your remediation costs and ongoing compliance overhead.

"The most cost-effective PCI-DSS compliance strategy is usually scope reduction first, remediation second. If cardholder data doesn't flow through a system, that system doesn't need to comply. Every tokenisation project, every hosted payment page migration, reduces the compliance surface."