PCI DSS v4.0 requirements What's New and Who Needs to Comply
PCI DSS v4.0 requirements stopped being “something to plan for” a while back — if your company stores, processes, or transmits payment card data, it’s the version your acquirer, your assessor, or your biggest customer’s security questionnaire is testing you against today. PCI DSS v3.2.1 was retired back in 2024, and the transition window for v4.0’s toughest new requirements closed on March 31, 2025. Every PCI DSS assessment run in 2026 is measured against v4.0.1, the current, fully-in-force version of the standard. Most teams aren’t stuck on any single requirement — they’re stuck figuring out what actually changed, what’s genuinely new, and whether their business even falls in scope. This guide walks through v4.0 in plain English: what changed from v3.2.1, the requirements that are now mandatory, the key dates, and who needs to pay attention.
Quick answer PCI DSS v4.0 (now formally v4.0.1) is the current version of the Payment Card Industry Data Security Standard, replacing v3.2.1. It introduced 64 new or updated requirements — 13 that took effect immediately in 2022 and 51 “future-dated” ones that became mandatory on March 31, 2025. It applies to any organization that stores, processes, or transmits cardholder data, or that could impact the security of a payment transaction, regardless of size. v4.0.1, released in 2024, made no changes to requirements — only clarifications and corrections.
What Is PCI DSS v4.0, Exactly?
The Payment Card Industry Data Security Standard (PCI DSS) is a set of security requirements maintained by the PCI Security Standards Council — the body formed by the major card brands — for anyone who handles payment card data. Unlike ISO or NIST frameworks, PCI DSS isn’t a government regulation; it’s a contractual obligation enforced through your merchant agreement or acquiring bank, which makes non-compliance a business risk rather than a legal one, though the consequences (fines, higher transaction fees, loss of card-processing privileges) can be just as serious.
Version 4.0 replaced the long-serving v3.2.1 and represents the most significant overhaul the standard has had in years. Rather than a routine update, the PCI SSC used v4.0 to shift the standard’s underlying philosophy: away from PCI compliance as a once-a-year audit event, and toward security as a continuous, business-as-usual practice. That shows up throughout the standard as new requirements for ongoing monitoring, targeted risk analyses, and named ownership of security responsibilities, rather than one-time checkbox controls.
A quick note on versioning: PCI DSS v4.0.1, released in mid-2024, is a limited revision — it corrected typographical errors and clarified the intent of specific requirements (multi-factor authentication, patch management timelines, payment-page script management, among others), but it added and removed zero requirements. When people refer to “v4.0 requirements” in 2026, they mean the same 64 new or updated requirements, just under the current v4.0.1 text.
The Requirements: What's the Same, What's Renamed
PCI DSS still organizes its controls under the same 12 core requirements and six control objectives it has used for years. The requirement numbers didn’t change — but several were renamed to reflect a broader scope than the old titles implied.
| Control Objective | PCI DSS v3.2.1 | PCI DSS v4.0 |
|---|---|---|
| Build and maintain a secure network and systems | 1. Install and maintain a firewall configuration to protect cardholder data | 1. Install and maintain network security controls |
| Build and maintain a secure network and systems | 2. Do not use vendor-supplied defaults for system passwords and other security parameters | 2. Apply secure configurations to all system components |
| Protect cardholder data | 3. Protect stored cardholder data | 3. Protect stored account data |
| Protect cardholder data | 4. Encrypt transmission of cardholder data across open, public networks | 4. Protect cardholder data with strong cryptography during transmission over open, public networks |
| Maintain a vulnerability management program | 5. Protect all systems against malware and regularly update antivirus software | 5. Protect all systems and networks from malicious software |
| Maintain a vulnerability management program | 6. Develop and maintain secure systems and applications | 6. Develop and maintain secure systems and software |
| Implement strong access control measures | 7. Restrict access to cardholder data by business need-to-know | 7. Restrict access to system components and cardholder data by business need-to-know |
| Implement strong access control measures | 8. Identify and authenticate access to system components | 8. Identify users and authenticate access to system components |
| Implement strong access control measures | 9. Restrict physical access to cardholder data | 9. Restrict physical access to cardholder data |
| Regularly monitor and test networks | 10. Track and monitor all access to network resources and cardholder data | 10. Log and monitor all access to system components and cardholder data |
| Regularly monitor and test networks | 11. Regularly test security systems and processes | 11. Test security of systems and networks regularly |
Important context – B4Q Assurance runs PCI DSS gap assessments against the full v4.0.1 requirement set as part of every engagement, mapping which of the 64 new/updated requirements already have evidence in place and which still need remediation before a Report on Compliance (ROC) or Self-Assessment Questionnaire (SAQ) is submitted.
What Actually Changed: The Headline New Requirements
Of the roughly 64 new or updated requirements in v4.0, a handful account for most of the implementation effort teams report. These are the ones worth planning around first.
Universal multi-factor authentication (Req. 8.4.2 / 8.3.1) — Under v3.2.1, MFA was only mandatory for administrators and remote access into the cardholder data environment (CDE). Under v4.0, MFA is required for all access into the CDE, including non-administrative users. A clarification in v4.0.1 confirms that accounts using phishing-resistant authentication factors — FIDO2/WebAuthn hardware keys or certificate-based authentication — already satisfy the intent of MFA and don’t need a second, separate factor stacked on top.
12-character minimum passwords (Req. 8.3.6) — The password length minimum moved up from 7 to 12 characters (or 8, where the system genuinely can’t support 12), alongside continued complexity requirements.
Targeted risk analyses — Several controls that used to specify a fixed frequency (for example, reviewing logs daily) now let organizations define their own cadence, provided it’s backed by a documented risk analysis justifying the choice.
Named roles and responsibilities — Many requirements now explicitly call for documented ownership: a specific role or team accountable for each control, not just a policy that references the requirement in the abstract.
Anti-skimming controls for payment pages (Req. 6.4.3 and 11.6.1) — E-commerce merchants must now inventory and monitor scripts loaded on payment pages and detect unauthorized changes, directly targeting the digital skimming attacks that hit checkout pages.
Authenticated internal vulnerability scanning (Req. 11.3.1.2) — Internal vulnerability scans must now be performed with authenticated scanning wherever technically feasible, surfacing issues that unauthenticated scans typically miss.
Encryption of sensitive authentication data and cardholder data at rest — Expanded cryptography requirements clarify how account data must be rendered unreadable, including guidance on keyed cryptographic hashes, refined further in v4.0.1.
Key Dates: The PCI DSS v4.0 Timeline
The rollout of v4.0 followed a multi-year transition designed to give organizations time to implement the more demanding controls before they became mandatory.
| Date | Milestone |
|---|---|
| March 31, 2022 | PCI DSS v4.0 officially released, alongside validation documents. |
| 2022–2023 | Transition period: ISAs and QSAs trained on v4.0; supporting documents published; both v3.2.1 and v4.0 active simultaneously. |
| March 31, 2024 | PCI DSS v3.2.1 formally retired — v4.0 (and later v4.0.1) became the only active version. |
| Mid-2024 | PCI DSS v4.0.1 published — a limited revision correcting errors and clarifying intent, with zero new or deleted requirements. |
| March 31, 2025 | The 51 "future-dated" requirements — including universal MFA and the 12-character password minimum — became mandatory for all assessments. |
| 2026 onward | All PCI DSS assessments are conducted against v4.0.1 in full; every one of the 64 new or updated requirements is in scope. |
If your organization last validated under v3.2.1, or validated under v4.0 in 2024 without implementing the future-dated requirements, treat your next assessment as a gap assessment first — those requirements are no longer optional best practices.
Who Needs to Comply With PCI DSS v4.0?
PCI DSS applies to any entity that stores, processes, or transmits cardholder data, or that could impact the security of the cardholder data environment — regardless of transaction volume or company size. In practice, that covers a wide range of business types:
- Merchants of all sizes that accept card payments, from large e-commerce platforms down to small businesses using a single card reader
- Payment processors, gateways, and payment facilitators
- Service providers whose infrastructure touches cardholder data — hosting providers, SaaS platforms with embedded payments, managed security providers
- E-commerce businesses, particularly those in scope for the payment-page script requirements (6.4.3, 11.6.1)
- Financial institutions issuing or supporting card products
Exactly how you validate compliance — a Self-Assessment Questionnaire (SAQ) versus a full Report on Compliance (ROC) with a Qualified Security Assessor (QSA) — depends on your PCI DSS merchant or service provider level, which is driven mainly by annual transaction volume. That level determines how much of the 64-requirement set applies directly to your assessment, and it’s detailed enough to warrant its own guide.
Common mistake – Assuming that because PCI DSS v4.0.1 made “no new requirements,” a v3.2.1-era compliance program is still good enough. The requirements that matter most for 2026 assessments — universal MFA, 12-character passwords, payment-page script monitoring — came from v4.0, not v4.0.1. Treating the two as interchangeable is one of the fastest ways to walk into an assessment with unremediated gaps.
How Organizations Are Approaching the Transition
Because the future-dated requirements are now fully in force, most organizations are no longer asking whether to implement v4.0 — they’re auditing how much of it they’ve actually completed. A structured approach typically means comparing current controls against all 64 new or updated requirements (not just the 13 that were immediately effective back in 2022), documenting where evidence already exists, flagging partial controls, and building a prioritized remediation plan for the gaps — usually starting with the requirements that touch authentication and payment-page integrity, since those tend to require the most architectural change.
How B4Q Assurance Helps
B4Q Assurance works with merchants, service providers, and payment platforms to assess their environment against the full PCI DSS v4.0.1 requirement set, build the remediation roadmap for any outstanding future-dated controls, and prepare the evidence QSAs expect to see for a Report on Compliance or a Self-Assessment Questionnaire. Rather than treating all 64 requirements as equally urgent, we help clients prioritize based on their actual cardholder data footprint and assessment type.
Ready to check your PCI DSS v4.0.1 readiness?
Book a free strategy call with B4Q Assurance to scope a PCI DSS v4.0.1 gap assessment against your current environment.
Resources
PCI Security Standards Council — Official Document Library: https://www.pcisecuritystandards.org/document_library/
PCI SSC — Just Published: PCI DSS v4.0.1: https://blog.pcisecuritystandards.org/just-published-pci-dss-v4-0-1
PCI SSC — Summary of Changes, v3.2.1 to v4.0: https://listings.pcisecuritystandards.org/documents/PCI-DSS-v3-2-1-to-v4-0-Summary-of-Changes-r1.pdf
FAQs
Is PCI DSS v4.0 still valid, or do we need v4.0.1?
v4.0.1 is the only active version now. It’s a limited revision of v4.0 — no requirements were added or removed, only clarified and corrected — so “v4.0 compliance” and “v4.0.1 compliance” refer to the same requirement set in practice.
Do the March 31, 2025 requirements still need to be implemented if we missed the deadline?
Yes. The deadline determined when assessors started testing against those requirements, not whether they still apply. Every assessment from 2026 onward tests all 64 new or updated requirements, so any gap needs remediating regardless of when the original deadline passed.
What's the difference between an SAQ and a ROC?
A Self-Assessment Questionnaire (SAQ) is a self-validated questionnaire used by lower-volume merchants, while a Report on Compliance (ROC) is a full assessment conducted by a Qualified Security Assessor (QSA), typically required for higher-volume merchants and most service providers. Which one applies depends on your PCI DSS level.
Does PCI DSS v4.0 apply to us if we use a third-party payment processor?
Possibly, but with reduced scope. If your payment page is fully outsourced and you never touch cardholder data directly, you may qualify for a shorter SAQ (such as SAQ A). If your website can influence how card data is captured or transmitted — including through payment-page scripts — you’re likely in scope for a broader set of requirements, including 6.4.3 and 11.6.1.
Is PCI DSS a legal requirement?
No — it’s a contractual requirement imposed by the card brands and enforced through acquiring banks and merchant agreements, not a government law. That doesn’t reduce the consequences of non-compliance, which can include fines, increased transaction fees, or loss of the ability to process card payments.