What are the most significant new PCI v4.0 requirements?

Requirement 6.4.3 is the one that changed the most for e-commerce: every script loaded on a payment page must be inventoried, authorised with a documented business justification, and integrity-checked. It targets Magecart-style skimming, where an attacker compromises a third-party script on the checkout page and exfiltrates card data as the customer types it. Requirement 8 expanded multi-factor authentication from remote access only to all access into the cardholder data environment, and raised the minimum password length from 7 characters to 12, or a passphrase of at least 15. Requirement 11.3.1.2 made internal vulnerability scans authenticated rather than unauthenticated. Requirement 5.4.1 added an explicit anti-phishing obligation that v3.2.1 did not carry. Requirement 10 now asks for automated mechanisms to detect and alert on security-relevant events. Requirement 12 introduced the customised approach and targeted risk analysis as a whole new way of meeting an objective, and strengthened third-party service provider management. Requirement 3 now requires sensitive authentication data to be removed after authorisation even for issuers, with enhanced disk-encryption and key-management requirements.

When did PCI DSS v4.0 become mandatory?

PCI DSS v4.0 was published in March 2022 and PCI DSS v3.2.1 retired in March 2024, which is the date v4.0 became the only standard you could be assessed against. The 51 requirements marked future-dated were optional during the transition and became mandatory on 31 March 2025. So 2026 is the first full assessment cycle in which every requirement in the standard, future-dated ones included, applies to every assessment. There is no transition relief left.

What is the PCI v4.0 customised approach?

It is one of the structural changes in v4.0 and it has no equivalent in v3.2.1. It lets an organisation meet a PCI DSS objective through controls other than the prescribed defined ones, provided a targeted risk analysis documents how the alternative achieves the same security outcome, and provided the assessor validates it. The trade is flexibility for documentation and assessor scrutiny: you write and maintain the risk analysis, and the assessor has to be satisfied by it. For most merchants the defined approach remains the shorter path, because the prescribed control is already implemented or is a configuration change, while the customised approach is a document you own and defend every year.

Does PCI v4.0 require more pen testing than v3.2.1?

The test set carries forward: external testing at least annually under Requirement 11.4.3, internal testing at least annually under 11.4.2, and segmentation validation at least every 12 months for merchants under 11.4.5, with six months for service providers under 11.4.6. What changed alongside it is scanning: Requirement 11.3.1.2 makes internal vulnerability scans authenticated, which means credentials have to be provisioned, managed and scoped for the scanner, and the results are longer because an authenticated scan sees more. We put no figure and no percentage on what that does to your bill, because pen testing is quoted per engagement and no firm publishes a rate to compare against. The direction is not arguable though: authenticated scanning is more work than unauthenticated scanning, and somebody bills for the difference.

Are SAQ A merchants affected by PCI v4.0?

Less than most, but the change is in eligibility rather than in control count. Effective 31 March 2025 the revised SAQ A removed requirements 6.4.3 and 11.6.1 from the questionnaire and added an eligibility criterion in their place: the merchant must confirm that its entire website is not susceptible to attacks from scripts that could affect its e-commerce system. That moves the question from what you answer to whether you qualify to answer it at all. Merchants sitting near the SAQ A and SAQ A-EP boundary should re-confirm eligibility against the criteria printed in the front of the current questionnaire rather than against a conclusion reached before March 2025, because landing on SAQ A-EP is roughly 139 controls against roughly 24, and that ratio is the honest measure of the gap.

How do I work out what v4.0 actually adds for my environment?

Take the future-dated requirement list and sort every entry into one of three piles against your own environment: already covered, configuration change, or new work. The third pile is your delta, and it is different for every merchant, which is exactly why no published figure could describe it. If you already enforce MFA on all CDE access, Requirement 8 costs you nothing. If your internal scanner already runs with credentials, Requirement 11.3.1.2 costs you nothing. If your payment page loads eleven third-party tags and nobody owns the list, Requirement 6.4.3 is a real project. Then price the third pile by getting quotes against it, and hand every firm the identical written scope so the answers are comparable.

