PCI DSS 4.0 Requirements Checklist for 2026

PCI DSS 4.0.1 is the only active version. Its 12 core requirements are unchanged in structure, but all 51 formerly future-dated controls became mandatory on March 31, 2025. Payment page scripts, MFA coverage, and evidence are the 2026 gaps.

Nothing about PCI DSS changes in 2026. That's the point. The standard finished changing on March 31, 2025, and the grace period people were quietly counting on is gone. What's left is a version of the standard that asks for more proof, more often, from more of your environment. This checklist covers all 12 PCI DSS 4.0 requirements, the 15 controls that actually get merchants failed, and how to tell which self-assessment form applies to you. It's the readiness list we work from on PCI DSS compliance engagements.

In January 2026, researchers at Silent Push published details of a card skimming network that had been running since at least January 2022. The malicious JavaScript sat on live checkout pages, read card numbers as shoppers typed them, and sent the data to servers the attackers controlled. It also watched for the WordPress admin bar. If the site owner logged in, the script erased itself from the page before anyone could see it.

Four years. Six card networks. And the merchants running those stores had no reason to think anything was wrong. That's the attack the newest PCI requirements were written to catch, and it explains why two of them deal with nothing but the scripts loading on your payment page. It's also where assessments now come apart most often.

What changed in PCI DSS 4.0, and what didn't

The 12 requirements didn't really change. The controls underneath them did.

That distinction matters more than it sounds. If you compare the requirement headings in version 3.2.1 against version 4.0.1, they look almost identical. Install network security controls. Protect stored account data. Restrict access. A CFO glancing at both documents would reasonably conclude not much happened. Underneath those headings, though, the Council added 64 new or updated requirements, and 51 of them were future-dated, meaning they counted as best practice until March 31, 2025 and became fully assessable the day after.

Here's the sequence, because the version history is genuinely confusing.

Jeremy King, the Council's Regional VP for Europe, framed the two-year runway as time to prepare rather than time to wait. Plenty of merchants read it the second way. The v4.0.1 revision published in June 2024 didn't change the deadline, since it added no requirements and removed none. There's no version 4.1 or 5.0 announced, so anything you build now has a reasonable shelf life.

The 12 PCI DSS requirements at a glance

These haven't moved much since version 3.2.1, so here they are in one place, with what an assessor actually looks for.

Requirement 10 is worth a second look if you've never had to produce a year of logs on demand. Most environments retain them. Far fewer can retrieve a specific user's activity from nine months ago inside an assessment window, which is the thing being tested.

The 15 controls that actually fail assessments in 2026

Almost all of these came out of the future-dated batch, which is why they cluster. They're the newest controls in the standard, the least likely to already be running, and several of them ask for an inventory or a document nobody was keeping before 2025. They fall into four groups.

Payment page controls

These are the ones tied to the skimming problem, and for an e-commerce merchant they're usually the biggest lift, because nothing in the previous version of the standard asked for them. The same month the Silent Push research came out, Malwarebytes reported skimming activity hitting major payment networks, and The Hacker News covered the same long-running campaign. This is a live problem, not a theoretical one.

• 6.4.3 lands hardest. You need an inventory of every script that loads in the customer's browser on a payment page, a written business justification for each one, an authorization record, and a method for confirming the script hasn't been altered. Analytics tags count. Chat widgets count. That marketing pixel someone added in 2023 and forgot about counts.
• 11.6.1 asks for a change and tamper detection mechanism that alerts when HTTP headers or payment page content are modified without approval. Weekly at minimum, or whatever cadence your risk analysis defends.
• 6.4.2 quietly removed an option. Public-facing web applications used to be protectable through periodic manual review. Now you need an automated technical solution running continuously, which in practice means a web application firewall.

Identity controls

Requirement 8 saw the widest expansion, and it's where internal IT teams find the most work.

