PCI DSS v4.0 raises the bar for access reviews and third-party risk

At a glance

What this is: This is an independent analysis of PCI DSS v4.0’s access-control, risk, and third-party security changes, with the key finding that compliance now depends on continuous identity governance rather than periodic checks.

Why it matters: It matters because payment programmes increasingly fail at the identity layer, where human access, service accounts, and vendor connections all need measurable review, evidence, and remediation.

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.

👉 Read Zluri's overview of PCI DSS v4.0 access control and risk changes

Context

PCI DSS v4.0 is the latest version of the payment card security standard, and the primary shift is from static compliance toward risk-based control validation. In practice, that means organisations now have to show that access controls, monitoring, and third-party oversight work continuously, not just at audit time. For identity teams, this is a governance problem as much as a security one.

The article frames access review, MFA, logging, and supplier oversight as the core mechanisms for staying compliant. That maps directly to IAM, PAM, and lifecycle governance because payment environments depend on who has access, how it is approved, and whether access is removed when it is no longer needed.

Key questions

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. The review should cover who has access, whether the access is still needed, whether the owner can justify it, and whether unauthorized permissions were actually removed before evidence is stored for assessment.

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. If those accounts are not inventoried, scoped, and offboarded with the same discipline as internal identities, cardholder-data exposure and audit failure become much more likely.

Q: What do teams get wrong about customised PCI DSS controls?

A: They often assume a custom control is acceptable if it sounds reasonable. In practice, the control must prove the same security outcome as the prescriptive requirement, with clear evidence of effectiveness, monitoring, and remediation. Without that proof, customisation becomes a documentation gap rather than a compliance advantage.

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.

Technical breakdown

Why PCI DSS v4.0 pushes access reviews beyond point-in-time validation

PCI DSS v4.0 makes access governance more evidence-driven by expecting organisations to prove that permissions remain appropriate over time. Access reviews are no longer just a periodic checkbox because the standard now ties compliance to ongoing monitoring, documented remediation, and clear accountability. That creates a stronger link between identity lifecycle controls and audit outcomes. For teams managing payment environments, the technical challenge is not only visibility into access, but also the ability to show that access exceptions are corrected and retained as evidence.

Practical implication: Treat access review as a continuous control with audit-ready remediation records, not a once-a-year certification exercise.

How third-party systems change the PCI DSS v4.0 risk model

The article emphasises third-party security because cardholder-data exposure often extends beyond internal users and systems. That shifts the problem from a simple perimeter model to a shared-responsibility model in which vendor access, supplier accounts, and connected services become part of the compliance boundary. When a third party can reach regulated data or supporting systems, the organisation must govern the identity, not just the network path. This is where lifecycle, offboarding, and least-privilege controls become central to payment security.

Practical implication: Inventory and review every supplier identity that touches payment systems, including its approval path, scope, and offboarding trigger.

What customized controls mean for identity governance in regulated environments

PCI DSS v4.0 allows a customised approach, but flexibility is only useful if an organisation can prove the control achieves the same security intent as the defined requirement. For identity teams, that means alternative control designs must still demonstrate who had access, why it was granted, how it was monitored, and when it was revoked. The burden therefore moves from simply meeting a prescriptive rule to documenting control effectiveness in a way auditors can test. This makes governance maturity, not tooling alone, the deciding factor.

Practical implication: Use customized controls only when you can produce clear evidence of effectiveness, traceability, and compensating accountability.

NHI Mgmt Group analysis

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.

Third-party access is now a first-class compliance boundary. PCI DSS v4.0 places more weight on vendor-connected systems because payment risk increasingly flows through supplier identities and integrated services. A programme that only governs employee accounts will miss the real exposure surface. The practitioner implication is that supplier identities must be included in the same governance model as internal access.

Customized controls widen the gap between mature and immature identity programmes. Organisations with strong IAM, PAM, and lifecycle discipline can adapt controls to their environment and still satisfy the standard. Organisations that rely on manual reviews and incomplete inventories will struggle to defend their choices during assessment. The practical conclusion is that flexibility rewards governance maturity, not improvisation.

Risk assessment in PCI DSS v4.0 is really lifecycle governance by another name. The standard now expects organisations to revisit risk, document evidence, and adjust controls as conditions change. That is the same operational discipline used in access recertification, offboarding, and privilege remediation. For identity leaders, the field lesson is clear: compliance follows the quality of the lifecycle process, not the volume of policy text.

Payment compliance increasingly depends on cross-domain identity control. Human authentication, service account oversight, and third-party entitlement management now intersect in the same compliance story. PCI DSS v4.0 does not isolate these problems, it exposes their interdependence. Practitioners should therefore align IAM, PAM, and supplier governance under one control framework.

From our research:

• 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.
• For a deeper governance baseline: Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs shows where review, rotation, and offboarding usually break down.

What this signals

PCI DSS v4.0 is likely to expose programmes that still separate compliance evidence from identity operations. The standard’s emphasis on continuous monitoring, third-party oversight, and documented remediation means access governance has to produce artefacts that auditors can test, not just controls that look correct on paper. Lifecycle evidence debt: when identities are not tied to expiry, ownership, and offboarding triggers, compliance findings accumulate faster than remediation can clear them.

For identity teams, the practical signal is that supplier access will be scrutinised more closely than before. A programme that can inventory employee access but not vendor entitlements will struggle to defend its control boundary. The next maturity step is to unify IAM, PAM, and third-party lifecycle management under the same evidence model.

The broader market signal is that payment compliance is becoming a proxy for identity governance maturity. Organisations that can prove access review quality, privilege containment, and revocation discipline will adapt faster to future framework changes, including tighter expectations around machine and service identities.

For practitioners

• 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. Use access review reports that show findings, action taken, and final status.
• 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.

Key takeaways

• PCI DSS v4.0 shifts the compliance burden toward continuous access governance and provable remediation.
• Third-party and service identities now sit inside the payment-risk boundary, not beside it.
• Organisations that cannot evidence ownership, review, and offboarding will struggle to defend custom controls or audit findings.

Key terms

• Customized approach: A customized approach lets an organisation design controls that meet a security objective without using the exact prescriptive method in the standard. In PCI DSS v4.0, that flexibility only works if the organisation can demonstrate the control is effective, measurable, and auditable in practice.
• Access review: An access review is a formal check of who has access, whether that access is still justified, and whether any changes are needed. In regulated environments, the value is not the review itself but the evidence that excess access was identified, removed, and recorded.
• Third-party identity: A third-party identity is an account or credential used by a supplier, partner, or managed service to access an organisation's systems. These identities are high-risk because the access often spans organisational boundaries, making ownership, lifecycle control, and offboarding harder to enforce.
• Cardholder data environment: The cardholder data environment is the systems, people, and processes that store, process, or transmit payment card data. For identity teams, it becomes the control boundary where authentication, authorization, logging, and revocation must be proven, not assumed.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Zluri: Access Management PCI DSS v4.0 and what's new in the latest version. Read the original.