How should security teams prepare for PCI DSS audits when access to cardholder data spans multiple systems?

Why This Matters for Security Teams

PCI DSS audits become difficult when cardholder data flows across apps, databases, pipelines, and service accounts because the auditor is not just testing whether access exists, but whether scope is accurate and controls are consistently enforced. The risk is amplified by non-human identities, which often outnumber human identities by 25x to 50x in modern enterprises, according to the Ultimate Guide to NHIs.

That matters because a single overlooked API key, integration token, or shared service account can create an undocumented path into cardholder data environments. Current guidance in PCI DSS v4.0 expects organisations to prove control ownership, access restriction, and evidence quality, not just describe the architecture. In practice, many security teams encounter scope disputes only after evidence collection has already started, rather than through intentional PCI boundary mapping.

How It Works in Practice

Preparation starts with a system-by-system map of every place cardholder data is stored, processed, or transmitted, then a second map of every identity with access to those systems. That includes people, service accounts, API keys, CI/CD runners, and any agentic workflow that can reach cardholder data. The practical goal is to align the PCI scope with the real access graph, not the org chart.

For human identities, teams should be able to show role assignment, approval history, and periodic review evidence. For NHIs, they need a lifecycle view that covers issuance, ownership, rotation, offboarding, and secret storage. The Ultimate Guide to NHIs — Regulatory and Audit Perspectives is useful here because it frames NHI controls in terms auditors can actually test. Pair that with the OWASP Non-Human Identity Top 10 to identify the most common failure modes: excessive privilege, weak rotation, hidden secrets, and poor visibility.

• Define a single authoritative scope statement for each cardholder data flow.
• List every identity, including machine identities, that can touch the scoped systems.
• Match access review evidence to the exact system and identity, not a general control domain.
• Preserve scan results, remediation tickets, and retest evidence for each in-scope component.
• Document any compensating controls where legacy systems cannot be changed quickly.

Using the Ultimate Guide to NHIs — Key Research and Survey Results, security teams can also justify why NHI inventory must be part of audit prep: only 5.7% of organisations have full visibility into their service accounts, which makes evidence gaps likely unless discovery is deliberate. These controls tend to break down when cardholder data moves through ephemeral cloud services and shared automation layers because ownership, logging, and rotation evidence are fragmented across too many consoles.

Common Variations and Edge Cases

Tighter scope control often increases operational overhead, requiring organisations to balance audit precision against engineering speed. That tradeoff becomes visible when cardholder data sits in hybrid estates, third-party processors, or shared platform services where one identity may support multiple business units.

Best practice is evolving for these environments, especially where service meshes, secrets managers, and automated deployment pipelines create indirect access paths. There is no universal standard for this yet, but teams should avoid assuming that a tool boundary equals a PCI boundary. A database in one cloud account, an app in another, and a shared token in CI/CD can still form one audit problem if the same credential chain can reach cardholder data.

One useful signal is whether the organisation can answer, for each in-scope system, who approved access, when it was last reviewed, and how quickly that access can be revoked. If the answer depends on tribal knowledge, the audit will likely surface gaps. The Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is especially relevant where long-lived secrets, stale integrations, or outsourced operations make revocation slow. In those cases, scope documentation and evidence discipline matter more than a perfect technical architecture.

Related resources from NHI Mgmt Group

• How should security teams prepare access governance for SOX 404(b) audits?
• How should security teams govern access when sensitive data is spread across multiple systems?
• How should security teams use ISO 27001 alongside SOC 2, HIPAA, and PCI DSS?
• How should security teams implement access reviews for PHI systems?