How should organisations use access reviews to support PCI DSS compliance?

Why This Matters for Security Teams

Access reviews are not a paperwork exercise for PCI DSS. They are the control that shows cardholder data access is actively governed, periodically revalidated, and removed when it is no longer justified. That matters because access sprawl almost always includes more than user accounts: privileged admins, service accounts, API keys, and other NHIs can retain reach long after the business reason has changed. NHI Management Group’s Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, which makes review quality a real compliance risk.

PCI DSS v4.0 expects organisations to prove that access is limited to approved identities and that removals happen in a timely way, not just that a review occurred. The practical test is whether the review can trace each identity to a current business need, an owner, and a remediation record. In practice, many security teams discover stale privileged and non-human access only after an audit sample fails or an incident exposes inherited permissions, rather than through intentional governance.

How It Works in Practice

effective access reviews for PCI DSS start with scope, not tooling. The review population should include all identities that can reach cardholder data environments, including employees, contractors, privileged administrators, application accounts, API keys, certificates, and secrets-backed workloads. Reviewers should confirm three things for each access path: who owns it, why it exists, and whether it still needs to exist. The review outcome should be explicit approval, reduction, or revocation, with evidence retained alongside the decision.

For operational consistency, many organisations tie the review to authoritative identity sources, entitlement catalogs, and ticketing records. That helps establish whether the account is human or non-human, whether it is privileged, and whether its permissions align with the current role or workload. For NHIs, the review should include rotation and offboarding checks, because a validated account can still be unsafe if the secret is long-lived or broadly reusable. NHI Management Group’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives is a useful reference for documenting that lifecycle view.

• Use a complete entitlement inventory before the review begins.
• Require asset owners to attest to business need, not just existence.
• Validate privileged access separately from standard user access.
• Record remediation evidence, including revocation timestamps and ticket IDs.
• Re-check NHIs for secret rotation, scope reduction, and orphaned ownership.

Auditors typically care less about the meeting itself than about the control path: whether review frequency is defined, whether exceptions are tracked, and whether denied or revoked access actually disappeared. Guidance from the PCI DSS v4.0 documentation and the NIST Cybersecurity Framework 2.0 both reinforce that governance only counts when it is operationalised through repeatable evidence. These controls tend to break down in CI/CD-heavy environments because service accounts and secrets change faster than periodic review cadences can track.

Common Variations and Edge Cases

Tighter access review rules often increase operational overhead, requiring organisations to balance audit confidence against remediation speed. That tradeoff is especially visible when the environment contains many NHIs, delegated admin paths, or dynamic cloud workloads. Best practice is evolving, but current guidance suggests that a single quarterly review may be too coarse for high-churn secrets and ephemeral workloads, even if it is still used for formal PCI evidence.

One common edge case is the “reviewed but not removed” problem. A reviewer may flag access as unnecessary, yet the entitlement remains because no one owned the follow-up action. Another is indirect access: an account may not hold cardholder data permissions directly, but it may reach systems that can pivot into the environment. For that reason, organisations should review inheritance, group membership, and machine-to-machine trust paths, not just direct grants. The Top 10 NHI Issues and Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs both support that lifecycle approach.

For third-party access, shared admin accounts, and automated workloads, there is no universal standard for review frequency beyond the PCI requirement itself, so organisations should set tighter intervals where the blast radius is larger. When access is issued through orchestration platforms or secrets managers, the review should include the source of authority as well as the active credential. That is the difference between a control that looks complete on paper and one that actually limits cardholder-data exposure.

Related resources from NHI Mgmt Group

• How should security teams run access reviews for non-human identities?
• When do NHI access reviews create more value than a one-time cleanup?
• How should organisations use AI agents in access reviews without losing governance control?
• When should organisations use entity-level isolation for access reviews?