Start with a complete entitlement inventory across all in-scope systems, then route each account to the correct owner for validation. Prioritise accounts with broad privileges or no clear business owner, and close any access that cannot be justified immediately. The review is only useful when remediation happens as part of the same workflow.
Why This Matters for Security Teams
PCI DSS access reviews fail when teams treat them as a paperwork exercise instead of an entitlement integrity check. For in-scope systems, the question is not only who has access, but whether each account still has a business owner, a valid purpose, and the minimum privileges needed. The risk is amplified by orphaned accounts, stale shared access, and service credentials that are no longer tied to a current team or application change. NHI Mgmt Group notes that only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs, which helps explain why reviews often miss the highest-risk access paths.
For PCI environments, auditors care less about how many review attestations were collected and more about whether the organisation can prove that access was validated, remediated, and removed where unjustified. That requires a current inventory, named ownership, and a workflow that closes the loop on exceptions rather than deferring them. The PCI DSS v4.0 documentation makes clear that access control is not static, and review evidence must reflect actual enforcement. In practice, many security teams discover orphaned access only after a finding, because the review process was built around approvals rather than authoritative entitlement data.
How It Works in Practice
The most reliable review process starts with an entitlement inventory that covers all in-scope systems, including application accounts, admin users, shared access, API keys, and service identities. Each entry should be mapped to a business owner, a technical owner, and a system of record. Where ownership is missing, the account should be treated as suspect until proven otherwise. That approach aligns with the broader guidance in the Ultimate Guide to NHIs — Key Challenges and Risks, because excessive privilege and missing visibility are usually what turn routine reviews into audit failures.
In a PCI review cycle, teams should prioritise access that creates the most blast radius first:
- Privileged accounts with payment data access or security tooling access
- Accounts with no active owner, no recent use, or no clear business justification
- Shared accounts that cannot be traced to an individual or a controlled service function
- Third-party or vendor access that has not been reconfirmed against the current engagement
Validation should happen at runtime against current entitlements, not old spreadsheets. Where access cannot be justified immediately, it should be removed or disabled in the same workflow, then reintroduced only through a documented exception path. Current guidance suggests that reviewers should not rely on human memory to catch orphaned access, because stale accounts often look legitimate until a system migration, staff turnover event, or application retirement exposes the gap. The operational benchmark is simple: if an account cannot be tied to a current owner and purpose, it fails review by default. These controls tend to break down in large estates with multiple IAM sources and weak application ownership because entitlement data becomes fragmented faster than reviewers can reconcile it.
Common Variations and Edge Cases
Tighter access review rules often increase remediation workload, requiring organisations to balance audit speed against the operational cost of interrupting legitimate access. That tradeoff matters most in environments with outsourced support, shared admin pools, and legacy platforms that do not expose clean ownership metadata. In those cases, best practice is evolving, but the safest approach is still to reduce ambiguity rather than preserve it.
One common edge case is service and batch access that has no human approver. These accounts still need an accountable owner, but the review criteria should focus on task scope, rotation, and whether the credential is still needed at all. Another is temporary access granted for incident response or project work. If the entitlement was not given a time limit up front, it should be treated as orphaned until the business case is refreshed. Organisations should also distinguish between valid dormant access and genuinely abandoned access. A low-usage account is not automatically orphaned, but an account with no owner, no recent change history, and broad privileges is a strong candidate for removal.
For evidence, teams should retain the entitlement export, reviewer attestation, remediation record, and exception approval in the same case file. That makes the review defensible under PCI DSS v4.0 expectations and supports follow-up investigations. Where visibility is weak, start by improving the inventory rather than widening the reviewer group, because more approvers do not fix missing data.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while PCI DSS v4.0 and PCI DSS v4.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| PCI DSS v4.0 | 7.2.1 | Requires formal review of user access and justification for access. |
| PCI DSS v4.0 | 7.2.3 | Supports periodic access reviews to identify excessive or stale access. |
| OWASP Non-Human Identity Top 10 | NHI-05 | Orphaned service accounts and unused secrets are classic NHI governance failures. |
Inventory in-scope entitlements, validate each one against owner and purpose, and remove unjustified access during review.