• 8.4.2 extends MFA to all non-console access into the cardholder data environment, from any location, for any role. Previously it applied to administrators. If you're still treating multi-factor authentication as an admin control, this is the gap.
• 8.3.6 raises minimum password length to 12 characters, with an exception at 8 for systems that genuinely can't support more.
• 8.6.1, 8.6.2, and 8.6.3 deal with application and system accounts. Interactive use has to be restricted and justified, passwords can't be hard-coded into scripts or config files, and they have to change on a frequency you can defend. The hard-coded credential rule is the one that breaks things, because those passwords are usually sitting in an automation script nobody has touched in years.

Detection controls

Detection moved from periodic to continuous, which changes the tooling conversation.

• 11.3.1.2 requires internal vulnerability scans to be authenticated. An unauthenticated scan sees what an outsider sees. An authenticated one logs in and sees what's actually installed, missing patches included, and the finding count typically jumps by a large multiple the first time a team runs one. This is also where the difference between vulnerability scanning and penetration testing stops being academic, since the standard requires both.
• 11.3.1.1 closes the habit of remediating only critical and high findings. Everything else needs to be addressed too, on a timeline your risk analysis sets. A working vulnerability management program is effectively assumed now.
• 10.4.1.1 requires automated log review. Someone reading a console once a week isn't sufficient.
• 5.4.1 adds automated anti-phishing mechanisms protecting personnel, not just training telling them to be careful.

Governance controls

The last group has no technology in it at all, and it's where organizations with good security lose points anyway.

• 12.5.2 requires documented, confirmed scope at least every 12 months and after any significant change. Service providers do it every 6 months under 12.5.2.1. Telling an assessor you descoped something without segmentation evidence behind it doesn't hold up.
• 12.3.1 is the targeted risk analysis, covered below.
• 12.10.7 requires incident response procedures for the specific scenario of finding card numbers somewhere they shouldn't be, like a support ticket or a shared drive.
• 3.5.1.2 narrowed what counts as making stored card data unreadable. Disk-level and partition-level encryption no longer qualifies on non-removable media. Full-disk encryption on a server protects you from someone walking out with the drive, and nothing else, which was always true but is now written down.

The SAQ A change that made compliance harder for some merchants

In January 2025 the Council updated SAQ A and removed requirements 6.4.3, 11.6.1, and 12.3.1 from it. That got reported widely as a simplification for small e-commerce merchants. It isn't quite that.

The requirements didn't disappear. They moved into the eligibility section of the form. To use SAQ A now, a merchant has to confirm that every element of the payment page delivered to the customer's browser comes only and directly from a compliant third-party provider, and that the site isn't susceptible to script-based attacks that could affect their e-commerce systems.

Read that second condition again. There's no defined test for it. You're attesting to it yourself.

Chris Camejo at TrustedSec described this as a hidden trap, and the math is why. A merchant who qualifies for SAQ A answers roughly 19 controls. A merchant whose assessor decides they don't qualify can land on the full merchant form, which runs to 234. That's not a marginal increase in effort. It's a different project with a different budget.

The dividing line is how your payment page is built.

• Full redirect to the processor's hosted page. The script criterion doesn't apply to you. Your page hands the customer off before any card data is entered.
• Embedded iframe from the processor. The criterion does apply, because your page is still delivering the wrapper the payment form sits inside, and anything compromising your page can reach around it.

So which one is your checkout? Plenty of teams aren't sure, and that uncertainty is the finding.

An iframe integration is the common case for anyone using a modern payment provider's embedded checkout, and it's frequently sold as the low-effort compliance path. It still is, mostly. But you either put the script controls in place yourself or you get written assurance from the provider that they've handled it, and "we use a well-known processor" is not that assurance.

Which merchant level and SAQ apply to you

Level determines how you validate. The SAQ form determines how much you validate. Both get set by transaction volume and by how card data moves through your systems, and your acquiring bank has the final say.

One wrinkle worth knowing. Visa folded Level 4 into Level 3 in April 2024, so a small Visa merchant and a small Mastercard merchant can technically sit at different levels for the same volume. It rarely changes the work. It does change the paperwork.

