PCI DSS 3.2 Compliance: 12 Requirements and the Shift to 4.0

PCI DSS 3.2 compliance is no longer possible: version 3.2 (and the 3.2.1 minor update) was retired on March 31, 2024, and since March 31, 2025, PCI DSS version 4.0 is the only version accepted for validation.¹ If your security program is still built around the 3.2 control set, you have a live compliance gap. The twelve-requirement structure carried forward into 4.0, so the bones of what you built are still useful. The specifics are not. Below is what 3.2 required, what 4.0 added on top, and what you need to do about it.

The 12 Requirements That Defined Version 3.2

Version 3.2 organized its controls into twelve numbered requirements grouped under six goals. The structure is worth knowing because 4.0 kept it intact and most 3.2-era documentation still maps cleanly to the new standard.

Secure Network and Systems

Requirement 1 called for firewall configurations that restricted traffic to only what payment processing needed, with every connection to the cardholder data environment documented and justified. Requirement 2 prohibited vendor-supplied default passwords and settings; factory credentials had to be changed and unnecessary services disabled before any system went live.²

Cardholder Data Protection

Requirement 3 covered stored data: minimize what you keep, enforce retention and disposal policies, and encrypt primary account numbers. Displayed PANs had to be masked to the last four digits unless the viewer had a documented business need. Requirement 4 covered data in transit, mandating strong encryption (such as TLS) across open networks and explicitly prohibiting unencrypted card numbers in email or instant messages.²

Vulnerability Management

Requirement 5 required active, logging anti-malware software on all systems commonly affected by malicious software. Requirement 6 required a secure development process and installation of critical security patches within one month of release.³

Access Controls

Requirement 7 limited cardholder data access to personnel whose job required it, and Requirement 8 required unique credentials for every user. Version 3.2 expanded Requirement 8.3 to require multi-factor authentication for all non-console administrative access into the cardholder data environment, which was the headline change of that release.⁴ Requirement 9 handled physical security: camera surveillance, entry controls, and protection of any location where cardholder data could be physically accessed.

Monitoring and Testing

Requirement 10 demanded comprehensive logging of access to network resources and cardholder data, with logs retained for at least one year and three months immediately available for analysis.⁵ Requirement 11 required quarterly internal vulnerability scans, quarterly external scans by an Approved Scanning Vendor, and penetration testing at least annually or after any significant infrastructure change.

Security Policy

Requirement 12 was the administrative layer: a written information security policy covering all twelve requirements, formal annual risk assessments, and security awareness training for all employees on hire and at least yearly.

What Version 4.0 Requires That 3.2 Didn’t

Version 4.0 added 64 new requirements on top of the existing structure. A handful of those are the ones most likely to catch a 3.2-era program off guard.

Multi-Factor Authentication for All CDE Access

Under 3.2, MFA was mandatory only for administrative and remote access to the cardholder data environment. Version 4.0 extended it to all access into the CDE, administrative or not.¹ This was among the 47 requirements that became mandatory on March 31, 2025 after a year-long best-practice transition.

Twelve-Character Passwords

The 3.2 minimum was seven characters. Version 4.0 raised it to twelve, or eight if the system cannot support twelve.¹ A system still enforcing a seven-character minimum is out of compliance today.

The Customized Approach

Version 3.2 allowed compensating controls when a legitimate constraint prevented meeting a requirement as written. Version 4.0 keeps compensating controls and adds a parallel option called the customized approach, which lets an organization meet a requirement’s security objective through a different method than the one specified.⁶ Each customized implementation requires a documented targeted risk analysis and assessor evaluation, so it is not a shortcut. It is useful for mature programs that have better controls than the prescribed ones.

Targeted Risk Analysis

Several 4.0 requirements let you set your own frequencies for things like malware scans, log reviews, and device inspections, provided you perform and document a targeted risk analysis supporting the chosen interval.⁷ Assessors will scrutinize the analysis itself, so weak documentation is worse than keeping the default cadence.

How You Validate Compliance Now

Validation requirements scale with annual transaction volume. The thresholds below reflect Visa’s program, which is representative of the major brands.

Level 1: more than 6 million Visa transactions per year across all channels, or any merchant that has suffered a data breach. Requires an annual on-site assessment by a Qualified Security Assessor and a Report on Compliance.
Level 2: 1 million to 6 million transactions per year. Typically validated through a Self-Assessment Questionnaire, though the acquiring bank can require an on-site audit.
Level 3: 20,000 to 1 million e-commerce transactions per year.
Level 4: fewer than 20,000 e-commerce transactions per year, or up to 1 million total transactions across all channels.

