PCI DSS 4.0 replaced 3.2.1 as the required standard in March 2025. Most parking operators encountered the transition as a generic checkbox exercise mediated by their acquirer or gateway. A few of the changes, however, have meaningful operational consequences that checkbox exercises miss.

This article focuses on the requirements where 4.0 genuinely differs from 3.2.1 for parking operators — and which ones are more than paperwork.

The Shift From Prescriptive to Outcome-Based

The most consequential change in 4.0 isn’t a specific requirement. It’s the introduction of a “customized approach” that lets operators meet security objectives through alternative controls, provided they document the objective, the risk, and the chosen control with equal rigor.

For parking operators, this matters because several 3.2.1 requirements — particularly around quarterly internal vulnerability scanning on every network segment — were operationally painful in multi-site environments. 4.0 lets you substitute continuous monitoring, properly documented, for the rigid quarterly cycle. The tradeoff: the documentation burden is substantially higher.

Operators with small IT teams should stick with the prescribed approach. Operators with mature security programs can save ongoing effort with the customized approach — but only after investing in the initial documentation work.

Requirements That Genuinely Changed

8.3.6: Password length increased to 12 characters. 3.2.1 required 7. Parking operators with back-office systems, pay station admin panels, and enforcement devices all using 8-character passwords need to force a reset cycle.

11.6.1: Scripts on payment pages must be managed. If your operator portal includes any script — analytics, session replay, customer service widget — on a page that handles cardholder data, you now need a documented script inventory with integrity verification. Most operators discover they’re using three or four scripts they didn’t know were there.

12.3.1: Risk analysis required for customized controls. Any compensating or customized control needs a documented risk analysis reviewed annually. This is the paperwork price of the flexibility in the customized approach.

5.4.1: Phishing-resistant authentication for administrative access. Username/password alone is no longer acceptable for administrative access to systems in the cardholder data environment. MFA is the usual solution; hardware tokens are preferred for high-privilege accounts.

Scope Questions Most Operators Get Wrong

Mobile payment providers. If your facility offers mobile pay through a third-party app (ParkMobile, PayByPhone, Passport, etc.), the scope question is subtle. The app provider handles most of the compliance, but the physical signage, QR codes, and transaction reconciliation may still place elements of your operation in scope. Ask your provider for their Responsibility Matrix specifically for PCI DSS 4.0 — the 3.2.1 matrix is no longer current.

Wi-Fi networks at facilities. If a facility’s Wi-Fi is reachable from any system processing card data (including pay station maintenance ports connected during service), the Wi-Fi is in scope. Segmentation is the cheapest fix; many operators discover the segmentation they assumed existed is theoretical.

Phone system integration. VoIP systems carrying payment-related calls (typically customer service or refund lines) are in scope under 4.0’s broader interpretation of “payment channels.” 3.2.1 was ambiguous on this; 4.0 is not.

Documentation That Survives an Audit

QSAs auditing to 4.0 are asking for evidence-of-activity, not just policy documents. A written password policy is insufficient; you need logs showing the policy is enforced. This is where most parking operators fall short — they have policies but not the log retention to prove those policies are active.

Minimum evidence for a parking operator:

  • Authentication logs showing 12-character enforcement (90-day retention minimum, 1-year preferred)
  • Script inventory with cryptographic hashes and change history
  • Quarterly access review documentation with signoff
  • Vendor Responsibility Matrices for every third-party payment component

Frequently Asked Questions

Do I need to hire a QSA to become 4.0 compliant?

Level 4 merchants (under 20,000 e-commerce transactions annually) typically self-attest via the SAQ appropriate to their transaction flow. Level 1 (over 6 million transactions) requires a QSA. Most parking operators fall in Levels 3 and 4 and do not need a QSA for attestation, but should engage one for initial gap analysis if PCI experience is limited.

Is tokenization required under 4.0?

Not explicitly, but tokenization substantially reduces compliance scope. A parking operator that tokenizes all stored card data can typically complete a shorter SAQ — usually SAQ A or SAQ A-EP — rather than SAQ D. The scope reduction often justifies the tokenization service fees within a year.

What happens if we’re not compliant by the deadline?

PCI non-compliance triggers acquirer-imposed fines (typically $5,000-$100,000/month depending on merchant level), increased transaction fees, and in the event of a breach, significantly reduced liability protection. The practical enforcement mechanism is the acquirer, not a regulator, which means consequences vary but are real.

How does 4.0 treat legacy pay stations that can’t meet requirements?

A pay station that cannot support 12-character passwords or the required cryptographic algorithms is a compensating-control situation. You document why the hardware can’t comply, what compensating controls you’ve implemented (typically network segmentation and enhanced monitoring), and accept the QSA’s or self-assessment finding. This is a bridge, not a permanent solution — hardware replacement typically becomes compulsory within 2-3 years of a scheme mandate.