- PCI DSS 4.0.1 is the only active version for all 2026 assessments. All 64 new or updated requirements, including mandatory MFA across the full CDE, payment page integrity monitoring, and phishing-resistant controls, are now in force with no exceptions.
- Scope definition is the highest-leverage decision in the compliance program. Every system removed from CDE scope reduces the assessment surface, the evidence burden, and ongoing maintenance cost. Getting scope wrong in month one compounds through every phase that follows.
- Evidence collection is a year-round discipline. The organizations that fail PCI DSS assessments most often do not fail because controls are absent. They fail because controls that were operational in month two were not documented or maintained through month twelve.
- Targeted risk analysis (TRA) is one of the most misunderstood changes in version 4.0.1. It replaces fixed-frequency review schedules for eligible requirements, but only when the analysis is documented, risk-grounded, and management-approved. A generic template will not satisfy an assessor.
PCI DSS 3.2.1 was retired on March 31, 2024. Every future-dated requirement in version 4.0 became mandatory on March 31, 2025. As of 2026, all assessments run against PCI DSS 4.0.1 with no exceptions and no transition allowances remaining.
The question for GRC and security leads right now is not whether to comply. It is how to build a 12-month program that survives the assessment cycle, coordinates across engineering, IT, DevOps, and HR, and does not collapse into a last-minute evidence scramble every year.
This playbook gives you that program. A phased roadmap, a responsibility matrix, the high-risk requirements that trip up most assessments, and the evidence milestones that determine whether your next Report on Compliance & Self-Assessment Questionnaire holds up.
What PCI DSS 4.0 actually changed
PCI DSS 4.0 introduced 64 new or updated requirements compared to version 3.2.1. Thirteen became effective immediately when organizations moved to v4.0 assessments. The remaining 51 were future-dated, meaning they were best practices until March 31, 2025, and mandatory from that date forward.
The most operationally demanding changes fall into five areas. MFA is now required for all access to the cardholder data environment, covering internal network access, remote access, and non-console administrative access. Password minimums moved from 8 to 12 characters. Phishing-resistant controls became mandatory under Requirement 5.4.1. Payment page integrity monitoring is required under Requirement 11.6.1. And targeted risk analysis replaced fixed-frequency review schedules throughout the standard.
PCI DSS 4.0.1 was published in June 2024 as a minor clarification release. It corrected typographical errors and clarified requirement intent. It introduced no new requirements and deleted none. PCI DSS 4.0 was retired on December 31, 2024, making 4.0.1 the sole active version.
The philosophy shift is as important as any individual requirement. PCI DSS 3.2.1 was commonly treated as an annual compliance event. Version 4.0 explicitly rejects that model. The standard now frames security as a continuous, business-as-usual process, and assessors evaluate programs accordingly.
The 12-month compliance roadmap
PCI DSS 4.0.1 does not reward organizations that build compliance programs in the weeks before an assessment. It rewards organizations that run one continuously. The roadmap below breaks the 12-month cycle into six two-month phases, each with a defined focus, a cross-functional ownership structure, and evidence milestones that keep the program audit-ready throughout the year, not just at the finish line.
Months 1 and 2: Scope and gap assessment
The most expensive mistake in PCI compliance is misdefining scope. Every system that stores, processes, or transmits cardholder data falls within scope. So does every system that could affect the security of the cardholder data environment. Cloud components, third-party service providers, internal shared services, and development environments that connect to production all require examination.
In months one and two, the priority work is a full CDE boundary map, a gap assessment against all 64 new or updated requirements, a QSA engagement or internal assessment decision, and a vendor inventory with verification that every service provider handling cardholder data has a current PCI DSS compliance certificate or equivalent attestation.
Evidence to collect now: CDE network diagram, asset inventory, data flow diagrams showing where cardholder data enters, moves, and exits the environment, and vendor compliance documentation.
Months 3 and 4: Authentication and access control
Requirement 8 is where most organizations carry the heaviest implementation debt after the March 2025 deadline. MFA must cover all access into the CDE from internal networks, all remote access to the entity's network, and all non-console administrative access. The previous exemption for trusted internal users is gone.
Password policy changes are similarly broad. Passwords must be at least 12 characters long for all accounts. However, the 90-day password rotation requirement applies only when passwords are used as the sole authentication factor (single-factor authentication). Organizations using multi-factor authentication are not required to rotate passwords every 90 days unless a targeted risk analysis determines that more frequent changes are necessary. Service accounts and shared credentials also require documented formal management.
Evidence to collect now: MFA configuration screenshots across all CDE access paths, password policy documentation, service account inventory with ownership and review records, and access control system logs showing enforcement.
Months 5 and 6: Vulnerability management and application security
Requirement 6 covers software development security and payment page integrity. For e-commerce environments, Requirement 11.6.1 mandates change-and-tamper-detection mechanisms on all payment pages. This requirement targets Magecart-style web skimming attacks and requires organizations to detect unauthorized modifications to HTTP headers and payment page content.
Requirement 5.4.1 mandates automated mechanisms to detect and protect personnel against phishing. Email security platforms with anti-phishing capabilities satisfy this requirement when they include automated detection and response, documented coverage across all personnel with CDE access, and evidence of ongoing monitoring.
Penetration testing was already required annually under PCI DSS 3.2.1 Requirement 11.3, and that cadence carries forward in version 4.0.1. What changed is the scope and documentation expectations. The penetration test must now explicitly validate network segmentation controls if segmentation is used to reduce CDE scope, and findings must be tracked to remediation with evidence that remediation was verified. Version 4.0.1 also introduced the option to use a penetration testing methodology aligned with industry standards such as PTES or OWASP, giving organizations more flexibility in how the test is scoped and executed, provided the methodology is documented and approved by management.
Evidence to collect now: Payment page monitoring solution configuration, anti-phishing tool coverage reports, penetration test report with remediation tracking, and application vulnerability scan results.
Months 7 and 8: Cryptography and data protection
Requirement 3.5.1.2 removed disk-level or partition-level encryption as an acceptable method for protecting stored primary account numbers on fixed devices. Column-level, field-level, or file-level encryption is now required. Organizations that relied on full-disk encryption to satisfy stored data requirements need architectural changes in this phase.
Tokenization and PCI-validated point-to-point encryption remain effective scope-reduction tools. Reducing the number of systems within CDE scope is the highest-leverage compliance investment available. Every system removed from scope reduces the assessment surface, the evidence burden, and the ongoing maintenance cost.
Evidence to collect now: Encryption configuration documentation for all stored PAN, key management procedures, tokenization scope maps, and P2PE solution documentation if applicable.
Months 9 and 10: Monitoring, logging, and targeted risk analysis
Requirement 10 covers audit log management across the CDE. Logs must be generated for all CDE access, all administrative actions, and all security events. They must be protected from modification, retained for 12 months with at least three months immediately available, and reviewed daily. Automated log review with alert thresholds satisfies the daily review requirement when properly configured and documented.
Targeted risk analysis is one of the most operationally significant changes in version 4.0. For requirements that previously specified fixed frequencies, such as annual reviews, organizations may now determine their own review frequency through a formal risk analysis. The analysis must be documented, reviewed annually, and approved by management.
Organizations that do not complete targeted risk analyses for applicable requirements default to the maximum frequency in the standard. In practice, a targeted risk analysis is a documented decision with four components: the objective of the activity being reviewed, the threat and vulnerability landscape specific to the organization's environment, the controls in place to address that risk, and the resulting frequency determination with management sign-off.
Organizations that treat the TRA as a checkbox document, disconnected from genuine risk decisions, produce analyses that do not survive assessor scrutiny. The analysis needs to reflect the actual environment, not a generic template.
Evidence to collect now: Log review procedures with scheduling evidence, SIEM alert configuration documentation, targeted risk analysis reports for all applicable requirements, and management approval records.
Months 11 and 12: Pre-assessment readiness and evidence assembly
The final two months are not for discovering gaps. Every gap found in month 11 is a remediation timeline that may not close before the assessment. The pre-assessment phase is for validating that controls documented earlier in the year are still operating as configured, that evidence is complete and organized for assessor production, and that the internal team responsible for each requirement domain has reviewed their evidence package.
A mock assessment or internal readiness review conducted in month 10 or 11 produces a realistic picture of where the program stands. The findings from a readiness review are incomparably cheaper to address than findings from an assessor.
A structured readiness review covers three areas: control operating effectiveness, meaning are the controls actually running as configured; evidence completeness, meaning can every required control produce documentation covering the full assessment period; and scope accuracy, meaning does the CDE boundary map reflect the current environment after any system changes during the year.
Organizations that skip the scope accuracy check frequently discover during the formal assessment that a system added or changed mid-year brought new components into scope that were never assessed.
Evidence to collect now: Complete evidence library organized by requirement, control owner sign-off across all domains, remediation closure documentation for any open findings, and QSA or ISA pre-assessment review results.
Stakeholder responsibility matrix
PCI DSS 4.0 requires documented roles and responsibilities for each requirement. The table below shows the typical ownership pattern across functions. Organizations should adjust based on their structure.
Common migration risks by phase and how to address them
Evidence collection milestones
Evidence collection distributed across the year avoids the pre-assessment scramble that produces incomplete packages. The milestones below align to the phased roadmap.
How Scrut supports the full compliance cycle
The program described above requires continuous evidence collection, cross-functional coordination, and a monitoring infrastructure that does not depend on manual effort at assessment time. Most organizations that fail PCI DSS assessments do not fail because their controls do not exist. They fail because their evidence does not exist, or because controls that were operational in month two were not maintained through month twelve.
Scrut automates evidence collection from the infrastructure and tools organizations already use, keeps it organized by requirement throughout the year, and surfaces control drift before it compounds into an assessment finding. Targeted risk analysis workflows are structured and scheduled. Vendor compliance tracking is centralized. Control ownership is documented and assigned, not assumed.
The compliance teams that pass assessments consistently share one operational characteristic. They treat the 12 months between assessments as the compliance program, not the four weeks before the assessor arrives.
See how Scrut helps payment and e-commerce organizations maintain continuous PCI DSS 4.0 compliance. Request a demo.
PCI DSS 4.0.1 is a minor clarification release published in June 2024. It corrected typographical errors and clarified the intent of certain requirements. It introduced no new requirements and removed none. PCI DSS 4.0 was retired on December 31, 2024, making 4.0.1 the sole active version for all assessments from January 2025 onward. If your organization completed a 4.0 assessment before December 2024, your ROC or SAQ remains valid. All new assessments must reference 4.0.1.
Any organization that stores, processes, or transmits payment card data is subject to PCI DSS. Compliance level is determined by transaction volume, not by company size. Visa and Mastercard define four merchant levels: Level 1 merchants process over six million transactions annually and require a formal ROC conducted by a QSA. Levels 2, 3, and 4 merchants complete a SAQ, with the specific SAQ type depending on how card data is accepted and whether it is stored. Service providers have their own two-tier structure. Your acquiring bank is the authoritative source for your specific level requirement.
A targeted risk analysis (TRA) is a documented risk decision that replaces fixed-frequency review schedules for certain requirements. Where PCI DSS 3.2.1 specified that an activity must occur annually or quarterly, version 4.0.1 allows organizations to determine their own frequency through a formal risk analysis, provided the analysis is documented, reviewed annually, and approved by management. Requirements that allow a TRA-defined frequency include log review intervals, recurring security training, and several monitoring activities. Requirements that retain fixed frequencies, such as the annual penetration test and quarterly vulnerability scans, do not offer a TRA alternative. The PCI SSC's Customized Approach guidance and the standard itself identify which requirements are eligible.
Requirement 11.6.1 mandates change-and-tamper-detection mechanisms on payment pages to detect unauthorized modifications to HTTP headers and page content. It targets Magecart-style web skimming attacks that inject malicious scripts into checkout pages. The requirement applies to all entities that have payment pages delivered to cardholders' browsers, which includes most e-commerce merchants. It does not apply to merchants who use a fully outsourced payment solution where the payment page is entirely hosted and delivered by a PCI DSS-compliant third party and the merchant has no ability to modify it. Assessors evaluate whether the mechanism in place actually detects changes, not simply whether a monitoring tool is installed.
PCI DSS, SOC 2, and ISO 27001 share significant control overlap in areas including access control, logging and monitoring, incident response, vulnerability management, and risk assessment. Organizations subject to more than one framework can map controls across standards to reduce duplicate implementation and evidence collection work. For example, a documented risk assessment process that satisfies ISO 27001 Clause 6.1 and SOC 2 CC3.2 will address substantial portions of PCI DSS Requirement 12.3. The key difference is that PCI DSS is prescriptive and requirement-specific, while SOC 2 and ISO 27001 are principles-based. Achieving PCI DSS compliance does not automatically satisfy SOC 2 or ISO 27001, but a mature PCI program significantly reduces the gap. A compliance automation platform that maps evidence across frameworks eliminates most of the duplication.
%201.png){kind=icon}
.png)
