PCI DSS 4.0.1 Readiness
From PCI DSS 3.2.1 to 4.0 and 4.0.1
PCI DSS 3.2.1, released in 2018, has been retired and replaced by PCI DSS 4.0, with 4.0.1 issued as a maintenance update that clarifies requirements and guidance. The 4.x line keeps the same 12 high‑level requirements but introduces new controls, new wording, and a stronger emphasis on continuous security and risk‑based flexibility.
Version 4.0.1 refines language around topics like multi‑factor authentication (MFA), phishing‑resistant authentication, and payment‑page script responsibilities so that entities and assessors interpret the expectations more consistently. Organizations already on 4.0 are expected to align with 4.0.1 as part of their normal update cycle.
High-level changes vs 3.2.1
Key thematic changes from 3.2.1 to 4.x include:
Outcome based and flexible:
Many requirements now define security “objectives,” allowing either a defined approach or a “customized approach” backed by evidence and risk analysis.
Continuous security focus:
There is stronger emphasis on ongoing monitoring, logging, testing, and detection, not just annual point‑in‑time checks.
Greater use of risk analysis:
New “Targeted Risk Analysis” (TRA) concepts determine the frequency of some activities and justify customized approaches.
Expanded client side and e commerce protection:
New requirements like 6.4.3 and 11.6.1 address scripts and change detection on payment pages to combat skimming and Magecart‑type attacks.
Timelines from PCI SSC and card brands gave entities until March 31, 2024 to move off 3.2.1, and additional time until March 31, 2025 for many new “future‑dated” requirements to become fully effective.
New focus: requirements 6.4.3 and 11.6.1
Requirements 6.4.3 and 11.6.1 are among the most visible 4.x changes because they directly target client‑side risks on payment pages.
Requirement 6.4.3 – script management on payment pages:
Entities must maintain an inventory of all scripts on payment pages, document the business justification for each script, and assure script integrity (e.g., via SRI, digital signatures, or other controls). This requirement aims to ensure that only authorized, validated scripts execute in the browser where card data is entered.
Requirement 11.6.1 – change detection on payment pages:
Entities must detect and alert on unauthorized changes to payment page scripts and security‑impacting HTTP headers, at a minimum on a weekly basis or at a frequency justified by a targeted risk analysis. The goal is to identify script injections or tampering quickly, reducing the dwell time of skimming attacks.
Imperva’s client‑side protection materials illustrate how automated script inventory, integrity checks, and change detection tools can help align with 6.4.3 and 11.6.1 without relying solely on manual reviews.
Targeted risk analysis (TRA) under 4.0.1
PCI DSS 4.x introduces formal “Targeted Risk Analysis” as a requirement in several places, especially where the standard allows flexibility in how often a control is performed. Under requirements such as 12.3.1 and 12.3.2, entities must perform TRAs to justify the frequency of activities like log reviews, scans, or security checks, instead of relying only on fixed intervals.
A TRA typically identifies the assets being protected, relevant threats, likelihood and impact factors, and a reasoned decision on control frequency and approach. TRAs must be documented, reviewed at least annually, and updated when there are significant changes to the environment or risk profile.
Practical readiness steps for PCI DSS 4.0.1 PCI DSS 4.0.1
To move from 3.2.1 (or a “minimal 4.0” posture) into full 4.0.1 alignment, organizations can follow a readiness sequence:
01
Gap analysis vs 4.0.1:
- Map current controls and assessment artifacts to the 4.0.1 requirements using the official Summary of Changes and internal checklists.
02
Prioritize new and future dated controls:
- Identify where requirements like 6.4.3, 11.6.1, TRA obligations, and enhanced authentication controls are not yet in place, and assign owners and timelines.
03
Implement script and change detection controls:
- Deploy processes and tools to inventory, authorize, validate, and monitor payment page scripts and headers, drawing on client‑side protection solutions where appropriate.
04
Define a TRA methodology:
- Standardize how targeted risk analyses are conducted, documented, reviewed, and linked to control frequencies and customized approaches.
05
Update policies, procedures, and evidence:
- Refresh documentation and day‑to‑day practices so that ROCs/SAQs, policies, and operational logs reflect 4.0.1 expectations rather than legacy 3.2.1 language.