What Version of PCI DSS Applies in 2026?

PCI DSS v4.0.1 is the current and only active version of the Payment Card Industry Data Security Standard. The PCI Security Standards Council published it on June 11, 2024 as a limited revision and stated in its release announcement that “PCI DSS v4.0 will be retired on 31 December 2024.” Version 3.2.1 had already retired on March 31, 2024.

Version 4.0.1 added no new requirements and deleted none. It corrected formatting and typographical errors and clarified the focus and intent of language in Requirements 3, 6, 8, and 12 plus several appendices. The 12 core requirements are structurally unchanged, so an existing map of the 12 PCI DSS requirements still applies cleanly to v4.0.1.

What did change is the compliance clock. Every future-dated requirement introduced in v4.x became mandatory on March 31, 2025. Assessments conducted from that date forward score all of them as in-scope, with no remaining “best practice” carve-out and no grace period.

A successor is in early development but is not imminent. The council opened a request for comments on PCI DSS v4.0.1 that ran from June 3 to July 20, 2026, asking stakeholders where the standard should evolve to support “future technology and AI innovation” as it begins work on the next iteration. The council’s 2025 Annual Report, published in January 2026, records that a second RFC cycle for PCI DSS v5.0 completed in December 2025. No release date has been announced.

History suggests a long runway. v4.0 was published in March 2022 and v3.2.1 stayed active until March 2024 — a two-year overlap. Plan on v4.0.1 governing at least your next two annual assessment cycles.

Which PCI DSS Requirements Became Mandatory on March 31, 2025?

PCI DSS v4.0 introduced 64 new requirements. Thirteen took effect immediately when v3.2.1 retired. The council confirmed that 51 of the 64 were future-dated and became effective on March 31, 2025. That date has passed, so the answer for any 2026 assessment is straightforward: all of them.

The new requirements cluster into six themes — payment page and script integrity, authentication strength, automated logging and monitoring, vulnerability management rigor, scope discipline, and formalized risk analysis. About sixteen of them carry most of the assessment burden and most of the remediation cost.

Two entries reshape scope rather than merely tighten a control. Requirement 12.5.2 forces a documented annual re-confirmation of PCI DSS scope; Jeremy King, the council’s Regional Vice President for Europe, framed the point plainly when he said organizations “really do need to validate all parts of their PCI DSS scope every year.” Requirement 12.10.7 obliges you to open an incident response case whenever stored PAN turns up outside your defined cardholder data environment, which quietly makes data discovery a compliance capability rather than a nice-to-have.

What Do Requirements 6.4.3 and 11.6.1 Require for Payment Pages?

Requirements 6.4.3 and 11.6.1 are the most consequential additions in v4.x, and assessors consistently report them as the most commonly failed. They exist to stop e-skimming: Magecart-style attacks in which a single injected or hijacked JavaScript file silently harvests card data as the shopper types it, leaving the transaction and the server logs looking entirely normal.

What 6.4.3 requires

6.4.3 is an authorization and inventory control. For every script loaded into and executed in the consumer’s browser on a payment page, you must confirm the script is necessary, authorize it, assure its integrity, and keep an inventory with written business justification. The unit of compliance is the individual script, not the site.

What 11.6.1 requires

11.6.1 is a detection control. You need a change- and tamper-detection mechanism that alerts personnel to unauthorized modification of the HTTP headers and the content of the payment page as received by the consumer browser, evaluated at least once every seven days or at a frequency justified by a targeted risk analysis under 12.3.1.

The council published a dedicated information supplement, Payment Page Security and Preventing E-Skimming, on March 10, 2025. It directs organizations to ensure payment page scripts are “properly authorized, checked for integrity, and monitored for tampering,” and to manage security-impacting HTTP headers as well as scripts, “whether in the server environment or as rendered in the consumer’s browser.” The supplement notes that e-skimming breaches have increased significantly as e-commerce platforms have grown more complex and more dependent on external scripts.

Failures here are almost always governance failures, not technical ones. Marketing teams add tracking tags through a tag manager without routing the change past security, so the script inventory is stale within days. Teams also try to satisfy 11.6.1 with an existing vulnerability scanner, which inspects the server response rather than what the browser actually renders. Put script changes behind the same change-approval gate as code, and make the tag manager an in-scope system.

The threat data supports the priority. Verizon’s 2026 DBIR retail snapshot analyzed 997 incidents and 806 confirmed breaches in retail, where system intrusion accounted for 61% of breaches and basic web application attacks another 10%.

