How should organisations prepare IAM evidence for a PCI DSS assessment?

Why This Matters for Security Teams

PCI DSS assessors do not only want to see that access was limited. They want evidence that access decisions were controlled, reviewed, and traceable across the full lifecycle. That means identity owners, approvers, dates, exceptions, remediation, and monitoring logs must line up. For NHI-heavy environments, this is harder than it looks because service accounts, API keys, and workload tokens are often created outside standard joiner-mover-leaver processes.

The assessment burden is tied to control design, not just policy language. A team can have a strong access model on paper and still fail if it cannot demonstrate who approved a privilege change or how a stale entitlement was removed. Guidance in the PCI DSS v4.0 materials makes this evidentiary expectation clear: controls must be both in place and provable. NHI Management Group’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives highlights why that is difficult in practice, especially where secrets, service accounts, and third-party access expand faster than review workflows.

In practice, many security teams discover evidence gaps only after an assessor asks for a complete trail from entitlement to approval to remediation, rather than through deliberate audit rehearsal.

How It Works in Practice

Effective PCI evidence preparation starts with building a repeatable evidence pack for each in-scope identity type: human users, privileged admins, service accounts, API keys, and application tokens. The pack should show the control objective, the operating procedure, and the artefacts that prove both were followed. For access reviews, that usually means review rosters, reviewer sign-off, exceptions, and remediation tickets. For provisioning, it means approvals, timestamps, scope of access, and any time-bound expiry logic. For monitoring, it means logs that show access use and alerting on misuse or drift.

For NHI governance, the strongest evidence usually comes from systems that enforce lifecycle controls automatically. If a workload identity is issued for a task, the organisation should be able to show the request context, the approval path, the short-lived credential issuance, and the revocation event. The 2024 Non-Human Identity Security Report notes that 88.5% of organisations say NHI practices lag human IAM, which is why assessors often see fragmented screenshots instead of a defensible trail. The operational goal is to connect the policy to the system of record and then to the control evidence.

• Map each PCI control to a named evidence owner and an evidence source.
• Use dated exports from IAM, ticketing, SIEM, and vault systems rather than manual summaries.
• Preserve approval records, reviewer comments, and exception approvals with retention aligned to the assessment period.
• Document how revoked access is verified, not just requested.
• Keep samples consistent so the assessor can trace one entitlement across its full lifecycle.

Where possible, align evidence capture with the same controls used for privileged access and secrets management, including findings from the JetBrains GitHub plugin token exposure research and the PCI Council’s own PCI DSS v4.0 documentation. These controls tend to break down when access is granted in ad hoc CI/CD paths because approvals, revocations, and logs are split across systems with no common identifier.

Common Variations and Edge Cases

Tighter evidence collection often increases operational overhead, requiring organisations to balance assessor readiness against team effort and system complexity. That tradeoff is especially visible when access is dynamic, temporary, or managed outside a central IAM tool.

Current guidance suggests treating exceptions as first-class evidence, not as informal notes. If a legacy application cannot support per-user attribution, the organisation should document compensating controls, owner approval, and the review cadence. If third-party administrators or managed service providers touch in-scope systems, the evidence package should include contract scope, access boundary, and review records, not just internal IAM exports. For NHIs, there is no universal standard for proving ephemeral access maturity, but best practice is evolving toward short-lived credentials, workload identity, and policy-as-code records that can be recreated during audit.

Assessments often become more difficult where the evidence source is a secrets vault, cloud control plane, or pipeline system rather than a traditional IAM directory. The main risk is that the team can prove access existed, but not that it was approved, monitored, and removed on time. That is why audit preparation should include sample testing before the formal assessment and a clear owner for each evidence type. Organisations that rely on manual screenshots or email approvals usually spend the most time reconstructing history after the fact.

Related resources from NHI Mgmt Group

• How should organisations decide whether appsec, IAM, or platform teams own a control failure?
• How do organisations know whether IAM observability is actually working?
• How can organisations connect community education to IAM outcomes?
• How can organisations tell whether IAM governance is actually improving?