⁸

Service providers fall into two levels. Level 1 covers any provider storing, processing, or transmitting more than 300,000 transactions per year and requires an on-site QSA assessment; Level 2 covers providers below that threshold.⁸ A breach can push any organization to Level 1 regardless of volume, which means a full on-site audit at your expense.

Most merchants below Level 1 validate using a Self-Assessment Questionnaire, and picking the right one matters because each form is tailored to a specific payment environment.

SAQ A: all cardholder data storage, processing, and transmission outsourced to validated third parties; you never touch card data electronically.
SAQ A-EP: e-commerce merchants who outsource processing but whose website could affect transaction security, such as hosting payment page elements.
SAQ B: standalone dial-out terminals on a phone line, no electronic storage.
SAQ B-IP: standalone terminals with IP connections to the processor, no electronic storage.
SAQ C-VT: manual keyed entry one transaction at a time through a validated virtual terminal.
SAQ C: payment systems connected to the internet, no electronic storage.
SAQ P2PE: hardware terminals managed through a validated point-to-point encryption solution.
SAQ D: the catch-all for any environment the others do not fit, including merchants that store cardholder data locally. It covers the full standard and is by far the longest.

⁹

Validation renews annually, and quarterly ASV scans continue throughout the year. A failing scan has to be remediated and re-scanned clean before you can finalize your attestation.

What Happens If You Stay Out of Compliance

Card brands enforce PCI DSS indirectly through acquiring banks and processors. Penalties can include fines passed down from the brands (commonly reported in the range of $5,000 to $100,000 per month depending on severity and duration), higher per-transaction fees, and in serious cases suspension or termination of your ability to accept card payments.¹⁰ Losing processing capability is existential for most merchants, and it is the penalty that usually gets attention.

A breach escalates everything. The card brands require the affected organization to immediately engage a PCI Forensic Investigator from the PCI SSC’s approved list.¹⁰ Add card reissuance costs, customer notification, credit monitoring, potential litigation, and the Level 1 reclassification that triggers an annual on-site QSA audit from that point forward.

Shrinking What You Have to Protect

The less cardholder data your systems touch, the fewer PCI DSS requirements apply to you. Two technologies do most of the work.

Tokenization replaces real card numbers with tokens that have no exploitable value if stolen. A properly implemented solution can eliminate the need to store PANs after the initial transaction, pulling large portions of your infrastructure out of scope.¹¹ Recovering the original PAN from a token alone must be computationally infeasible, and systems handling tokens must be segmented from any system that can de-tokenize.

Point-to-point encryption encrypts card data at the terminal before it reaches your network, with decryption keys held by the solution provider rather than you. A validated P2PE solution lets you qualify for SAQ P2PE, which is dramatically shorter than SAQ D. For small and mid-sized merchants, combining P2PE or tokenization with outsourced processing is usually the cheapest route to compliance.

State Safe Harbor Laws

Connecticut, Iowa, Ohio, Oklahoma, Texas, and Utah have each enacted some form of cyber safe harbor law, generally providing a defense against tort claims if a breached organization maintained a written security program conforming to a recognized framework such as the NIST Cybersecurity Framework, CIS Critical Security Controls, or ISO 27000, scaled to the organization’s size. PCI DSS compliance alone may not be enough. Iowa’s statute, for example, explicitly states that PCI DSS by itself does not qualify for the affirmative defense. The practical read: PCI DSS is a strong component of a safe harbor posture, but building the broader program around one of the general frameworks is what the statutes reward.

1
PCI Security Standards Council. Summary of Changes From PCI DSS Version 3.2.1 to 4.0
2
PCI Security Standards Council. PCI DSS Quick Reference Guide
3
PCI Security Standards Council. PCI DSS Quick Reference Guide
4
PCI Security Standards Council. PCI DSS 3.2 Resource Guide
5
PCI Security Standards Council. Effective Daily Log Monitoring Guidance
6
PCI Security Standards Council. PCI DSS v4.0 Compensating Controls vs Customized Approach
7
PCI Security Standards Council. Just Published PCI DSS v4.x Targeted Risk Analysis Guidance
8
Visa. Validation of Compliance
9
PCI Security Standards Council. Understanding Self-Assessment Questionnaires
10
PCI Security Standards Council. Responding to a Cardholder Data Breach
11
PCI Security Standards Council. PCI DSS Tokenization Guidelines