PCI DSS v4.0.1: the 12 requirements, explained

PCI DSS v4.0.1 is the current version of the Payment Card Industry Data Security Standard, the PCI Security Standards Council's (PCI SSC) baseline for securing cardholder data. It organizes 12 numbered requirements under 6 high-level goals, and since 31 March 2025 it has enforced 51 additional requirements that were only "best practice" during a transition window — things like 12-character passwords and mandatory multi-factor authentication into the cardholder data environment are no longer optional.

From v3.2.1 to v4.0 to v4.0.1: the version history

PCI DSS v4.0 was published in March 2022, replacing the older v3.2.1. PCI SSC's own Summary of Changes from PCI DSS Version 3.2.1 to 4.0 (Revision 1, May 2022) documents exactly how big that jump was: 64 new requirements in total, split by when they took effect — 13 effective immediately for all v4.0 assessments, and 51 treated as "best practices" until 31 March 2025, after which they became mandatory requirements like any other.

PCI DSS v4.0.1 followed two years later. PCI SSC's blog post announcing it, Just Published: PCI DSS v4.0.1, describes it as a "limited revision" published 11 June 2024 that corrects "formatting and typographical errors" and clarifies "the focus and intent of some requirements," explicitly stating "there are no additional or deleted requirements in this revision." PCI DSS v4.0 itself was retired on 31 December 2024, after which — per the same post — "PCI DSS v4.0.1 became the only active version of the standard supported by PCI SSC." Critically, v4.0.1 did not move the 31 March 2025 effective date for the 51 future-dated requirements; that date came from the original v4.0 publication and held regardless of the later wording cleanup.

The 6 goals and 12 requirements

PCI SSC's own merchant compliance page lists the structure as follows:

Goal	Requirements
Build and Maintain a Secure Network and Systems	1. Install and Maintain Network Security Controls · 2. Apply Secure Configurations to All System Components
Protect Account Data	3. Protect Stored Account Data · 4. Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks
Maintain a Vulnerability Management Program	5. Protect All Systems and Networks from Malicious Software · 6. Develop and Maintain Secure Systems and Software
Implement Strong Access Control Measures	7. Restrict Access to System Components and Cardholder Data by Business Need to Know · 8. Identify Users and Authenticate Access to System Components · 9. Restrict Physical Access to Cardholder Data
Regularly Monitor and Test Networks	10. Log and Monitor All Access to System Components and Cardholder Data · 11. Test Security of Systems and Networks Regularly
Maintain an Information Security Policy	12. Support Information Security with Organizational Policies and Programs

Each of the 12 principal requirements breaks down further into numbered sub-requirements (for example, Requirement 8's password and MFA rules live at 8.3.x and 8.4.x) — this guide covers the top-level structure; the full sub-requirement text sits in the standard itself.

What became mandatory on 31 March 2025

PCI SSC's Summary of Changes document lists all 64 new v4.0 requirements individually, tagging each as either "Immediately for all v4.0 Assessments" or "31 March 2025." A sample of what crossed over from best-practice to mandatory on that date:

Requirement	What it requires
8.3.6	Password/passphrase minimum length of 12 characters, or 8 characters if the system cannot support 12
8.4.2	Multi-factor authentication for all access into the cardholder data environment (CDE), not just remote access
6.4.2	An automated technical solution for public-facing web applications that continually detects and prevents web-based attacks
6.4.3	Management of all payment page scripts loaded and executed in the consumer's browser
11.6.1	A change-and-tamper-detection mechanism for payment pages, alerting on unauthorized modification
5.4.1	Mechanisms to detect and protect personnel against phishing attacks

The 13 requirements that took effect immediately in 2022 were mostly structural — each principal requirement (1 through 12) got a new "roles and responsibilities" sub-requirement (e.g. 2.1.2, 3.1.2, 4.1.2) documenting who owns that area, plus a handful of scope-confirmation and reporting duties.

Who has to comply

PCI SSC's own PCI DSS overview page states the applicability plainly: PCI DSS applies to "entities that store, process, or transmit cardholder data (CHD) and/or sensitive authentication data (SAD) or could impact the security of the cardholder data environment (CDE)." The same page is careful to note a boundary on PCI SSC's own role: "whether an entity is required to comply with or validate compliance to a PCI SSC standard is at the discretion of organizations that manage compliance programs, such as a payment brand, acquirer, or other entity." In practice, PCI SSC writes and maintains the standard, but a merchant's specific validation path — which Self-Assessment Questionnaire (SAQ) type applies, whether an annual on-site assessment by a Qualified Security Assessor is required, and which "merchant level" it falls into — is set by the payment brands and the merchant's acquirer, not by PCI SSC. Any organization unsure of its obligations should confirm directly with its acquirer rather than assume a threshold from a third-party summary.

A workable starting point

1. Confirm your cardholder data environment (CDE) scope first. PCI DSS v4.0 added a dedicated "Scope of PCI DSS Requirements" section and an "Understanding PCI DSS Scoping" diagram specifically because scope-creep is the most common way assessments go wrong.
2. Treat the 31 March 2025 requirements as already-live, not upcoming — the transition period is over; all 64 new v4.0 requirements are now assessed like any other requirement.
3. Check your password, MFA and payment-page-script controls specifically — Requirements 8.3.6, 8.4.2, 6.4.3 and 11.6.1 are among the most operationally disruptive of the 51 future-dated requirements for teams that had not already implemented them.
4. Route merchant-level and SAQ-type questions to your acquirer, not PCI SSC — the Council sets the requirements; your acquirer and card brand set which validation path applies to you.

SoftWSP can help review the firmware and vulnerability-management side of a connected point-of-sale or payment device against PCI DSS's technical requirements: see device firmware security.

This guide summarises public PCI Security Standards Council publications; it does not constitute legal or compliance advice.