PCI DSS 3.2.1 Retires March 31, 2024: Are You Ready for the Switch?

PCI DSS v3.2.1 retires on March 31, 2024. After that date, every PCI DSS assessment, whether a Report on Compliance (ROC) or a Self-Assessment Questionnaire (SAQ), has to be completed against v4.0. The 51 new requirements that v4.0 marks as future-dated stay best practice until March 31, 2025, so the retirement doesn't make everything mandatory at once. It does change the templates, the documentation your assessor expects, and a set of requirements that took effect the day v4.0 was published. If your next assessment lands after March 31, the transition work starts now.

What changes when PCI DSS 3.2.1 retires?

The PCI Security Standards Council (PCI SSC) published v4.0 on March 31, 2022 and set a two-year transition period during which both versions are valid. When that window closes, v4.0 becomes the only active version of the standard.

In practice, that means three things:

• Any assessment completed after March 31, 2024 uses the v4.0 requirements, testing procedures and reporting templates.
• Every v4.0 requirement that isn't future-dated applies in full. That includes the controls carried over from 3.2.1, many with revised wording, plus 13 new requirements that were effective immediately.
• The 51 future-dated requirements can be assessed if you've implemented them, but they don't have to be in place until March 31, 2025.

If your assessment period straddles the retirement date, ask your QSA and your acquirer now which version they expect. Planning for v4.0 is the safer assumption.

How do the 2024 and 2025 deadlines fit together?

The PCI SSC's Summary of Changes from v3.2.1 to v4.0 lists 64 new requirements. Thirteen were effective immediately for any v4.0 assessment, and 51 are future-dated. Most of the immediate ones are the roles-and-responsibilities requirements covered below.

The mistake to avoid is treating 2025 as the "real" deadline. Your first v4.0 assessment will test the immediate requirements. And some future-dated items, such as multi-factor authentication (MFA) for all access into the cardholder data environment (CDE) or authenticated internal scanning, can take the better part of a year to roll out cleanly.

How do you run a PCI DSS 4.0 gap assessment?

A gap assessment compares what you do today against v4.0's wording and testing procedures, requirement by requirement. The Summary of Changes is the best starting map, because it labels each change as an evolving requirement, a clarification or a structural change.

A practical sequence:

1. Confirm scope first. Refresh your data-flow diagrams, account data locations and segmentation boundaries. v4.0 expects this to be documented anyway (see 12.5.2 below).
2. Walk each of the 12 principal requirements. Read the v4.0 requirement, its applicability notes and its testing procedures. The testing procedures tell you what evidence the assessor will ask for.
3. Sort gaps by deadline. Separate "needed for our first v4.0 assessment" from "needed by March 31, 2025."
4. Flag long-lead items. Anything that needs budget, a new tool, an architecture change or a vendor's cooperation goes to the top of the 2025 list.
5. Assign owners and dates. A gap list without owners tends to still be a gap list six months later.

Don't skip requirements that "haven't changed." Many existing controls were renumbered or reworded, and the testing procedures behind them moved. Your evidence from the last 3.2.1 assessment is a starting point, not a finished answer.

What new documentation does v4.0 require now?

Roles and responsibilities in every requirement

Each of Requirements 1 through 11 now opens with two sub-requirements. The first (1.1.1, 2.1.1 and so on) covers documented, current policies and procedures that are in use and known to the people affected. The second (1.1.2 through 11.1.2) requires that roles and responsibilities for that requirement's activities are "documented, assigned, and understood." Requirement 12 covers the same ground through its own security policy and role requirements.

The word that trips people up is "understood." Assessors are expected to interview the people named, not just read a document. A simple approach that works:

• Build one responsibility matrix covering all 12 requirements, naming roles rather than individuals where you can.
• Link each role to the procedures it performs.
• Brief each role holder and keep a record of it, such as a signed acknowledgement or a training entry.

Annual scope confirmation

Requirement 12.5.2 took effect immediately. You must document and confirm your PCI DSS scope at least once every 12 months and after significant changes to the in-scope environment. The confirmation covers data flows, every location where account data is stored, processed or transmitted, the system components involved, segmentation controls and connections from third parties. It's your job, not the assessor's.

Service provider support for customers

Service providers picked up 12.9.2 immediately. It requires them to support customer requests for their PCI DSS compliance status and for information about which requirements are the provider's responsibility, the customer's, or shared. Expect customers to ask for a responsibility matrix, and have one ready.