Did SAQ A Change, and Are You Still Eligible?

Yes, and the change caught a lot of merchants out. On January 30, 2025 the council announced updates to SAQ A that removed Requirements 6.4.3, 11.6.1, and the supporting targeted risk analysis under 12.3.1 from the questionnaire, citing stakeholder feedback about the complexity of implementing the new e-commerce requirements. The October 2024 version of SAQ A retired on March 31, 2025; the January 2025 version took effect the same day.

Removing the requirements did not remove the obligation. The council replaced them with an eligibility criterion: the merchant must confirm that their site is not susceptible to attacks from scripts that could affect their e-commerce systems. If you cannot make that confirmation, you are not eligible for SAQ A at all and must validate against SAQ A-EP, which carries a far larger requirement set.

A follow-up FAQ published on February 28, 2025 clarified how merchants can satisfy the criterion. There are two routes: implement the controls described in 6.4.3 and 11.6.1 yourself, or obtain written confirmation from a PCI DSS compliant third-party service provider that its embedded payment solution includes protections against script attacks when implemented according to the provider’s instructions. The FAQ also scoped the criterion tightly — it applies to merchants using embedded payment forms such as iframes, not to merchants who redirect the customer away from their site entirely.

Two practical consequences follow. First, “our site does not use scripts” is not an acceptable answer, because an attacker can inject a script at transaction time. Second, the responsibility to verify the provider’s implementation instructions were followed sits with the merchant, not the provider. Collect the provider’s Attestation of Compliance and their written statement, and keep evidence that you implemented their solution as documented.

What Are the New MFA and Password Requirements?

Authentication saw the widest expansion of scope in v4.x, and it is the change most likely to require budget rather than paperwork.

Requirement 8.4.2 now requires multi-factor authentication for all access into the cardholder data environment. Under v3.2.1, MFA was required for administrative access and for remote access originating outside the network. Under v4.x, a standard user account logging in from inside the corporate office to a CDE system needs MFA too. For most organizations this is the single largest engineering lift in the standard, because it drags identity providers, jump hosts, database access paths, and legacy applications into scope.

Requirement 8.5.1 sets the quality bar for the MFA system itself. It must not be susceptible to replay attacks, it cannot be bypassed by any user — including administrators — unless specifically documented and authorized for a limited time, and it must use at least two different factor types. Success on all factors is required before access is granted, so a system that grants partial access after the first factor fails the requirement.

Requirement 8.3.6 raised the minimum password length from 8 to 12 characters, containing both numeric and alphabetic characters, with 8 permitted only where a system cannot technically support 12.

Requirements 8.6.1 through 8.6.3 finally address service and application accounts. Interactive login by system accounts must be constrained and justified, passwords for those accounts must not be hard-coded in scripts, configuration files, or source code, and the password strength and change frequency for them is set by a targeted risk analysis rather than a fixed rule. In practice, 8.6.2 is where secrets management stops being optional.

Customized Approach vs. Defined Approach: Which Should You Use?

The customized approach is v4.x’s most-discussed innovation and its least-used one. It lets a mature organization meet the stated objective of a requirement using controls of its own design rather than the prescribed implementation, provided the assessor can validate that the objective is met.

The mechanics are demanding. For each requirement handled this way, the entity produces a controls matrix documenting the control, how it meets the objective, and how it will be tested, plus a targeted risk analysis under Requirement 12.3.2. The assessor then derives bespoke testing procedures rather than following the standard ones. Self-assessment questionnaires do not accommodate the customized approach, so in practice it is available only to entities producing a Report on Compliance with a QSA or ISA.

In June 2026 the council published new guidance on compensating controls and the customized approach precisely because the two were being confused. Compensating controls apply when an organization cannot meet a defined requirement because of a legitimate technical or business constraint. The customized approach is a proactive design choice by an entity that already has, in the council’s framing, “dedicated risk management functions and the internal capacity to design, implement, document, test, and maintain their own controls over time.” The guidance also reiterates that assessor independence is non-negotiable: an assessor cannot design a control and then evaluate it.

Targeted risk analyses are now mandatory paperwork