Version comparison

PCI DSS v4.0 vs v3.2.1: what actually changed

The delta between the two versions is real, documented, and checkable against the standard itself. It is just not denominated in money. This page names every requirement v4.0 added or expanded, gives the published control counts either side of the version line, and tells you the one thing that decides whether any of it costs you anything: what you already had.

Updated July 2026

Why there is no dollar delta on this page

Subtracting a v3.2.1 price from a v4.0 price would need both prices to exist. Neither does. No QSA firm publishes a rate card, no acquirer publishes its PCI fee, no pen test firm publishes rates, and only one ASV publishes any price at all. A difference between two estimates is not a measurement, it is a guess with an extra step in it. No card brand, QSA, acquirer or pen test firm publishes a price list for PCI compliance work, and only one ASV publishes any price at all. So this site does not print cost bands for that work: a range for a price nobody discloses would be a guess, and labelling a guess an estimate does not make it true. What you get instead is what each line is priced against, so you can go and get a real number from the only people who have one, and a calculator that does the arithmetic using rates you supply from your own quotes. Where a real published price does exist, such as the compliance platform list prices on AWS Marketplace or SecurityMetrics' published small-business bundle, we quote it to the source and say when we checked it.

Future-dated requirements

Optional in the transition. Mandatory since 31 March 2025

v3.2.1 retired

Mar 2024

v4.0 has been the only standard since

Biggest change for e-commerce

Requirement 6.4.3, payment page scripts

The version calendar

PCI DSS v4.0 was published in March 2022, and the PCI SSC ran a two-year transition during which both v3.2.1 and v4.0 were accepted for assessments. PCI DSS v3.2.1 retired in March 2024. Fifty-one of the v4.0 requirements were marked future-dated during that transition, meaning best practice rather than obligation, and they became mandatory on 31 March 2025. So 2026 is the first full assessment cycle in which every requirement in the standard applies to every assessment, with no transition relief anywhere in it. v4.0.1 is a limited revision of v4.0 that corrects and clarifies rather than adding obligations.

If your last assessment ran under v3.2.1, which is to say your annual cycle last closed in Q1 2024 or earlier, your 2025 or 2026 renewal is the first one that meets the full v4.0 control set head-on. What follows is what that renewal contains that the old one did not.

What v4.0 added, requirement by requirement

Every row here is verifiable against the standard in the PCI SSC document library, which is the point: you can check the whole table without taking our word for any of it. There is no cost column, because the honest third column is not a price. It is the question that decides whether the change is free or a project for you specifically, and that question has a different answer in every organisation.

