The QSA flagged it on day two of the on-site assessment. A payment page was loading three JavaScript files from external CDNs that had no inventory entry, no integrity hash, and no authorization record. The security team had deployed a new checkout widget six weeks earlier. Nobody had updated the script inventory. Nobody had tested whether the CDN resources could be modified by a third party. Under PCI DSS 3.2.1, the finding would have triggered a remediation note. Under PCI DSS 4.0.1, it triggered a full Requirements 6.4.3 and 11.6.1 exception: unauthorized scripts on a payment page with no tamper-detection mechanism in place.
PCI DSS 4.0.1 became fully mandatory on March 31, 2025. The 47 new requirements it introduced are not incremental updates to an existing checklist. They represent a structural shift in how payment security compliance works. The standard moved from point-in-time audit validation to continuous operational monitoring, from prescriptive control implementation to objective-based customization, and from passive inventory to active real-time oversight of every asset touching cardholder data. Organizations that treated the March 2025 deadline as a documentation exercise are now operating with material compliance gaps.
The 12 core requirement groups remain the structural backbone of the standard. What changed is the evidence the QSA expects behind each one, the frequency of the controls, and the new requirements embedded within familiar categories. Four of those new requirements carry the highest operational impact for most organizations: 6.4.3 and 11.6.1 (payment page security), 12.3 (risk-based activity frequency), and 12.5 (formal scoping validation). Start there.
PCI DSS 4.0 compliance requirements apply to all entities storing, processing, or transmitting cardholder data. Effective March 31, 2025, PCI DSS 4.0.1 added 47 new requirements across 12 requirement groups. Key changes include real-time payment page script monitoring (Req. 6.4.3), tamper detection (Req. 11.6.1), targeted risk analysis (Req. 12.3), and mandatory scoping validation (Req. 12.5) [PCI DSS 4.0.1].
What Changed in PCI DSS 4.0.1
PCI DSS 4.0.1 was not a version bump. The Payment Card Industry Security Standards Council (PCI SSC) overhauled the standard’s underlying architecture, shifting from control prescriptions to security objectives. The result: more flexibility for mature security programs, more accountability for everyone, and a compliance evidence model that assumes continuous operation rather than periodic snapshots.
The Defined Approach vs. The Customized Approach
PCI DSS 4.0.1 formally codifies two compliance paths [PCI DSS 4.0.1 Section 4]. The defined approach mirrors the traditional method: implement specific controls exactly as written, document them, and present evidence to the QSA. The customized approach is new. Organizations can design their own controls provided they demonstrably meet each requirement’s stated security objective.
The customized approach is not a shortcut. It requires a controls matrix mapping each custom control to the security objective, a risk analysis supporting the design, and QSA validation that the custom control achieves the intent of the requirement. For organizations with mature security architectures that already exceed the defined controls, the customized approach reduces friction. For organizations still building foundational controls, the defined approach remains the right starting point.
From Point-in-Time to Continuous
The most consequential shift in PCI DSS 4.0.1 is the move from periodic assessment to continuous monitoring. Multiple requirements now mandate real-time or near-real-time controls where PCI DSS 3.2.1 accepted quarterly or annual evidence. Requirements 6.4.3 and 11.6.1 mandate active payment page monitoring, not after-the-fact review. Requirement 12.3 requires organizations to define and justify the frequency of every recurring security activity based on a targeted risk analysis. This means the evidence package for a PCI DSS 4.0.1 audit includes operational system logs and automated monitoring outputs, not just point-in-time reports.
Audit your current evidence inventory against the continuous monitoring requirements now. Pull your QSA’s Report on Compliance (ROC) template for version 4.0.1 and map every evidence item to its required collection frequency. Any requirement showing quarterly or annual evidence where 4.0.1 requires real-time or continuous monitoring is a gap. Prioritize Requirements 6.4.3, 11.6.1, and 12.3 for immediate remediation.
The 12 PCI DSS Requirements: What Each One Demands
The 12 requirement groups organize every PCI DSS control into functional categories. Each group has specific sub-requirements, and PCI DSS 4.0.1 added or modified controls within several of them. The table below maps each requirement to its core obligation and the primary evidence a QSA requests.
| Requirement | Category | Core Obligation | Key 4.0.1 Change |
|---|---|---|---|
| Req. 1 | Network Security Controls | Install and maintain network security controls | Expanded scope to all network security controls, not just firewalls |
| Req. 2 | Secure Configurations | Apply secure configurations to all system components | Vendor-supplied defaults explicitly prohibited; configuration inventory required |
| Req. 3 | Account Data Protection | Protect stored account data | New controls for disk-level encryption and hashing of PANs |
| Req. 4 | Data-in-Transit Encryption | Protect cardholder data with strong cryptography during transmission | TLS 1.2 minimum enforced; TLS 1.3 recommended |
| Req. 5 | Anti-Malware | Protect all systems against malware | Anti-phishing controls and removable media encryption added |
| Req. 6 | Secure Systems and Software | Develop and maintain secure systems and software | Req. 6.4.3 adds payment page script monitoring (new) |
| Req. 7 | Access Control | Restrict access to system components and cardholder data by business need to know | All access defined and documented; no default allow |
| Req. 8 | User Identification and Authentication | Identify users and authenticate access to system components | MFA required for all access into CDE; phishing-resistant MFA for non-console admin |
| Req. 9 | Physical Access Restrictions | Restrict physical access to cardholder data | POI device tampering inspection frequency formalized |
| Req. 10 | Logging and Monitoring | Log and monitor all access to system components and cardholder data | Automated audit log review required; manual review insufficient |
| Req. 11 | Security Testing | Test security of systems and networks regularly | Req. 11.6.1 adds payment page change detection (new) |
| Req. 12 | Organizational Policies | Support information security with organizational policies and programs | Req. 12.3 (risk analysis) and 12.5 (scoping) both new |
Four requirements from this table carry disproportionate compliance risk in 2026 because they are new, operationally demanding, and frequently misunderstood. They deserve their own examination.
The Four Critical New Requirements in PCI DSS 4.0.1
Requirements 6.4.3, 11.6.1, 12.3, and 12.5 represent the highest-impact changes in PCI DSS 4.0.1 for most organizations. Two address payment page security directly. One fundamentally changes how you document recurring security activities. One makes scope validation a formal, auditable process. All four became mandatory on March 31, 2025.
Requirement 6.4.3: Payment Page Script Inventory and Authorization
Requirement 6.4.3 mandates that all scripts loaded on payment pages have an authorized and documented method for confirming each script is authorized, an integrity attribute applied to confirm no unauthorized modification, and a written inventory of all scripts with business justification for each [PCI DSS 4.0.1 Req. 6.4.3].
This requirement exists because Magecart-style attacks inject malicious JavaScript into payment pages through compromised third-party CDNs, tag managers, and analytics libraries. A legitimate-looking script tag loading from a known CDN can exfiltrate card data in real time. Under PCI DSS 3.2.1, organizations had no explicit obligation to monitor or inventory payment page scripts. Under 4.0.1, the absence of a script inventory and integrity verification is itself a finding.
The implementation approach most QSAs accept: maintain a documented script inventory in a version-controlled configuration file, implement Subresource Integrity (SRI) hashes on all externally loaded scripts, and deploy a Content Security Policy (CSP) that restricts which domains can serve scripts to your payment pages. Review the inventory and regenerate integrity hashes after every release cycle. Any script without a documented business justification and integrity attribute fails this control.
Build your script inventory now. Load each payment page and inspect the source for every <script> tag. Document the URL, hosting domain, business purpose, and the team that owns the vendor relationship. Add SRI hashes using the sha384 algorithm for all externally hosted scripts. Implement a CSP header that includes a script-src directive restricting script execution to your approved domains. Add the inventory review to your release checklist so every deployment validates the inventory. Keep evidence of each review for QSA examination.
Requirement 11.6.1: Change and Tamper Detection for Payment Pages
Requirement 11.6.1 mandates a mechanism to detect unauthorized changes to payment pages, including changes to HTTP headers and the contents of received payment pages as received by the consumer browser [PCI DSS 4.0.1 Req. 11.6.1]. The mechanism must alert on unauthorized modifications and must run at minimum weekly, or more frequently when the risk analysis for Requirement 12.3 justifies a higher frequency.
Where 6.4.3 covers what scripts are authorized to run, 11.6.1 covers whether those scripts have been modified without authorization. The distinction matters operationally. A script that passes the 6.4.3 inventory check on Monday can be replaced with a malicious version by Tuesday if the CDN hosting it is compromised. Requirement 11.6.1 closes that window by mandating ongoing change detection, not just point-in-time inventory.
Implementation options range from commercial solutions (Reflectiz, Source Defense, Featurespace, and others built specifically for PCI payment page monitoring) to custom mechanisms using headless browsers and hash comparison. The QSA evaluates whether the mechanism detects changes to HTTP headers, content integrity of the payment page as rendered by the browser, and script source URLs. Screenshot-based monitoring does not satisfy this requirement. The mechanism must operate at the browser-rendered DOM level.
Evaluate commercial payment page monitoring platforms against the 11.6.1 requirements before building a custom solution. Most offer automated weekly (or more frequent) scans, alert workflows, and QSA-ready compliance reports. If you build internally, document the detection methodology explicitly: what elements are hashed, at what DOM rendering stage, with what alert threshold, and how alerts are reviewed and resolved. Keep alert logs as audit evidence. Weekly review records are a QSA deliverable.
Requirements 6.4.3 and 11.6.1 together create a continuous security obligation that extends beyond your internal systems to every third-party vendor whose code runs on your payment pages. A QSA finding under either requirement traces directly to third-party risk management failure, not just a technical control gap.
Requirement 12.3: Targeted Risk Analysis for Activity Frequency
Requirement 12.3 requires organizations to perform a targeted risk analysis for each PCI DSS requirement that specifies a frequency as defined by the organization, rather than a specific defined frequency [PCI DSS 4.0.1 Req. 12.3]. The risk analysis must identify the assets being protected, the threat actors and threat vectors, the likelihood and impact of a threat actor exploiting a vulnerability, and the resulting frequency determination.
This requirement fundamentally changes how you document recurring security activities. Under PCI DSS 3.2.1, an organization could set a “quarterly access review” cadence and document it in a policy. Under 4.0.1, requirements that say “periodically” or “at least once every X months” require a documented targeted risk analysis supporting the chosen frequency. If your access reviews happen quarterly, your risk analysis must demonstrate that quarterly frequency is sufficient given your threat model, your data sensitivity, and your operational environment.
The risk analysis for Requirement 12.3 is not a one-time document. It feeds the frequency of controls across multiple requirements, and the QSA will test whether your actual control frequency matches the risk analysis output. Organizations operating at lower frequencies than their own risk analysis supports are in a worse position than organizations with a well-documented quarterly cadence.
Map every PCI DSS 4.0.1 requirement in your scope that specifies a frequency “as defined by the entity.” For each one, build a targeted risk analysis document that covers: the asset protected, three to five plausible threat scenarios, a likelihood and impact rating for each, and the resulting frequency determination. Store these analyses in your compliance evidence repository. Update them annually or whenever the threat environment changes materially. Link each analysis to the corresponding control in your ROC evidence package.
Requirement 12.5: Formal Scoping Validation
Requirement 12.5 mandates that the scope of the PCI DSS assessment be formally documented and confirmed at least once every 12 months and upon significant changes to the in-scope environment [PCI DSS 4.0.1 Req. 12.5]. The validation must include all system components, personnel, processes, and third-party entities involved in the storage, processing, or transmission of cardholder data, as well as all connected systems that could impact the security of the CDE.
Scoping errors are among the most common findings in QSA assessments. Organizations routinely undercount their cardholder data environment because they rely on outdated network diagrams, miss recently deployed systems, or fail to trace data flows through all processing stages. Requirement 12.5 formalizes what many QSAs already expected informally: a documented, signed scoping validation exercise completed before the assessment begins.
The scoping exercise must trace the data flow for cardholder data from the point of capture through storage, processing, transmission, and destruction. Every system that touches the data flow, or is connected to a system that does, falls within scope. Organizations using point-to-point encryption (P2PE) solutions can reduce scope significantly, but the P2PE solution itself must be PCI-validated and the scoping reduction documented with the solution’s validation documentation.
Conduct your scoping validation as a formal exercise, not an ad hoc QSA conversation. Assign a scoping team that includes network engineering, application development, and compliance. Walk the full cardholder data flow on paper first, then validate against actual network traffic using packet capture or firewall log analysis. Document every system component in scope with its function in the data flow. Have the exercise reviewed by your QSA before the assessment begins. Significant changes (new payment processors, cloud migrations, new applications) trigger a re-scoping exercise regardless of the annual cycle.
Maintaining Continuous Compliance in 2026
PCI DSS 4.0.1 treats compliance as an operating state, not an audit milestone. The evidence model assumes that controls run continuously and that the QSA reviews operational records, not staged documentation. Organizations that build compliance programs around annual preparation cycles will produce the right documents for the wrong reasons, and QSAs are trained to distinguish between controls that actually run and controls that were activated for the assessment.
Quarterly ASV Scans Plus Real-Time Monitoring
Quarterly Approved Scanning Vendor (ASV) scans remain required under Requirement 11.3.2 [PCI DSS 4.0.1 Req. 11.3.2]. The ASV scan is not optional and cannot be replaced by internal scanning. Choose an ASV from the PCI SSC’s approved vendor list, schedule scans at least 90 days apart, and address failing findings before submitting passing scan results to your acquirer or payment brand.
The quarterly ASV scan satisfies the minimum compliance requirement. Operational security demands more. As explored in vulnerability scanning frequency analysis, the 89-day window between quarterly scans leaves critical external assets undetected against newly published CVEs. Organizations in the CDE should run weekly external scans and monthly internal credentialed scans in addition to the mandatory quarterly ASV scans. Document both the compliance minimum and the operational cadence in your vulnerability management policy. See also vulnerability scanning vs. penetration testing for the distinction between automated scanning and the manual penetration testing required under Requirement 11.4.
Penetration Testing Under Requirement 11.4
Requirement 11.4 mandates external and internal penetration testing at least annually and after any significant infrastructure or application upgrade [PCI DSS 4.0.1 Req. 11.4]. The penetration test must cover all CDE system components and connections from outside the CDE, all CDE system components and connections inside the CDE, and all segmentation controls if used to reduce scope [PCI DSS 4.0.1 Req. 11.4.5].
PCI DSS 4.0.1 does not require a QSA to perform the penetration test. An internal resource with penetration testing expertise may conduct it, provided the tester is organizationally independent of the environment being tested. Most organizations use external firms to avoid independence questions. The penetration test report must include the methodology used, the scope, the findings, and the remediation status of all critical and high findings. Unresolved critical findings at assessment time produce a Requirement 11.4 exception. For organizations also maintaining SOC 2, see SOC 2 penetration testing requirements for alignment opportunities between the two frameworks’ testing obligations.
Incident Response Readiness Under Requirement 12.10
Requirement 12.10 mandates an incident response plan that addresses the response to suspected or confirmed breaches of cardholder data [PCI DSS 4.0.1 Req. 12.10]. The plan must cover roles and responsibilities, communication and contact strategies with payment brands, legal, forensics firms, and law enforcement, specific incident response procedures for at least six defined incident types, business recovery and continuity procedures, and annual testing.
PCI DSS 4.0.1 added Requirement 12.10.7: specific response procedures for the detection of unauthorized cleartext PAN storage outside the CDE. If your security monitoring detects cardholder data in an unexpected location, the incident response plan must have a documented playbook for that specific scenario. Organizations implementing incident response plan programs should review their existing procedures against the 4.0.1-specific scenarios now. The continuous compliance monitoring infrastructure built for Requirements 6.4.3 and 11.6.1 feeds directly into this incident response pipeline.
Aligning with NIST CSF 2.0 for Operational Efficiency
Organizations operating PCI DSS alongside other frameworks can reduce compliance overhead by aligning controls architecturally. NIST CSF 2.0 implementation maps well to PCI DSS 4.0.1 because both frameworks now emphasize continuous monitoring, governance documentation, and supply chain risk management. The NIST CSF 2.0 Govern function aligns with PCI DSS Requirements 12.3 and 12.5. The Detect function aligns with Requirements 6.4.3, 11.6.1, and 10 (logging and monitoring). Building a single monitoring infrastructure that satisfies both frameworks eliminates duplicated evidence collection and reduces QSA preparation time.
Build a compliance calendar that maps every PCI DSS 4.0.1 recurring activity to its required frequency. Include: ASV scans (quarterly), internal vulnerability scans (monthly minimum), payment page script reviews (per release), payment page change detection reviews (weekly minimum), penetration testing (annual), risk analysis reviews (annual or upon significant change), scoping validation (annual), and incident response plan testing (annual). Assign an owner to each activity. Store evidence in a structured repository indexed by requirement number. When your QSA requests evidence, the package should already be assembled.
PCI DSS 4.0.1 ended the compliance model where organizations prepared for an annual assessment and then stood down. Requirements 6.4.3 and 11.6.1 require active monitoring infrastructure that runs year-round. Requirements 12.3 and 12.5 require documented analytical work that precedes the controls, not documentation assembled after the fact. Organizations that build for continuous operation now will produce assessment evidence as a byproduct of their security program. Organizations that build for point-in-time assessment will spend escalating resources staging compliance they do not actually maintain.
Frequently Asked Questions
What are the PCI DSS 4.0 compliance requirements that became mandatory in 2025?
PCI DSS 4.0.1’s 47 new requirements became fully enforceable on March 31, 2025. The highest-impact new requirements are 6.4.3 (payment page script inventory and integrity verification), 11.6.1 (payment page change and tamper detection), 12.3 (targeted risk analysis for activity frequency), and 12.5 (formal annual scoping validation). All entities storing, processing, or transmitting cardholder data must meet these requirements [PCI DSS 4.0.1].
Who does PCI DSS 4.0.1 apply to?
PCI DSS 4.0.1 applies to all entities that store, process, or transmit cardholder data, regardless of transaction volume or business size [PCI DSS 4.0.1 Scope]. This includes merchants, service providers, payment processors, and any third-party entity with access to cardholder data or systems connected to the cardholder data environment. Transaction volume determines the validation method (self-assessment questionnaire vs. QSA assessment), not whether the standard applies.
What is the customized approach in PCI DSS 4.0.1?
The customized approach allows organizations to design their own controls to meet each requirement’s security objective, rather than implementing the defined controls exactly as written [PCI DSS 4.0.1 Section 4]. It requires a controls matrix, a supporting risk analysis, and QSA validation. The customized approach suits mature security programs with existing controls that exceed the defined approach. Organizations still building foundational controls should use the defined approach.
What does Requirement 6.4.3 require for payment page scripts?
Requirement 6.4.3 mandates a written inventory of all scripts on payment pages with business justification for each, a method to confirm each script is authorized, and integrity attributes on all scripts to detect unauthorized modification [PCI DSS 4.0.1 Req. 6.4.3]. Scripts without an authorization record and integrity hash fail this control. The inventory must be reviewed and updated with every deployment cycle.
How does Requirement 11.6.1 differ from Requirement 6.4.3?
Requirement 6.4.3 addresses script authorization and integrity at a point in time. Requirement 11.6.1 addresses ongoing change detection: the mechanism must alert when payment page scripts or HTTP headers change without authorization, operating at minimum weekly [PCI DSS 4.0.1 Req. 11.6.1]. An authorized script that gets replaced by a malicious version satisfies 6.4.3 at inventory time but triggers a finding under 11.6.1 if the change is not detected.
What does PCI DSS 4.0.1 require for vulnerability scanning?
Requirement 11.3.2 mandates quarterly external vulnerability scans by an Approved Scanning Vendor (ASV) [PCI DSS 4.0.1 Req. 11.3.2]. Requirement 11.3.1 mandates quarterly internal vulnerability scans [PCI DSS 4.0.1 Req. 11.3.1]. Both requirements also mandate rescanning after significant environment changes. Quarterly represents the compliance minimum; operational security programs should run external scans weekly and internal scans monthly.
What is the PCI DSS 4.0.1 penetration testing requirement?
Requirement 11.4 mandates penetration testing of all CDE components at least annually and after significant changes [PCI DSS 4.0.1 Req. 11.4]. The test must cover external and internal network layers and application layers for web-facing applications. Requirement 11.4.5 separately requires testing of segmentation controls if used to reduce scope. Critical and high findings must be remediated before the assessment closes.
Get The Authority Brief
Weekly compliance intelligence for security leaders. Frameworks decoded. Audit strategies explained. Regulatory updates analyzed.