Requirement 12.3.1 requires a documented targeted risk analysis for each requirement that lets you choose how frequently a control runs — malware scan frequency (5.3.2.1), application and system account review frequency (7.2.5.1), periodic log reviews for non-CDE systems (10.7.3), the scope of lower-risk vulnerability remediation (11.3.1.1), payment page change-detection frequency (11.6.1), and incident response training frequency (12.10.4.1), among others. Each TRA must be reviewed at least every 12 months, and the council publishes a template. Requirement 12.3.2 is the separate TRA required for every customized-approach control. Missing or stale TRAs are a common and entirely avoidable finding.

Who Has to Comply, and How Do You Prove It?

PCI DSS applies to any entity that stores, processes, or transmits cardholder data, and to any entity that could affect the security of that data — which is why service providers, hosting companies, and script vendors get pulled in. The standard itself does not set validation levels; the individual payment brands do, based on annual transaction volume. Level 1 merchants generally validate through an annual Report on Compliance, while lower-volume merchants use the appropriate Self-Assessment Questionnaire. Thresholds differ by brand and by acquirer, so confirm yours in writing; our overview of the four PCI compliance levels walks through the typical bands.

Whatever your level, the deliverables are the same three artifacts: a completed ROC or SAQ, a signed Attestation of Compliance, and quarterly Attestations of Scan Compliance from an Approved Scanning Vendor where external scanning applies. The council warned in September 2025 that “the only documentation recognized for PCI DSS validation are the official form documents from the PCI SSC website,” and that any certificate claiming PCI DSS compliance is not authorized or validated by PCI SSC. If a vendor sends you a glossy compliance certificate instead of an AOC, ask again.

The reporting machinery was refreshed alongside the standard. The council released the ROC template for v4.0.1 on August 28, 2024, redesigned after feedback that the v4.0 version took too long to complete, demanded redundant information, and produced an unwieldy final report.

One more scoping note that trips up SaaS companies: if your platform touches a merchant’s payment page or receives cardholder data, your customers will ask for your AOC, and their SAQ A eligibility may depend on your answer. Budget for that before a deal stalls — see our breakdown of what PCI compliance actually costs.

What Does a PCI DSS Assessment Take in 2026?

With the future-dated requirements fully in force, a 2026 assessment is a full-standard assessment. The organizations that get through it cleanly treat it as a year-round evidence problem, not a Q4 documentation sprint. A workable sequence:

1. Re-confirm scope first (12.5.2). Produce a current data-flow diagram and system inventory, then run data discovery to catch stored PAN outside the CDE before an assessor does. This feeds both 12.5.2 and 12.10.7.
2. Fix the payment page controls (6.4.3, 11.6.1). These have the highest exploitation risk and the longest lead time, because they require a change-approval process that includes marketing and the tag manager.
3. Close the MFA gap (8.4.2, 8.5.1). Enumerate every access path into the CDE, including service accounts, database clients, and break-glass routes, then test that the MFA system meets 8.5.1 rather than assuming it does.
4. Move logging and scanning to automation (10.4.1.1, 11.3.1.2). Automated daily log review and authenticated internal scanning both need tooling and credential plumbing, not policy edits.
5. Write the targeted risk analyses (12.3.1, 12.3.2). Do these last, once the controls exist, so the analysis reflects reality. Diary the 12-month review date.
6. Collect evidence continuously. Assessors sample across the period, so point-in-time screenshots taken the week before fieldwork rarely survive testing.

Two developments are worth folding into your 2026 plan. In March 2025 the council published guidance on integrating artificial intelligence into PCI assessments, which allows AI to support document review and report drafting but is explicit that “AI is a tool, not an assessor” and that assessors must disclose AI involvement and obtain client consent. And in July 2026 the council released a mapping of PCI DSS v4.0.1 to NIST Cybersecurity Framework 2.0, useful for identifying where one control satisfies both frameworks — though the council is careful to note the two are complementary and “neither one is a replacement for the other.”

Finally, size the downside honestly. IBM’s 2026 Cost of a Data Breach Report puts the global average cost of a data breach at $4.99 million, a 12% year-over-year increase and a record high. Verizon’s 2026 DBIR, drawing on more than 31,000 incidents and over 22,000 confirmed breaches across 145 countries, found that vulnerability exploitation rose to 31% of initial access vectors and that third parties were involved in 48% of breaches, a 60% jump over the prior year. For a full program walkthrough, start with our complete guide to PCI DSS compliance.

Frequently asked questions

About this guide. By Compyl Research. Last updated August 11, 2026. This is general information, not legal advice — consult counsel for your specific obligations. Compyl is an AI-powered, agentic GRC platform built by CISOs.