Notifications
Clear all
Topic starter
12/06/2026 10:25 pm
TL;DR: PCI DSS v4.0 adds 64 new requirements, mandates MFA for access to cardholder data environments, and expands risk assessment and third-party security expectations as organisations move from v3.2.1 to the new standard, according to Zluri. The compliance problem is less about new wording than about proving continuous access governance across human, NHI, and supplier-owned identities.
NHIMG editorial — based on content published by Zluri: Access Management PCI DSS v4.0 and what's new in the latest version
By the numbers:
- PCI DSS v4.0 introduces 64 new requirements.
- The current version of PCI DSS v3.2.1 remained valid until March 31, 2024.
- If your organization handles payment card data, it must comply with v4.0 by March 31, 2025.
Questions worth separating out
Q: How should security teams run access reviews for PCI DSS v4.0?
A: They should run access reviews as a continuous governance process, not a one-time audit task.
Q: Why do third-party identities create more PCI DSS v4.0 risk?
A: Third-party identities expand the compliance boundary because the organisation still owns the risk even when access is granted to vendors or connected services.
Q: What do teams get wrong about customised PCI DSS controls?
A: They often assume a custom control is acceptable if it sounds reasonable.
Practitioner guidance
- Map all payment-system identities to owners and business purpose Build a current inventory of human, service, and supplier identities that can access cardholder-data environments, then record the approving owner, scope, and expiry condition for each one.
- Tie access reviews to documented remediation outcomes Do not treat a review as complete until unauthorized access has been removed and the evidence is retained for audit.
- Include third-party accounts in the same lifecycle process Apply joiner, mover, leaver handling to vendor identities and connected services so that offboarding, privilege reduction, and contract changes trigger access removal.
What's in the full article
Zluri's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step access review workflow examples for PCI DSS v4.0 compliance.
- How Zluri positions automated remediation and reporting for audit evidence.
- Examples of policy updates and monitoring workflows for access governance.
- The article’s own explanation of how its workflow maps to Intune and other environments.
👉 Read Zluri's overview of PCI DSS v4.0 access control and risk changes →
PCI DSS v4.0 access reviews and third-party risk: what changed?
Explore further
13/06/2026 1:10 am
PCI DSS v4.0 turns access governance into an evidence problem, not a policy problem. The article’s core message is that organisations must prove access decisions are current, monitored, and remediated, not merely written down. That aligns with the reality that payment environments fail when review workflows exist without reliable enforcement. Practitioners should read v4.0 as a demand for operational proof of control.
A few things that frame the scale:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
A question worth separating out:
Q: Who is accountable when PCI DSS access controls fail?
A: Accountability sits with the organisation that stores or processes cardholder data, even when the access path includes suppliers, integrators, or managed services. The practical answer is to assign named control owners for identity, review, and remediation so that failures can be traced to a business function, not a vague shared responsibility model.
👉 Read our full editorial: PCI DSS v4.0 raises the bar for access reviews and third-party risk
