Spreadsheet-driven PCI access reviews usually break on evidence integrity, timing, and completeness. They cannot reliably prove who reviewed which account, when the review happened, or whether revocations were actually executed. That makes it hard to satisfy QSA scrutiny, especially when the CDE includes multiple systems and service accounts.
Why This Matters for Security Teams
PCI access reviews are meant to prove that access to the cardholder data environment is reviewed, justified, and removed when no longer needed. When that process lives in spreadsheets, the evidence chain becomes fragile: formulas are easy to break, timestamps are inconsistent, and approvals can be separated from the actual revocation work. That creates a gap between “reviewed on paper” and “remediated in practice.”
This is especially risky where service accounts, API keys, and other non-human identities are part of the CDE. NHIMG notes that only 5.7% of organisations have full visibility into their service accounts, and the Ultimate Guide to NHIs — Regulatory and Audit Perspectives shows why that lack of visibility becomes an audit problem fast. Spreadsheets can track tasks, but they do not establish control enforcement. For broader identity risk context, the OWASP Non-Human Identity Top 10 is a useful benchmark for the failure modes auditors now expect teams to understand.
In practice, many security teams discover review gaps only after a QSA asks for proof that a stale account was actually revoked, rather than through intentional control testing.
How It Works in Practice
A defensible PCI access review process needs more than an ownership spreadsheet. It needs a workflow that ties each account to an authoritative source, records the reviewer’s decision, preserves the evidence, and confirms that any removal or downgrade action completed successfully. The relevant control objective is not just review cadence, but traceability from review to enforcement.
In mature programs, the review output should map directly to a ticketing or access governance system so that every decision has a unique identifier, reviewer identity, date, scope, and remediation status. For non-human identities, this matters even more because accounts may not be owned by a single person in the way a user account is. NHIMG’s NHI Lifecycle Management Guide is explicit that lifecycle controls only work when provisioning, rotation, review, and offboarding are treated as one continuous process. That aligns with the intent of the NIST Cybersecurity Framework 2.0, which expects repeatable, evidence-backed governance rather than ad hoc documentation.
- Use an authoritative inventory of all PCI-scoped human and non-human accounts.
- Bind each review item to a system of record, not a manually edited worksheet.
- Capture reviewer attestation, rationale, and remediation outcome in a tamper-evident log.
- Verify revocations, not just approvals, and retain proof of execution.
- Reconcile spreadsheet output against actual IAM and PAM states before the audit window closes.
NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs reinforces that lifecycle automation reduces the evidence gap by making review and revocation part of the same control path. These controls tend to break down when PCI scope spans multiple legacy systems and shared service accounts because ownership, approval, and execution are split across tools with no single source of truth.
Common Variations and Edge Cases
Tighter access review controls often increase operational overhead, requiring organisations to balance auditability against reviewer workload and system integration effort. That tradeoff becomes more visible in environments with multiple business units, outsourced administrators, or shared infrastructure teams.
There is no universal standard for whether a spreadsheet is always unacceptable as a supporting artifact, but current guidance suggests it should not be the control system of record. A spreadsheet can help coordinate a review cycle, yet it should not be the place where decisions, approvals, and revocation evidence live. In mixed environments, teams often keep a spreadsheet only as a reconciliation layer while the real evidence resides in IAM, PAM, ticketing, and log systems.
Edge cases usually appear when the CDE includes service accounts that are exempt from human review cadences but still require periodic attestation, or when offshore support teams make revocation difficult to validate quickly. NHIMG’s 52 NHI Breaches Analysis and Ultimate Guide to NHIs — Key Challenges and Risks both reinforce a practical point: if the process cannot prove who acted, what changed, and whether the change stuck, then the review may satisfy a spreadsheet checklist but not a PCI control objective.
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 surface, NIST CSF 2.0 set the technical controls, and PCI DSS v4.0 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| PCI DSS v4.0 | 7.2.4 | Requires periodic access reviews and validation of least privilege. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions should be managed and reviewed consistently across assets. |
| OWASP Non-Human Identity Top 10 | NHI-03 | NHI lifecycle and credential governance are central when PCI scope includes service accounts. |
Inventory non-human identities and enforce review, rotation, and offboarding with auditable evidence.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
