PCI DSS 4.0 effort is driven by seven things: how much of your environment touches card data, how you must validate, how many third parties are involved, current controls, evidence automation, open remediation and your assessor. We give no prices, because the standard does not set them.
PCI DSS is for entities that store, process or transmit cardholder data or sensitive authentication data, or that could affect the security of the cardholder data environment. The PCI Security Standards Council says that includes merchants, processors, acquirers, issuers and service providers. It also says that whether an entity must comply, or validate compliance, is at the discretion of the organizations that manage compliance programs, which means payment brands and acquirers. Ask yours what applies to you before anything else.
Where does the standard stand today?
From PCI SSC's own publications: PCI DSS v4.0 was published in March 2022, and v4.0.1 followed in June 2024 as a limited revision. The Council says v4.0.1 corrected typographical and formatting errors and clarified intent, with no requirements added or deleted. v4.0 was retired on 31 December 2024, after which v4.0.1 is the only active version the Council supports.
Many new requirements were future-dated. In a Council Q&A, a qualified security assessor said that of 64 new requirements, 51 were future-dated and took effect on 31 March 2025. As of this post, that date has passed, so those requirements are part of what an assessor expects.
The seven drivers
1. Scope
Scope is the largest lever. Every system that stores, processes or transmits card data, plus systems connected to them, is in scope. A flat network puts everything in scope. Segmentation, tokenization and handing card entry to a payment provider can shrink it. The Council's Q&A notes a new requirement, 12.5.2, for an annual scope confirmation exercise, so scope work recurs.
2. How you validate
Merchants may complete a Self-Assessment Questionnaire in some cases, while others need a Report on Compliance from a qualified assessor. The effort differs sharply. Your acquirer or payment brand tells you which applies. Do not guess, and do not assume the shorter form from a competitor's example applies to you.
3. Third-party service providers
Each provider that touches your card environment adds work: contracts, responsibility matrices and evidence of their compliance. In the same Q&A, the assessor said many new requirements focus on roles and responsibilities, with a responsibility assignment matrix as one form of documentation. For e-commerce merchants completing SAQ A, the Q&A says quarterly vulnerability scans by an Approved Scanning Vendor are expected, and that this must be accounted for even when a provider runs the site for you.
4. Current control maturity
A team with centralized logging, patch management and access reviews already running spends effort on documenting. A team without them spends effort on building. This is why a gap assessment is the first step in nearly every sensible plan.
5. Evidence production
PCI assessments are evidence heavy. If you can export access lists, scan results and change records on demand, assessment time drops. If each item is a manual hunt, it grows. This is where automation pays back, though it is still your responsibility to show the controls operate.
6. Remediation backlog
Findings from the gap assessment become projects: network segmentation, multi-factor authentication for access into the card environment, script management on payment pages. v4.0.1 added applicability notes for payment page scripts, and a note that multi-factor authentication for non-administrative access into the card environment does not apply to accounts authenticated only with phishing-resistant factors. Reading those notes before you design can save a rebuild.
7. Assessor and calendar
Assessor availability, the length of the evidence period and your own release schedule set the timeline. Assessments are not instant. Ask potential assessors for their typical lead time and what they need from you, and do not rely on a generic estimate.
What does a vulnerability program have to do with it?
The software supply chain shows up in the vulnerability and patching requirements. The v4.0.1 summary says it reverted to v3.2.1 language that the 30 day patch window applies to critical vulnerabilities. Having a current inventory of components, and a record of how fast you fix serious findings, makes that easy to show. Safeguard's documentation lists PCI DSS among the frameworks where it maps automated tests from connected systems. That supports your evidence. It does not certify you, and only your assessor and the card brands decide that.
What to do
- Ask your acquirer or payment brand how you must validate, and write the answer down.
- Draw the card data flow and mark every system and provider in it.
- Look for scope reduction first: tokenization, a hosted payment page, segmentation.
- Commission a gap assessment against v4.0.1, including the future-dated requirements.
- List every provider with a contract date and the date of their last compliance evidence.
- Decide which evidence can be exported automatically, and build those exports first.
- Ask two or more assessors for lead time and evidence needs before you fix a date.
Quick check
Is PCI DSS 4.0 still the current version?
The active version is v4.0.1, which the Council says is the only version it supports after v4.0 was retired on 31 December 2024. Check the PCI SSC document library for anything newer.
How much will PCI DSS cost us?
It depends on scope, validation type, providers, current controls and evidence. Size those first. The standard itself sets no price.
Sources
- PCI Security Standards Council, PCI DSS
- PCI SSC Blog, Just Published: PCI DSS v4.0.1
- PCI SSC Blog, Now is the Time for Organizations to Adopt the Future-Dated Requirements of PCI DSS v4.x
- Safeguard docs: Compliance
Last reviewed: 18 October 2026.
