What changed in PCI DSS v4.0.1 and what it means for your next assessment
A customer, acquirer or contract now asks for a current PCI DSS validation, and the first question is which version applies. PCI DSS v4.0.1 is the only active version. It was published on 11 June 2024 as a limited revision of v4.0, with no requirements added or deleted. PCI DSS v4.0 was retired on 31 December 2024, and v3.2.1 was retired on 31 March 2024. Any validation you submit now should be written against v4.0.1 and the SAQ or Report on Compliance templates that align with it.
Three parties own different parts of the result. Your organization owns its controls and the decisions about scope and validation method. An implementation partner or consultant can prepare systems, configuration baselines and evidence, but cannot sign off on them. Only a Qualified Security Assessor (for a ROC) or the completed SAQ with its Attestation of Compliance (for an SAQ) constitutes validation. Before you start, confirm with your acquirer or the requesting customer which validation type they accept and which version they expect, because some still reference older documents.
The v4.0.1 revision did not end the cycle. The PCI SSC ran a request for comments from 3 June to 20 July 2026 to begin the next iteration of the standard. As of October 2026, the SSC had announced no release date for a new version. Plan around v4.0.1 for your next assessment, and check the PCI SSC standards page and its blog for any published timeline before you commit a renewal date to a customer or contract.
Which PCI DSS versions are retired and what that means for an assessment
PCI DSS has three versions in the retirement picture, and only one is active today. Each card explains where an organization still on an older version stands, what it must move to, and who sets the deadline it has to meet.
PCI DSS v3.2.1 is retired
v3.2.1 retired on 31 March 2024, so it can no longer be used as the basis for a new assessment. An organization still reporting against it must move its assessment to v4.0.1 and the matching SAQ or Report on Compliance template. Confirm with your acquirer or payment brand which version and reporting date they expect on your next submission, because the Council does not set that deadline for you.
PCI DSS v4.0 is retired
v4.0 retired on 31 December 2024, after the v4.0.1 SAQs were published in October 2024 to run alongside it. Any assessment still built on v4.0 templates needs to be re-based on v4.0.1, including the SAQ content changes for SAQ A, A-EP, C and C-VT. Check whether your existing evidence, such as scan reports and policy sign-offs, references the v4.0 wording and needs updating for the new template.
PCI DSS v4.0.1 is the only active version
v4.0.1 is the only active version of the standard, published on 11 June 2024 as a limited revision with no added or deleted requirements. Every new validation, from the first assessment onward, should be prepared against v4.0.1 and its current SAQ or ROC template. Confirm the version your acquirer accepts before you start, so the scope and evidence work is not repeated.
Who sets the deadline
The PCI SSC maintains the standard but does not enforce compliance or impose penalties. The payment brands decide which entities must validate, by when, and what happens if they do not. Ask your acquirer or brand for a written statement of the version, reporting date and submission route. Keep that statement with your assessment file so an auditor or QSA can see the basis for the version you validated against.
What v4.0.1 changed and what it left alone
PCI DSS v4.0.1 was a limited revision, and it did not change the set of obligations. It was published on 11 June 2024 with no requirements added or deleted, and it kept the 31 March 2025 effective date that applied to v4.0. That means the 64 requirements introduced in v4.0, including the 51 future-dated ones that became mandatory on 31 March 2025, are still the same obligations. An organization that built its controls against v4.0 is not starting over. It is checking that its written controls, procedures and evidence match the corrected wording.
The changes are clarifications and corrections, so most existing evidence still applies. Two items deserve direct attention. The first is the patching timeframe in Requirement 6.3.3: v4.0.1 limits the one-month installation window to patches for critical vulnerabilities, and other patches fall within a timeframe the entity sets. Confirm that your patch policy, risk ranking method and ticket records reflect that split, and that the timeframe you chose is documented and followed. The second is the keyed hashing requirement for protecting stored PAN in Requirement 3.5.1.1, which v4.0.1 clarified. If your environment uses hashes of the PAN, check the key management and key separation records behind them, not only the hashing algorithm.
Do not assume that v4.0 evidence matches the v4.0.1 text. Pull the current standard and map each requirement that your controls touch to the written policy, the configuration and the recorded output. Ask your QSA or internal assessor to confirm which clarifications affect your validation, and record that review in your readiness file. Where an assessor or payment brand has a specific interpretation, get it in writing before the next assessment cycle.
Two clarifications that change how controls are tested
Two clarifications in PCI DSS v4.0.1 change what an assessor expects to see for patching and for protecting stored PAN. Both depend on decisions your organization documents and on evidence that the chosen approach works, so confirm each interpretation with your QSA or acquirer before you build controls around it.
Patch timeframe for critical vulnerabilities
Requirement 6.3.3 reverted in v4.0.1 so that the one-month installation window applies only to patches for critical vulnerabilities. Other patches fall under a timeframe your entity sets. Assessors will expect a documented, risk-based method for ranking vulnerabilities and evidence that the ranking drives actual patch dates. Ask your QSA which ranking sources they accept before you finalize the method.
Document the vulnerability ranking method
The entity owns the ranking method, so the method must be written down and followed. A useful record names the scoring sources, the rules that promote a finding to a shorter window, and who approves exceptions. Show at least one cycle in which lower-ranked patches were installed inside the timeframe you set. A method that exists only on paper is the most common reason this area draws questions.
Keyed hashes for stored PAN
Requirement 3.5.1.1 requires any hash used to protect PAN to be a keyed cryptographic hash of the entire PAN, with the keys managed under Requirements 3.6 and 3.7. This became mandatory on 31 March 2025. Plain, unkeyed hashes of PAN do not meet the requirement, so check every location where a hash of card data is stored, including logs, backups and analytics tables.
Scope questions for hashed PAN
Hashing PAN does not automatically remove the hashed data from scope, and the answer depends on how the hash is produced and stored. Review the scope guidance before deciding that a system holding only hashes is outside the cardholder data environment. Confirm your reasoning with your QSA, since the answer shapes which systems you must assess.
Correlating hashed and truncated PAN
Keyed hashes and truncated PAN can, in combination, allow records to be matched or PAN to be reconstructed in some designs. Map every process that compares, joins or reports on card data across hashes and truncated values. Where correlation is needed for fraud or reconciliation, document the control that limits it and ask your QSA to review that design.
Confirm both with your assessor
Neither clarification is a substitute for an assessor's reading of your environment. Send your patch ranking method and your hashing design to your QSA or acquirer before the assessment window opens, and record their response. This turns an interpretation into agreed evidence and avoids rework late in the cycle.
How the v4.0.1 SAQ updates affect each questionnaire
SAQ A is used by e-commerce merchants that have fully outsourced their payment pages. For v4.0.1, the SAQ A text was aligned with the revised standard, its eligibility criteria were clarified, and one requirement was added. It also received updated completion guidance. Because the requirement added here is the change most likely to affect you, read the SAQ A text itself rather than relying on a summary of the change.
- Eligibility wording: Confirm that every payment page element is still delivered by a PCI DSS compliant provider through a redirect or embedded frame, and that you do not receive, process or store account data on your own systems.
- Added requirement: Find the new requirement in the v4.0.1 SAQ A and identify which system, page or vendor it applies to in your environment.
- Completion guidance: Compare the updated guidance with the version you used last year so your answers reflect the current wording.
- Evidence you already keep: Review your provider's responsibility documentation and AOC, your page-change records and any scan reports.
Check whether your checkout flow still matches the eligibility criteria before you begin. The separate SAQ A guide for e-commerce merchants covers these rules in more detail.
SAQ A-EP is for e-commerce merchants whose payment page is partly controlled by the merchant, for example when the site hosts the page but a third party processes payment. The v4.0.1 revision clarified the eligibility criteria and updated the completion guidance. Because this questionnaire covers more of your own web environment than SAQ A, the clarified criteria deserve careful review against how your site actually handles the payment page.
- Eligibility wording: Re-read the criteria to confirm that your website can still affect the security of the payment transaction, and that you have classified it correctly.
- Completion guidance: Note the updated guidance for this questionnaire and check which answers it changes for your environment.
- Web application controls: Map your current controls for payment page integrity and script management to the questionnaire's wording, and confirm who owns each one.
- Evidence you already keep: Gather change records for the website, scan results, and any records showing who approved script or page changes.
Confirm your eligibility with your acquirer if the boundary between your site and the payment provider is unclear.
SAQ C-VT is used by merchants that enter card data into a virtual terminal hosted by a third party, typically from a standard browser, with no card data stored on their own systems. The v4.0.1 SAQ clarified its eligibility criteria. The change does not alter the basic model of the questionnaire, but it does tighten what counts as a qualifying virtual terminal use case, so you should test your current setup against the text.
- Eligibility wording: Verify that card entry happens only in the hosted virtual terminal and that no card data reaches your internal systems, paper records or local files.
- Channel fit: Confirm that all your card-not-present payments come through the same hosted terminal. Mail order or phone channels with other tools may need a different SAQ.
- Terminal access: Review which staff can use the terminal, how they log in, and whether multi-factor authentication applies in your environment.
- Evidence you already keep: Keep the provider's AOC, your user access list for the terminal, and your records of quarterly scans if they apply to you.
If any step in your payment process touches card data outside the hosted terminal, the criteria may no longer fit.
SAQ C covers merchants that process card data through payment application systems connected to the internet, such as a point-of-sale system or payment terminal with a browser or network link. For v4.0.1, one requirement was removed from this questionnaire. A removed requirement can reduce work, but it does not remove the underlying control from your environment, and many organizations keep the same evidence for good practice.
- Removed requirement: Identify which requirement was taken out of SAQ C and check whether your current evidence was built only to answer it.
- Retained controls: Keep controls that still apply under other requirements, even if they no longer appear in this questionnaire.
- Payment application review: Confirm that the payment application and its connections match the configuration you described last year.
- Evidence you already keep: Retain network diagrams, system inventories and the vendor's implementation documentation.
Review the SAQ C text with your acquirer before you assume a requirement no longer applies to your channel.
What the 2026 request for comments means for your plan
The sequence separates what the PCI SSC has proposed from what your assessment requires today, so you can prepare evidence and plan changes without treating a draft as a new version. Each step ends with a written output that your compliance lead can hand to the QSA or acquirer.
Monitor PCI SSC publications for the next revision
The compliance lead watches the PCI SSC website and blog for announcements about the next iteration of the standard, including the request for comments that ran from 3 June to 20 July 2026. Record each publication with its date, title and the version it concerns. As of October 2026, the SSC had announced no release date for a new version, so the output is a dated log that shows no new version is in force. Confirm the log is reviewed on a fixed schedule and that someone owns it.
Read the request for comments and any draft
Read the request for comments and any draft material the SSC publishes, and note which requirements, testing procedures or guidance could change. A request for comments is a consultation, not a new version of the standard, and it does not change what assessors test today. The output is a short summary that separates proposed changes from confirmed ones, with the source for each item. Share the summary with the security lead and the QSA so the team reads the same text.
Map proposed changes to existing controls
For each proposed change, identify which current controls, policies, configurations and evidence it would touch, including the v4.0.1 items already in force such as the keyed hashing requirement and the patching timeframe for critical vulnerabilities. Owners of each control confirm the impact in writing. The output is an impact register listing affected requirements, the evidence that would need to change, and the owner of each item. Items with no impact are recorded too, so the register shows the review was complete.
Plan changes with the QSA or acquirer
Take the impact register to your QSA, or to your acquirer if the validation path runs through them, and agree which changes are worth preparing for now and which should wait for a published version. Your team owns the decisions about its own controls, and the QSA gives an independent view of how the assessor would test them. The output is a written plan with owners, dependencies and the point at which work would be triggered, such as publication of a final version. Ask the QSA to confirm in writing what it expects you to do before the new version is in force.
Validate against the version in force at assessment
When an assessment starts, confirm which version of the standard is active and validate against that version only. As of the date this page was written, that is PCI DSS v4.0.1, since v4.0 retired on 31 December 2024 and v3.2.1 retired on 31 March 2024. The output is an assessment record that names the version in use, the SAQ or ROC template that matches it, and the evidence checked against each requirement. Confirm the version again at the start of every assessment cycle, because a new version may be published between cycles.
Where your current assessment stands if you validated against v4.0
Organizations that validated against v4.0 or worked from v3.2.1 should first confirm which version their acquirer or payment brand currently requires, because the PCI SSC does not decide which entities must validate or on what timeline. PCI DSS v4.0 was retired on 31 December 2024, so v4.0.1 is the only active version, and any assessment dated after that point should be run against it. v3.2.1 was retired on 31 March 2024. Ask your QSA or acquirer to confirm in writing the version, the validation type and the date by which your next attestation must reflect v4.0.1.
Next, review your existing Report on Compliance or Self-Assessment Questionnaire against the v4.0.1 wording, paying particular attention to the keyed hashing clarification for PAN protection under Requirement 3.5.1.1 and the reverted timeframe in Requirement 6.3.3, which now applies the one-month installation window to critical vulnerability patches only. Document each gap, its owner and its remediation date. Requirements that became mandatory on 31 March 2025 cannot be backdated, so a gap found now is reported as a current gap, not as a past lapse. Keep a dated record of what you changed and when, since assessors will ask for it.
Finally, review every requirement you marked not applicable, and every requirement you meet through the customized approach. The customized approach and compensating controls are separate paths: a compensating control is a documented alternative used when a requirement cannot be met as written, while a customized approach meets the stated objective in a different way and requires its own targeted risk analysis and evidence. Confirm with your QSA which of your current entries fit each path, and whether your acquirer accepts them. Changes announced in the next iteration of the standard will not change these obligations until a new version is published and its own timeline applies.
What to confirm now against v4.0.1
PCI DSS v4.0.1 is the only active version, so the checks below start with the basics: which version and deadline apply to you, and which template you will submit. The remaining cards cover the two clarifications most likely to affect existing controls, then the evidence an assessor will ask to see. DeployOpen prepares systems and evidence, while your organization owns the controls and the QSA or SAQ process validates them.
Confirm the active version and deadline
Ask your acquirer or payment brand which PCI DSS version and reporting deadline apply to your next validation cycle, and get the answer in writing. PCI DSS v4.0.1 is the only active version, since v4.0 was retired on 31 December 2024, so any document still citing v4.0 needs updating. Record the date you were given and who gave it. The written answer from your acquirer is the document that governs your deadline, not this page.
Map patching policy to v4.0.1
Compare your written patching policy with the v4.0.1 wording for Requirement 6.3.3. The 30-day installation timeframe now applies to critical vulnerability patches, and you set the timeframe for other patches. Check that your policy names the timeframe you chose for non-critical patches, states who approved it, and matches what your change records show. An assessor will test the policy against actual patch dates, so the timeframe you set must be one your team actually meets.
Check keyed hashing of PAN
If you hash the primary account number anywhere, confirm the hash is a keyed cryptographic hash of the full PAN as Requirement 3.5.1.1 requires, and that it has been mandatory since 31 March 2025. Pull the key management records under Requirements 3.6 and 3.7 for each hashing key, including who generated it, where it is stored and when it was last rotated. Ask your QSA or SAQ reviewer to confirm how the hash is used before you rely on it for scope decisions. A hash without matching key records is a gap an assessor will report.
Confirm the SAQ or ROC template
Check which PCI SSC template you are required to submit: an SAQ with its Attestation of Compliance, or a Report on Compliance completed by a Qualified Security Assessor. The SAQs for v4.0.1 were published on 15 October 2024, and each has its own eligibility criteria, including changed criteria in SAQ A, A-EP and C-VT. Confirm you are using the current version of the form and that every eligibility condition holds for your environment today. Your acquirer, not the PCI SSC, decides which template applies to you, so get that decision in writing before you start.
Document the vulnerability ranking method
Confirm you have a documented method for ranking vulnerabilities, with defined criteria for what counts as critical, and evidence that the method was applied to recent scan and advisory results. Keep the ranking records, the reasoning for any downgrade, and the dates each finding was assigned and closed. The PCI SSC expects ranking to be risk-based and consistent, so a ranking that exists only in a spreadsheet with no approvals will be difficult to defend. Your security team owns the method, and your assessor checks that it works in practice.
Assign owners for compliance evidence
Name one owner for each evidence set: patch records, key management logs, scan results, SAQ or ROC documentation and the Attestation of Compliance. For each owner, record who signs off, how often the evidence is refreshed and where it is stored. DeployOpen can prepare and organize the technical evidence for systems it has implemented, but your organization keeps ownership of the controls and of any sign-off. The QSA or the SAQ process then determines whether the evidence is sufficient.
Questions buyers ask about PCI DSS v4.0.1 and the next version
Which PCI DSS version applies to my organization today?
PCI DSS v4.0.1 is the only active version. It was published on 11 June 2024 as a limited revision of v4.0, and v4.0 was retired on 31 December 2024. PCI DSS v3.2.1 was retired earlier, on 31 March 2024, so any assessment still referencing it is out of date. Your acquirer or payment brand sets the validation date you must meet, so confirm with them which version and deadlines apply to your submission. The PCI SSC standard page is the reference to check against.
Does PCI DSS v4.0.1 add new requirements?
No. PCI DSS v4.0.1 added and removed no requirements compared with v4.0. It corrected wording, clarified several requirements and kept the 31 March 2025 effective date unchanged. The two changes most teams notice are the reverted patching timeframe for non-critical vulnerabilities in Requirement 6.3.3 and the clarified keyed hashing expectation in Requirement 3.5.1.1. Work through the change list against your existing controls rather than assuming the update is a rewrite.
Does the 2026 request for comments change how I am assessed today?
No. The PCI SSC ran a request for comments from 3 June to 20 July 2026 to begin the next iteration of the standard. Feedback collection does not alter the current requirements, and as of October 2026 the SSC had announced no release date for a new version. Your current assessment still runs against PCI DSS v4.0.1. Watch the PCI SSC announcements for any future version and its transition period, and plan your roadmap around the date the SSC publishes, not the comment period.
Who decides which PCI DSS version and validation I must submit?
The payment brands and your acquirer decide which entities must validate, how, and by when. The PCI Security Standards Council owns and maintains the standard, but it does not enforce compliance or impose penalties. Your acquirer or the relevant card brand program tells you whether you need a Report on Compliance or a Self-Assessment Questionnaire, and what they expect in the Attestation of Compliance. Ask them in writing which version, validation level and submission date apply to you.
Can an implementation partner issue the PCI DSS report or certificate?
No. An implementation partner can prepare systems, controls and evidence, but it cannot issue a report or attestation. A Report on Compliance must be completed by a Qualified Security Assessor, and a Self-Assessment Questionnaire is completed by the merchant or service provider and signed in an Attestation of Compliance on official PCI SSC templates. Certificates and compliance logos are not recognized as validation. DeployOpen prepares systems and evidence for assessments; it does not issue audit reports, attestations or certifications.
How much effort does the v4.0.1 update take for a typical organization?
The effort depends on your scope, how well your controls are documented and how mature your evidence is. No official effort figure is published for this update. Organizations with a small, well-documented cardholder data environment and a clean evidence trail typically face a narrower gap. Teams with broad scope, undocumented controls or evidence scattered across tools face more work. Ask any advisor for a written gap analysis against your scope before agreeing to a fixed price or timeline.
Can we complete the PCI DSS v4.0.1 update ourselves?
Many organizations can run the internal work themselves, especially the policy updates, inventories and evidence collection, provided they have clear ownership and time to do it. The parts that usually need outside input are the validation decision, the assessor's independent testing and any technical hardening or scanning support. Consulting and assessment must stay independent, so the team that prepares your evidence should not be the one that validates it. Confirm with your acquirer which work they accept from an internal assessor before you commit.
How DeployOpen prepares systems and evidence for PCI DSS v4.0.1
DeployOpen works on the v4.0.1 changes by preparing the systems, configurations and evidence that the organization's assessor will review, while the organization keeps ownership of its controls. We do not issue reports, attestations or certificates; the QSA or the applicable validation template does that.
How we scope
- Confirm in writing which systems, networks and third parties fall inside the cardholder data environment before work starts.
- Agree the validation path (SAQ or ROC) with your acquirer or payment brand contacts so the work matches the evidence required.
- Document which v4.0.1 requirements apply now and which were future-dated and became mandatory on 31 March 2025 for your environment.
How we build
- Configure the self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks to meet the affected requirements.
- Implement keyed hashing for PAN where it is used, with key management aligned to Requirements 3.6 and 3.7, and test the result.
- Set vulnerability and patch workflows that reflect the v4.0.1 rule for critical patches within one month and other patches on the entity's own timeframe.
How we hand over
- Deliver written configuration baselines, data-flow and network diagrams, and change records that map each system to the requirements it supports.
- Provide test records for scans, configuration checks and fixes so your team and assessor can trace each control to its evidence.
- Hand over runbooks and an evidence calendar so your staff can produce recurring artifacts without depending on DeployOpen.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the initial fixed-scope engagement ends.
- Track future revisions of the standard after the 2026 request for comments and confirm any change with the PCI SSC before updating systems.
- Ask your QSA or assessor to confirm how they will test the work and which evidence they will accept before implementation begins.