Requirement	What v4.0 changed	What decides whether it costs you anything
Requirement 6.4.3	Manage all scripts loaded on the payment page: inventory every one, authorise each with a documented justification, and assure the integrity of each. New in v4.0, and the most impactful change for e-commerce. It targets Magecart-style skimming, where an attacker compromises a third-party script on the checkout page.	How many third-party scripts your payment page loads, where they come from, and whether your CDN or existing tooling already gives you script visibility. A page with one script and a page with fifteen are not the same job.
Requirement 8	MFA required for all access into the cardholder data environment, not just remote access as under v3.2.1. Minimum password length raised from 7 characters to 12, or a passphrase of at least 15.	Whether you already enforce MFA everywhere into the CDE. If you do, this change costs nothing. If you do not, it is an identity project, and the standard has effectively decided your timeline.
Requirement 11.3.1.2	Internal vulnerability scans must now be authenticated. Unauthenticated internal scanning no longer satisfies the requirement.	Whether your scanner already runs with credentials. If it does, this is a documentation exercise. If it does not, it is credential provisioning, scan tuning, and a longer findings list to work through the first time.
Requirement 5.4.1	An explicit anti-phishing requirement: processes and automated mechanisms to detect and protect personnel against phishing attacks. New in v4.0.	Whether your mail security and awareness programme already cover it. Most organisations of any size have something here; the work is usually evidencing it rather than buying it.
Requirement 10	Automated mechanisms are required to detect and alert on security-relevant events. Log review frequency beyond the daily-review set is driven by targeted risk analysis.	Whether you have centralised logging with alerting today. Manual log review across an estate of any size is where this one bites, and the requirement is explicit that the mechanism is automated.
Requirement 12	The customised approach and targeted risk analysis are a major new theme with no v3.2.1 equivalent. Third-party service provider management is strengthened.	Whether you use the customised approach at all. It is optional. The defined approach still exists, and for most merchants it is the shorter path. Where the TPSP obligations bite is your vendor count.
Requirement 3	Sensitive authentication data must be removed after authorisation, and v4.0 extends that to issuers. Enhanced disk-encryption and key-management requirements.	Whether you store SAD anywhere, including in logs, and whether your disk encryption meets the requirement rather than merely existing. This is the requirement most likely to surface something nobody knew about.

Source: PCI DSS v4.0 and v4.0.1, and the PCI SSC's own Summary of Changes, in the PCI SSC document library. The future-dated set became mandatory on 31 March 2025.

The control counts, which run the other way

Here is the fact that survives contact with the actual documents, and it is not the one the version-upgrade coverage led you to expect. The SAQ control counts went down. v4.0 consolidated a great many sub-requirements that v3.2.1 listed separately, so the raw number of requirements in a questionnaire fell even as the work each one asks for rose.

Questionnaire	Controls under v3.2.1 (retired)	Controls under v4.0.1	Who it is for
SAQ D (Merchant)	329	~251	Merchants not qualifying for any other SAQ type
SAQ D (Service Provider)	347	~269	Service providers eligible to self-assess

Counts are the number of requirements in each SAQ document, read off the PCI SSC's own published questionnaires. Use them as a unit of assessment work rather than as a measure of effort: a consolidated requirement can ask for more than the two it replaced. That is precisely why a control count is a good way to size the gap between SAQ A and SAQ A-EP, and a bad way to compare v3.2.1 against v4.0.

The comparison that does hold across the version line is the one within v4.0.1: roughly 24 controls for SAQ A against roughly 139 for SAQ A-EP, and roughly 251 for SAQ D. Six times the controls for the same merchant, decided by how the checkout is built. That is the number worth engineering against, and it is on the SAQ types guide in full.

Requirement 6.4.3 in detail, because it is the genuinely new one

Most of what v4.0 added is an expansion of something v3.2.1 already asked for. Requirement 6.4.3 is not. It created an obligation that did not previously exist, and it created it for a specific and well-evidenced reason. Any merchant whose payment page can load third-party scripts, which includes tags deployed through a tag manager, marketing pixels, analytics, session replay and chat widgets, must do three things: keep a written inventory of every script on the payment page, authorise each one with a documented business or technical justification, and assure the integrity of each one on an ongoing basis.

The attack it targets is payment-page skimming of the Magecart type: an attacker compromises a third-party script that the checkout page already trusts, a marketing tag or a chat widget or a tracking pixel, and injects code that copies card data as the customer types it into the form. Nothing in the merchant's own codebase changes, which is why these attacks ran for months at a time before anyone noticed. Requirement 6.4.3 makes the detection of that structurally mandatory rather than a matter of whether somebody thought to look.

Read the requirement closely and note the word ongoing, because it is what rules out the cheapest answer. A one-off manual inventory in a spreadsheet demonstrates that you looked once. It does not assure integrity between the looks. Two implementation routes exist: subresource integrity hashes on every script tag with a documented change-approval workflow around them, which costs no licence fee and a real amount of process discipline; or a deployed script monitoring capability, which several vendors sell and several CDNs already include in tiers merchants are often paying for anyway. We name no prices for any of them here, because none of them publishes one that would mean anything for your page. What we can tell you is what they will price against when you ask, and it is the same thing either route is sized by: how many scripts your payment page loads, and where they come from.

