Who is accountable for PCI DSS access and audit evidence?

Why This Matters for Security Teams

PCI DSS access and audit evidence are not just compliance artifacts; they are proof that payment-scope access is controlled, reviewed, and remediated by the right owners. Accountability matters because audit failures usually come from gaps between IAM, application teams, and evidence collectors, not from the standard itself. Guidance in PCI DSS v4.0 expects organisations to show traceable control ownership, while NHI governance research from Ultimate Guide to NHIs — Regulatory and Audit Perspectives shows that evidence is only useful when it ties back to lifecycle controls, not ad hoc screenshots.

That distinction matters because access reviews, offboarding, and remediation often sit in different queues, and each queue can fail quietly if nobody owns the full control outcome. The most common mistake is assigning evidence gathering to compliance alone, then discovering that no operational team can attest to the accuracy of the underlying access data. In practice, many security teams encounter control drift only after an assessor asks for defensible evidence, rather than through intentional review.

How It Works in Practice

Accountability should follow the control, not the calendar. Security usually owns the control design, IAM owns identity data and access enforcement, application owners own scope and business justification, and system or platform owners often own the technical evidence source. For PCI DSS, that means the people who can approve, revoke, and verify access must also be able to explain the evidence trail. The control objective is stronger when evidence comes from authoritative systems of record instead of manually assembled documents.

A practical model is to assign a named control owner for each evidence stream, then map that owner to the relevant PCI requirement and review cadence. For example, access review evidence should show who approved, who executed remediation, and when the change was validated. Offboarding evidence should show revocation completion, not just a ticket closure. This aligns well with NIST Cybersecurity Framework 2.0, which emphasizes governance and accountability, and with the NHI lifecycle approach described in NHI Lifecycle Management Guide.

• Security defines the evidence standard and escalation path.
• IAM provides the authoritative access records and review logs.
• Application owners confirm whether access still matches business need.
• Operations or platform teams preserve logs, timestamps, and retention.
• Compliance validates completeness, but does not own the control outcome alone.

Where organisations go wrong is treating evidence as a retrospective paperwork exercise. The better pattern is to generate audit-ready artifacts from the workflow itself, using ticketing, access governance, and logging systems that already record who approved what and when. These controls tend to break down when payment-scope access is spread across legacy apps, contractors, and shared service accounts because ownership becomes ambiguous and evidence loses traceability.

Common Variations and Edge Cases

Tighter accountability often increases coordination overhead, requiring organisations to balance audit defensibility against operational speed. That tradeoff is real in M&A environments, outsourced support models, and shared platform teams, where one group may manage identity tooling while another controls the protected application. In those cases, best practice is evolving toward a single accountable owner with delegated task ownership, rather than shared accountability with no clear decision-maker.

Evidence ownership also changes when non-human identities are involved. Service accounts, API keys, and automation tokens can create audit gaps if nobody owns their lifecycle or can prove timely revocation. NHIMG research shows that only 20% of organisations have formal offboarding and revocation processes for API keys, and that gap is directly relevant to PCI scope control. The broader risk is captured in Ultimate Guide to NHIs — Key Challenges and Risks and the OWASP Non-Human Identity Top 10, which both highlight how weak identity ownership turns into weak evidence.

For assessors, the key question is not who collected the report, but who can attest that the report reflects reality. If that answer is unclear, accountability has already failed.

Related resources from NHI Mgmt Group

• Who is accountable when PCI DSS access controls fail?
• Who is accountable when audit evidence shows access was not removed?
• How should security teams reduce SaaS access review overhead without losing audit evidence?
• How should organisations prepare IAM evidence for a PCI DSS assessment?