What is a targeted risk analysis, and when do you need one?

v4.0 lets you set the frequency of some activities yourself, as long as the choice is backed by a targeted risk analysis (TRA). Requirement 12.3.1 defines what that TRA must include:

• The assets being protected
• The threats the requirement protects against
• Factors that contribute to the likelihood or impact of a threat being realized
• An analysis that determines, and justifies, how often the activity must be performed
• A review of each TRA at least once every 12 months
• Updated analyses when the annual review shows they're needed

Requirement 12.3.1 is future-dated, and so are the requirements that depend on it. Examples include periodic evaluations of systems considered not at risk from malware (5.2.3.1), log review frequency for lower-risk systems (10.4.2.1) and inspection frequency for point-of-interaction devices (9.5.1.2.1). A separate requirement, 12.3.2, calls for a TRA for every requirement you meet with the customized approach, and that one applies now.

Write frequency TRAs early anyway. A TRA drafted under deadline pressure tends to justify whatever the team already does, and that's exactly what an assessor will probe.

What changes in the SAQs and the ROC Template?

Both reporting formats were rebuilt for v4.0. Neither is a reskin of the 3.2.1 version.

SAQs. The v4.0 SAQs follow the new numbering and wording, and responses move from 3.2.1's "Yes/No" answers to options such as "In Place," "Not Applicable" and "Not in Place." Content changed too. SAQ A, for example, now includes the payment page script requirements 6.4.3 and 11.6.1, both future-dated. Read your SAQ line by line and reconfirm that you still meet its eligibility criteria. Also note that the customized approach isn't supported in SAQs.

ROC Template. The v4.0 ROC Template restructures how assessors report findings and records whether a requirement was met with a compensating control or the customized approach. Ask your QSA how they plan to evidence each testing procedure, and whether they want evidence organized differently from last time.

The Attestations of Compliance changed alongside both. If your acquirer, customers or partners rely on your AOC, let them know a v4.0 version is coming.

Should you use the customized approach?

The customized approach lets you meet a requirement's stated objective with controls that don't follow the defined requirement's wording. It suits mature environments with unusual architectures. It also adds work: documented controls, a TRA for each customized requirement under 12.3.2, and testing that the assessor designs specifically for your controls.

For most small and mid-sized organizations, the defined approach, with compensating controls where they're justified, is the simpler path for the first v4.0 cycle.

A practical transition checklist

1. Confirm your next assessment date and which version your QSA and acquirer expect.
2. Get the v4.0 standard, the Summary of Changes and the correct v4.0 SAQ or ROC Template.
3. Refresh and document your scope under 12.5.2.
4. Run the gap assessment and split findings into "now" and "by March 31, 2025."
5. Publish roles and responsibilities for Requirements 1–11 and brief the people named.
6. Update policies and procedures to match v4.0 numbering and wording.
7. Draft the targeted risk analyses your environment will need.
8. Start the long-lead future-dated work: MFA for all CDE access (8.4.2), authenticated internal scanning (11.3.1.2), automated audit log reviews (10.4.1.1), payment page script controls (6.4.3 and 11.6.1) and an automated technical solution for public-facing web applications (6.4.2).
9. Schedule a readiness review with your assessor well before fieldwork.

Frequently asked questions

Can we still be assessed against PCI DSS 3.2.1 after March 31, 2024?

No. Once v3.2.1 is retired, v4.0 is the only active version. If fieldwork starts before the date and finishes after it, confirm the version with your QSA and acquirer in writing.

Do the future-dated requirements count in a 2024 assessment?

They're best practice until March 31, 2025, so not having them in place won't fail a 2024 assessment. If you've already implemented some, having them assessed early is a low-risk way to find problems before they count.

Does v4.0 change what's in scope?

The scoping principles are largely the same. What's new is the formal expectation that you confirm scope yourself every 12 months, with evidence. v4.0 also uses "account data" as the umbrella term for cardholder data and sensitive authentication data.

Is a gap assessment required?

The standard doesn't require one. It's simply the most reliable way to avoid discovering gaps during fieldwork.

Key takeaways

• On March 31, 2024, v4.0 becomes the only standard you can be assessed against. On March 31, 2025, the future-dated requirements become mandatory.
• The immediate changes are mostly documentation: roles and responsibilities, policies and procedures, and annual scope confirmation.
• Start the long-lead technical work now, and write targeted risk analyses before you need them.
• Treat the v4.0 SAQs and ROC Template as new documents and read them in full.