Skip to content
All insights

PCI DSS 4.0 for Merchants: What Changed After March 2025

The future-dated requirements are now mandatory. A PCI fee on your statement is not the same as being compliant.

PCI DSS 4.0 for Merchants: What Changed After March 2025

PCI DSS 4.0's future-dated requirements became mandatory on 31 March 2025, according to the PCI Security Standards Council. If you accept cards, the document that applies is PCI DSS v4.0.1. A PCI fee on your merchant statement is not that assessment. It is a processor program, often a non-compliance penalty, and it can appear whether or not you completed a Self-Assessment Questionnaire (SAQ) or a Report on Compliance (ROC).

The PCI Security Standards Council (PCI SSC) writes the standard. Your acquirer and the card brands run the compliance program: they decide how you validate, which SAQ you are eligible for, and what happens if you do not. PCI SSC states that whether an entity must comply with or validate to a PCI standard is at the discretion of those programs.

The dates that actually moved

Three calendar dates matter. Mix them up and you will file against the wrong document.

PCI DSS v4.0 was published in March 2022, and v3.2.1 retired on 31 March 2024 (Lauren Holloway, PCI SSC, 26 March 2025). That is the version cutover, not the date every new control became mandatory.

The second date is 31 March 2025. Holloway said on 26 March 2025 that 64 new requirements were released in PCI DSS and 51 of them were future-dated. Those 51 sat in the standard as best practices from 2022 until 31 March 2025. After that date they are required and "must be fully considered during a PCI DSS assessment."

The third date is the limited revision. PCI SSC published PCI DSS v4.0.1 on 11 June 2024: corrections and clarifications, no added or deleted requirements, and no change to the 31 March 2025 effective date (Alicia Malone, PCI SSC, 11 June 2024). That same notice set 31 December 2024 as the retirement date for v4.0. From 2025 onward, v4.0.1 is the text to assess against.

If a vendor is still talking about "getting ready for 4.0," they are late. Confirm you are on v4.0.1, and confirm the former future-dated items that apply to your environment are actually in place.

What applies to you

You do not implement 51 extra controls because you are a coffee shop. You implement the requirements that match how you take cards and where account data lives. Scope follows the data. If card numbers never touch your systems, the questionnaire is short. If you store, process, or transmit account data, or if your website can affect payment-page security, more of the standard applies.

Two e-commerce controls get most of the attention. PCI SSC Requirements 6.4.3 and 11.6.1 were added to reduce e-skimming: payment-page scripts must be authorized, checked for integrity, and monitored for unauthorized changes. Holloway (26 March 2025) described them as targeting scripts that run in the customer's browser. If your checkout is an embedded iframe or a page you control, they are not optional reading.

Other v4 additions on the shorter merchant SAQs, per PCI SSC's 27 March 2024 briefing: ASV scans on SAQ A for redirect and iframe sites; multi-factor authentication into the cardholder data environment on SAQ A-EP and SAQ C; paper-record controls if you keep receipts that include account data; and documented roles, phishing training, and targeted risk analyses on A-EP and C. None of that is a processor product. It is the questionnaire your acquirer expects.

SAQ versus ROC

Validation is how you prove the work. The standard is the same. The report is not.

SAQ. Eligible merchants complete the questionnaire that matches their acceptance method, then sign an Attestation of Compliance (AOC). PCI SSC's merchant SAQs for v4 include A, A-EP, B, B-IP, C, C-VT, P2PE, D-Merchant, and SPoC. SAQ D for Service Providers is the only SAQ for service providers. If you are unsure which one you are eligible for, PCI SSC says to ask your acquirer or the payment brand, not a blog table.

  • SAQ A: card-not-present merchants who fully outsource account-data functions to PCI DSS validated third parties and keep only paper reports or receipts. Not for face-to-face. These merchants do not store, process, or transmit account data in electronic form on their systems (Holloway, 26 March 2025).
  • SAQ A-EP: e-commerce where the merchant website can affect payment-page security even if a third party hosts the card fields.
  • SAQ B, B-IP, P2PE, C, C-VT: terminals, imprint, listed point-to-point encryption, payment applications, or a virtual terminal, depending on how the device is connected.
  • SAQ D-Merchant: the full merchant questionnaire when no reduced SAQ fits.

ROC. The detailed assessment, typically with a Qualified Security Assessor (QSA). PCI SSC describes QSAs as independent security organizations it has qualified to perform PCI DSS assessments. High-volume merchants, merchants after an account-data compromise, and anyone the brand or acquirer places on that path use a ROC. An Internal Security Assessor (ISA) is a PCI SSC-trained person who can assess their own organization. ASVs run the external vulnerability scans.

