Migration Guide
Migrate to PCI DSS 4.0.1 Without Disrupting Your Business
PCI DSS v4.0.1 represents the most significant update in the standard's history. With 64 previously future-dated requirements now fully mandatory since March 31, 2025, every organisation processing card payments needs a clear migration plan.
What Changed in PCI DSS v4.0.1
PCI DSS v4.0.1 is not simply a minor revision — it is a fundamental restructuring of how organisations approach payment security. The PCI Security Standards Council introduced several paradigm shifts that affect every entity in the payment ecosystem.
The Customised Approach
For the first time, PCI DSS v4.0.1 offers two compliance methodologies: the traditional Defined Approach (prescriptive controls) and the new Customised Approach. The customised approach allows organisations to meet the intent of a requirement using alternative controls, provided they document a targeted risk analysis demonstrating equivalent or superior security.
This is not a shortcut. The customised approach requires mature security processes, rigorous documentation, and more extensive assessor testing. It is best suited for organisations with dedicated security teams who can demonstrate their alternative controls meet the stated objective of each requirement. Your QSA must validate each customised control during assessment.
Targeted Risk Analysis
PCI DSS v4.0.1 introduces targeted risk analysis as a replacement for the blanket timeframes and thresholds of earlier versions. Instead of prescribing exact intervals (e.g., "review firewall rules every six months"), the standard now requires organisations to perform a documented risk analysis to determine the appropriate frequency for many activities.
This applies to requirements such as password change frequency (Req 8.3.9), malware scan frequency (Req 5.3.2.1), log review frequency (Req 10.4.1.1), and more. Each targeted risk analysis must be documented, approved by management, and reviewed at least annually. See the full list in the PCI DSS version change tracker.
Outcome-Based Requirements
Version 4.0.1 shifted many requirements from prescriptive "you must do X" language to outcome-based language that defines what must be achieved rather than how. This gives organisations flexibility but demands deeper understanding of security objectives. For example, Requirement 1 changed from "Install and maintain a firewall configuration" to "Install and maintain network security controls" — acknowledging that modern network security extends well beyond traditional firewalls.
Enhanced Authentication and Access Control
Authentication requirements were significantly strengthened. Multi-factor authentication (MFA) is now required for all access into the CDE (Req 8.4.2), not just remote access. Password requirements increased to a minimum of 12 characters (Req 8.3.6), and there are new requirements around managing system and service accounts (Req 8.6.1–8.6.3). Organisations that previously only enforced MFA for remote access must now extend it to every entry point into the cardholder data environment.
E-Commerce and Payment Page Security
Two of the most impactful new requirements target e-commerce specifically. Requirement 6.4.3 mandates a mechanism to manage all payment page scripts — including detecting unauthorised changes in real time. Requirement 11.6.1 requires a change-and-tamper-detection mechanism for payment pages. These directly address the growing threat of Magecart-style attacks that inject malicious JavaScript into payment forms. For more detail on e-commerce compliance, see our PCI for E-Commerce guide.
Critical Timeline
Understanding the PCI DSS v4.0.1 timeline is essential for planning your migration. Missing these dates means non-compliance, which can result in fines, increased transaction fees, and potential loss of payment processing privileges.
March 2022
PCI DSS v4.0 Released
The PCI Security Standards Council published PCI DSS v4.0, introducing the customised approach, targeted risk analysis, and 64 future-dated requirements. Organisations could begin transitioning immediately.
March 2024
PCI DSS v3.2.1 Retired
Version 3.2.1 was officially retired. All new assessments from this date forward must be conducted against PCI DSS v4.0 or later. Existing v3.2.1 ROCs and SAQs remained valid until their expiry.
June 2024
PCI DSS v4.0.1 Published
Version 4.0.1 was released as a clarification update to v4.0. It corrected errata, clarified testing procedures, and refined requirement language. No new requirements were added, but implementation guidance was significantly improved.
March 31, 2025
Full Enforcement — All Requirements Mandatory
All 64 previously future-dated requirements became fully mandatory. This is the single most critical deadline. Organisations that have not implemented these controls are now non-compliant. There is no further grace period.
For a visual representation of all PCI DSS milestones, use the interactive PCI DSS timeline planner.
Future-Dated Requirements Now Mandatory
The 64 future-dated requirements were the centrepiece of PCI DSS v4.0. Initially designated as "best practices" until March 31, 2025, they are now fully mandatory. Below are the most impactful ones that organisations must address immediately if they have not already.
Requirement 8.4.2 — MFA for All CDE Access
Multi-factor authentication must be implemented for all access into the cardholder data environment, not just remote or administrative access. This includes local console access, VPN connections, jump server sessions, and any method of accessing CDE systems. The MFA solution must use at least two of: something you know, something you have, or something you are. Independence of authentication factors is required — compromise of one factor must not compromise another.
Requirement 6.4.3 — Payment Page Script Management
All scripts loaded on payment pages must be authorised, inventoried, and monitored for integrity. You need an automated mechanism that alerts on or prevents unauthorised changes. This requirement was born from the epidemic of Magecart attacks where attackers inject malicious JavaScript into payment pages to skim card data. Implementation options include Content Security Policy (CSP) headers, Subresource Integrity (SRI) hashes, and real-time script monitoring services.
Requirement 10.4.1.1 — Automated Log Review
Organisations must use automated mechanisms to perform audit log reviews. Manual-only log review is no longer sufficient. This typically means deploying a SIEM (Security Information and Event Management) system or log analytics platform configured with detection rules for suspicious activity. The frequency of review must be determined by a targeted risk analysis.
Requirement 11.6.1 — Payment Page Tamper Detection
A change-and-tamper-detection mechanism must monitor HTTP headers and the content of payment pages as received by the consumer's browser. This works in tandem with Req 6.4.3 — together they create a defence-in-depth approach to payment page security. The mechanism must be capable of evaluating received pages and alerting on detected changes.
Requirement 5.3.2.1 — Targeted Risk Analysis for Malware Scans
The frequency of periodic malware scans must be defined through a targeted risk analysis rather than defaulting to a blanket interval. Organisations must consider the type of system, its exposure to threats, the malware landscape, and operational requirements. The analysis must be documented, approved by management, and reviewed at least annually.
Requirement 12.3.1 — Documented Targeted Risk Analyses
Where any requirement allows the entity to determine frequency through a targeted risk analysis, a formal documented analysis must exist. This is the "meta-requirement" that governs all other targeted risk analysis activities. The analysis must identify assets, threats, vulnerability likelihood, and resulting impact. See the full PCI DSS requirements for every instance where this applies.
For a complete list of all 64 future-dated requirements and their current enforcement status, visit the PCI DSS version change tracker.
Step-by-Step Migration Plan
Whether you are migrating from v3.2.1 or updating from v4.0 to v4.0.1, the following 8-step plan provides a structured path to full compliance. Each step builds on the previous one, so follow them in order.
Conduct a v4.0.1 Gap Analysis
Begin by mapping your current controls against every PCI DSS v4.0.1 requirement. Use the GRCTrack PCI Checklist to generate a personalised gap analysis based on your SAQ type. Focus especially on the 64 future-dated requirements and any modified requirements with new testing procedures. Document each gap with the specific sub-requirement reference, current state, and required state.
Inventory Future-Dated Requirements
Create a dedicated inventory of all 64 future-dated requirements. For each, record: requirement number, description, your current implementation status (not started, in progress, implemented, validated), the responsible owner, and target completion date. This inventory becomes your primary migration tracking document. The PCI DSS version change tracker can help you identify every affected requirement.
Evaluate the Customised Approach
Review each requirement where you have a gap and determine whether the customised approach may be appropriate. This is only recommended for organisations with mature security programmes and dedicated security teams. For each candidate requirement, draft a targeted risk analysis that documents: the control objective, your proposed alternative control, how it meets or exceeds the stated objective, the residual risk, and how effectiveness will be monitored. Discuss with your QSA early — they must validate each customised control.
Build a Remediation Roadmap
Prioritise gaps by risk impact and compliance criticality. High-priority items include any requirements that directly protect cardholder data (Requirements 3, 4), access controls (Requirements 7, 8), and monitoring (Requirement 10). Create a phased roadmap with realistic timelines. Assign clear ownership for each remediation task. Use the GRCTrack platform to track progress across your team.
Update Policies and Procedures
PCI DSS v4.0.1 changed the language and structure of many requirements. Your information security policies and operational procedures must reflect the current standard — not v3.2.1 language. Key policy updates include: security awareness training requirements (Req 12.6), incident response procedures (Req 12.10), change management processes (Req 6.5.1), and access control policies (Req 7.2). Review the implementation guides for each requirement to ensure policy alignment.
Implement Technical Controls
Deploy the technical controls identified in your gap analysis. The most common new implementations are: MFA for all CDE access (not just remote), payment page script monitoring and integrity checking, automated log review mechanisms (SIEM or equivalent), enhanced encryption key management, automated detection of rogue wireless access points, and updated vulnerability scanning with authenticated internal scans. Work with your IT and security teams to validate each control in a test environment before production deployment.
Train Staff
Security awareness training must be updated to cover v4.0.1 changes. All personnel with access to the CDE or security-relevant roles must receive training on: new authentication requirements (MFA everywhere), the customised approach (if used), their responsibilities under targeted risk analyses, phishing awareness (Req 5.4.1), and incident response procedures. Training must be conducted at hire and at least annually thereafter. Document completion records as evidence for your assessment.
Conduct Your v4.0.1 Assessment
Engage your QSA (for ROC assessments) or complete your Self-Assessment Questionnaire against the full v4.0.1 requirement set. Ensure all evidence is organised by requirement number and readily accessible. Your assessor will validate all controls, test configurations, interview relevant personnel, and review documentation. If any gaps remain, you will receive a findings report with remediation guidance. After successful assessment, file your Attestation of Compliance (AOC) with your acquirer.
Common Migration Mistakes
After working with hundreds of organisations through their v4.0.1 migration, these are the five most frequent mistakes we see. Avoiding them can save months of remediation effort and prevent assessment failures.
1. Ignoring Future-Dated Requirements Until the Deadline
Many organisations treated the March 31, 2025 deadline as a distant concern and did not begin implementing the 64 future-dated requirements until Q1 2025. By that point, the technical implementations alone — such as deploying MFA for all CDE access or implementing payment page script monitoring — could take 3–6 months. Organisations that started early had a significant advantage. If you have not yet implemented these controls, begin immediately and prioritise by risk impact.
2. Not Updating Policies and Procedures
Implementing technical controls without updating the corresponding policies and procedures is a guaranteed finding. Assessors verify that your documentation matches your implementation. If your policies still reference v3.2.1 language, outdated timeframes, or retired requirements, you will receive non-compliance findings even if your technical controls are sound. Budget dedicated time for policy review and update.
3. Underestimating the Customised Approach
The customised approach is attractive because it offers flexibility, but organisations frequently underestimate the documentation and testing burden. Each customised control requires a formal targeted risk analysis, detailed justification of why the alternative meets the objective, ongoing monitoring of effectiveness, and more rigorous assessor testing. Unless you have a mature security programme and a clear reason why the defined approach is unsuitable, the defined approach is typically faster and lower-risk.
4. Treating MFA as a Simple Checkbox
Requirement 8.4.2 mandates MFA for all access into the CDE, not just remote access. This includes local console access, database connections, application-layer access, and administrative interfaces. Many organisations deployed MFA for VPN and remote desktop but missed internal access paths. A thorough inventory of all CDE entry points is essential before deploying MFA, and the independence of authentication factors must be validated.
5. Neglecting Third-Party and Service Provider Dependencies
PCI DSS v4.0.1 strengthened requirements around third-party service provider management (Req 12.8, 12.9). If your service providers have not migrated to v4.0.1, their compliance gaps can become your compliance gaps. Review all third-party attestations of compliance and ensure they are assessed against v4.0.1 — not an older version of the standard.
Tools You'll Need
A successful v4.0.1 migration requires the right tools at each stage. GRCTrack provides an integrated platform that covers many of these needs, and our marketplace connects you with specialised service providers for the rest.
- PCI Compliance Checklist — Generate a personalised checklist for your SAQ type with all v4.0.1 requirements, including the 64 previously future-dated controls.
- Version Change Tracker — Filter changes by requirement, impact level, and type to quickly identify what affects your environment.
- Requirements Browser — Explore every v4.0.1 requirement with implementation guidance, evidence examples, and assessor expectations.
- Implementation Guides — Step-by-step technical guidance for each requirement with common pitfalls and best practices.
- Evidence Library — Sample evidence artefacts for every requirement to help you prepare for assessment.
- Timeline Planner — Visual timeline of all PCI DSS milestones and deadlines for your migration planning.
- SAQ Decision Engine — Determine your SAQ type to understand exactly which requirements apply to you.
- QSA Directory — Find a qualified security assessor experienced in v4.0.1 assessments to support your migration.
- CDE Scoping Tool — Define and document your cardholder data environment scope for accurate assessment preparation.
Start Your v4.0.1 Migration Today
GRCTrack maps every v4.0.1 requirement to actionable steps, tracks your progress, and connects you with QSAs who specialise in migration assessments.