Which makes the inventory itself the first move, and it is free. Count the third-party tags on your payment page. Several of them are there because nobody removed them after a campaign ended. Every one you delete is a script you never inventory, never justify and never monitor, in this compliance year or any future one, and deleting it costs nothing but the decision.

How to work out your own delta

Take the future-dated requirement list from the PCI SSC and walk it against your own environment, sorting every entry into one of three piles. Already covered, meaning you do this today and the work is evidencing it. Configuration change, meaning the capability is deployed and needs pointing at the CDE. New work, meaning you do not have this and will build or buy it. The third pile is your delta. It is a list of projects rather than a number, and it is the only version of this question with real inputs in it.

Then price the third pile the only way it can be priced: write it up as a scope, hand the identical document to two or three firms, and ask each of them the same three questions. How many assessor or engineer days does this fee assume? Is remediation and re-testing included, or billed separately? Who actually performs the work? A fixed-fee proposal that excludes remediation and a day-rate engagement that includes it are not comparable documents, and the gap between them is routinely wider than the gap between firms.

One shortcut is worth knowing about before you do any of that, because it can delete most of the delta rather than pricing it. If you are on SAQ A-EP because your own page collects the card details, moving to a fully hosted payment page removes Requirement 6.4.3 from your obligations entirely, because the payment page is no longer yours. It also moves you from roughly 139 controls to roughly 24, every year, not just this one. It is an engineering decision with a compliance consequence, the trade is real, and a redirect can move conversion. That last figure is one you already have and no assessor does, which makes it the one part of this decision you can genuinely calculate. Confirm eligibility against the criteria printed in the front of the current SAQ A rather than against the marketing name of an integration, and note that since 31 March 2025 SAQ A eligibility also requires confirming your site is not susceptible to script attacks.

Get the official v4.0 Summary of Changes

The PCI SSC publishes a Summary of Changes document detailing every change from v3.2.1 to v4.0, including the future-dated requirements and their effective dates, plus the SAQ documents with their eligibility criteria and control counts. Everything on this page is checkable against it.

PCI SSC document library →

Frequently asked

Nobody can tell you that honestly, including us, and the reason is structural rather than coy. Pricing the delta would need a published v3.2.1 price and a published v4.0 price to subtract, and neither exists: no QSA firm publishes a rate card or a day rate, no acquirer publishes its PCI fee, no pen test firm publishes rates, and only one ASV publishes any price at all. Every year-one uplift figure in circulation is therefore one estimate subtracted from another. What is documented, in the standard itself, is exactly what v4.0 added: Requirement 6.4.3 payment-page script management, Requirement 8 MFA for all access into the CDE rather than just remote access and a minimum password length of 12 characters, Requirement 11.3.1.2 authenticated internal vulnerability scanning, Requirement 5.4.1 anti-phishing, Requirement 10 automated detection and alerting on security-relevant events, and the Requirement 12 customised approach with targeted risk analysis. What each of those costs you depends entirely on what you already had. A shop already enforcing MFA everywhere pays nothing for the MFA change. A shop that is not enforcing it pays for a project. Walk the list against your own environment; that is the only version of this sum with real inputs in it.

2026 outlook

What changed for 2026, and what is actually published.

Level 3 PCI cost

The e-commerce tier, where 6.4.3 lands hardest.

SAQ A

The migration target that removes the 6.4.3 obligation.

PCI DSS requirements

All 12 requirements, with the v4.0 changes flagged.

Reduce PCI costs

Scope reduction, sized in controls rather than guesses.

ASV and pen test

Authenticated internal scanning is the new baseline.