PCI SSC does not publish one "you are Level 2" table that binds every brand. The card brands and your acquirer set volume thresholds and can tighten them after a breach. Ask the bank that holds your merchant ID, in writing, which document they want this year.

How a merchant validates PCI DSS 4.0.1
  1. 1
    Map how you take cards. Terminal, keyed, hosted checkout, iframe, or your own payment page. Scope follows the account data.
  2. 2
    Ask your acquirer the path. Which SAQ, or a ROC. PCI SSC writes the standard. The acquirer and card brands run the program.
  3. 3
    Use the current document. PCI DSS v4.0.1. After 31 March 2025, former future-dated requirements that apply to you are in scope.
  4. 4
    Separate the fee from the work. A PCI line on the statement is a processor program. The SAQ or ROC, plus scans and provider attestations, is the validation.

The PCI line on your statement is not the standard

Processors bill PCI compliance fees, PCI non-compliance fees, and sometimes both. Neither is an invoice from PCI SSC. Completing a portal quiz so the non-compliance fee drops off is not the same as meeting v4.0.1. It is often just proof you clicked through last year's form.

Nine signs you are overpaying flags a recurring PCI non-compliance charge as paperwork, not a security diagnosis. That is still true. What changed after March 2025 is the content of the paperwork. If you last filed against v3.2.1, or against v4.0 before the future-dated items were required, the portal that auto-renews your "compliant" badge may be asking the wrong questions.

Read the line the way you read any other monthly extra. How to read your merchant statement puts PCI with batch, statement, and gateway fees: small, easy to ignore, and part of effective rate. Illustrative arithmetic: a $40 monthly PCI non-compliance fee on $80,000 of card volume is 0.05 percent of that month. Paying it does not file the SAQ. Stopping it does not mean the 4.0.1 controls are in place. If you want to see whether that line is buried in a blended discount, run the statement through the analyzer once. The compliance work still sits with you and your acquirer.

Payment pages and SAQ A

SAQ A got tighter, then the Council adjusted it. PCI SSC added payment-page script controls and ASV scans for redirect and iframe sites, then Holloway (26 March 2025) said the Council removed Requirements 6.4.3, 11.6.1, and 12.3.1 from SAQ A and added an eligibility test: the merchant must confirm the site is not susceptible to script attacks that could affect e-commerce systems. Those three requirements remain in the standard. They left that one questionnaire, not PCI DSS.

Ask: are card numbers entered on a page you serve, or only inside a third-party iframe or a full redirect? Can third-party scripts on your page read or alter that form? Do you have confirmation from your PCI DSS validated provider that, used as instructed, their iframe or redirect includes techniques that protect the payment page? If you cannot answer those, you may not be SAQ A eligible even if you "don't touch cards." The checkout looks outsourced. The theme, analytics, and chat widgets often are not.

Keep the current SAQ, the signed AOC, ASV reports if they apply, and AOCs from every third-party service provider that can affect account data. "Our gateway is PCI" is not evidence. "Here is their AOC, dated, for v4.0.1, covering the services we actually use" is.

Do the four steps in the figure, in order. Do not start with a processor quote. Confirm v4.0.1 and the former future-dated items that apply to your channel. Confirm the SAQ or ROC with the acquirer. File on that document. Then look at the statement and ask whether the PCI fee is a program you enrolled in, a penalty for a lapsed SAQ, or a line nobody can map to work.

FAQ

What changed in PCI DSS 4.0 after March 31, 2025? The 51 future-dated requirements that PCI DSS had labeled best practices became mandatory on 31 March 2025. Assessments against PCI DSS v4.0.1 must now fully consider those controls.

Is a PCI fee on my merchant statement proof I am compliant? No. A PCI compliance or non-compliance line is a processor program. Compliance is the SAQ or ROC your acquirer requires, plus the evidence behind it.

What is the difference between an SAQ and a ROC? A Self-Assessment Questionnaire is the shorter path for eligible merchants. A Report on Compliance is the detailed assessment, usually with a Qualified Security Assessor. Your acquirer and the card brands decide which path you are on.

Do I still need PCI DSS if I use a hosted checkout or iframe? Yes. Outsourcing card entry can shrink scope, and many of those merchants use SAQ A, but you still have an obligation. Confirm current SAQ A eligibility with your acquirer, including how your site is protected from payment-page script attacks.

Which version of PCI DSS is in force in 2026? PCI DSS v4.0.1. That limited revision of v4.0 was published 11 June 2024 with no new or deleted requirements. PCI SSC retired v4.0 on 31 December 2024 and did not move the 31 March 2025 effective date for the former future-dated requirements.

Sources

Questions about how this applies to your business?

Talk it through

Your next move

Clarity looks good
on your business.

Analyze a statement