Then the form itself.

Choosing the wrong form is one of the more expensive mistakes in this area, because it usually surfaces late. Segmenting the network so fewer systems touch card data is the reliable way to move down this table, and network segmentation done properly is what makes a scope reduction defensible rather than aspirational. If PCI is one of several frameworks on your plate, it's worth mapping which compliance standards actually apply to your business before treating them as separate projects, because the control overlap is substantial.

The targeted risk analysis nobody documents

Several requirements in version 4.0.1 don't state a frequency. They say "periodically." That word is doing real work.

Requirement 12.3.1 says that wherever the standard leaves frequency open, you have to perform a targeted risk analysis to justify the interval you picked, and review it at least every 12 months. It applies to a defined set of controls, including 5.2.3.1, 7.2.5.1, 8.6.3, 10.4.2.1, 11.3.1.1, 11.6.1, and 12.10.4.1.

These are short documents. A page each is normal. Teams still miss them, because a targeted risk analysis isn't a security control and nothing breaks when it's absent. It just shows up as a finding.

Worth separating from 12.3.2, which is a different analysis used only when you're meeting a requirement through the customized approach rather than the stated one. Different form, different purpose, easy to confuse.

Evidence beats policy

The real shift in version 4.0 isn't any single control. It's that a policy describing what you do stopped being enough. A good portion of the new requirements in 4.0.1 are documentation and review obligations rather than technical ones.

An assessment in 2026 looks for artifacts covering the whole period, not a snapshot taken the week before. Quarterly scan reports with dates on them. Access review records with names and signatures. Change tickets. Alert history from the tamper detection tool showing it ran and produced output. A policy saying you review logs weekly is not evidence that you reviewed logs weekly. Could you produce 12 months of it by Friday?

Think of it the way an accountant thinks about receipts. Nobody doubts you bought the thing. Without the receipt it still doesn't count.

What that looks like by group.

Some merchants genuinely don't need help with this. A single-location retailer running one validated P2PE terminal with no e-commerce and no stored card data has a short SAQ and a small evidence pile, and paying someone to manage that is a waste of money. The picture changes once you have an online checkout, more than a handful of staff with system access, or card data touching anything you built yourself.

A 90-day readiness sequence

If you're starting from a partial position, the order matters more than the pace. Scope first, because everything downstream is sized by it.

1. Weeks 1 and 2. Scope and form selection. Map every system that stores, processes, or transmits card data, plus anything connected to it. Confirm your merchant level with your acquirer, then confirm the SAQ. If you use an embedded payment iframe, resolve the SAQ A eligibility question here rather than at assessment time.
2. Weeks 3 to 6. Payment page and identity. Build the script inventory. Stand up tamper detection. Extend MFA to every path into the cardholder data environment and clear out hard-coded credentials.
3. Weeks 7 to 10. Scanning and logging. Move internal scans to authenticated. Get automated log review running with the retention right, 12 months total and 3 immediately available. Fix what the first authenticated scan surfaces, and expect that number to be uncomfortable.
4. Weeks 11 to 13. Documentation and evidence. Write the targeted risk analyses. Confirm and date the scope document. Set up the collection process so next year's evidence accumulates on its own instead of being reconstructed.

That last step is the one that pays for itself. Merchants who build evidence collection into normal operations spend a fraction of the effort on their second assessment. Merchants who don't repeat the scramble annually.

Where this leaves you

Two things are worth carrying out of this. The first is that the deadline is behind you, not ahead of you, so any plan built around a future compliance date is pointing at one that already passed. The second is that the controls failing assessments in 2026 are mostly not hard technically. Script inventories, authenticated scans, and one-page risk analyses are ordinary work. They fail because nobody owns them between assessments.

If you're not sure whether your current SAQ is the right one, or whether your payment page would survive the eligibility question, that's a scoping problem before it's a security problem. Get the scope right and the rest of the checklist gets a lot shorter.

Speak to a PCI compliance expert and get your card data environment scoped properly.