Notifications
Clear all
Topic starter
12/06/2026 10:25 pm
TL;DR: Cardholder data protection depends on mapping people, systems, processes, and third parties to the cardholder data environment, with access control and segmentation doing most of the practical work, according to Zluri. That framing matters because scope drift is usually an identity and lifecycle failure, not just a network-design issue.
NHIMG editorial — based on content published by Zluri: How to Define PCI DSS Scope for Your Organization?
Questions worth separating out
Q: How should security teams define PCI DSS scope in practice?
A: Start with every system, process, and identity that stores, processes, transmits, or can influence cardholder data.
Q: Why do third-party integrations complicate PCI DSS scope?
A: Third-party services can create indirect paths into the cardholder data environment even when they do not process card data themselves.
Q: What breaks when access reviews are not aligned to PCI scope?
A: Access reviews certify only the identities that were included in the scoping model.
Practitioner guidance
- Define the cardholder data environment as an identity graph Map every human user, service account, vendor connection, admin console, backup system, and monitoring tool that can touch or influence cardholder data.
- Tie PCI scope reviews to access recertification Run a scope review whenever a business process, payment flow, or third-party integration changes, then recertify access for all in-scope identities before the new design goes live.
- Reduce inherited scope through segmentation and least privilege Separate payment systems from shared networks, restrict admin pathways, and remove unnecessary connectivity from backup, monitoring, and support tooling so fewer identities can reach cardholder data.
What's in the full article
Zluri's full article covers the operational detail this post intentionally leaves for the source:
- The step-by-step breakdown of how to map cardholder data flow across internal systems, backups, and third-party services
- Examples of scope reduction through network segmentation, tokenization, and point-to-point encryption in payment environments
- The access review workflow Zluri uses to identify and remediate risky permissions across in-scope applications
- The practical scoping checklist for keeping documentation current when systems or vendors change
👉 Read Zluri's guide to defining PCI DSS scope for your organisation →
PCI DSS scope and access reviews: what IAM teams miss?
Explore further
13/06/2026 1:10 am
PCI scope is fundamentally an identity boundary problem. The article correctly frames scope around systems, people, and processes, but the governing question is who or what can affect cardholder data, not just where the data sits. Once third parties, admin paths, and connected tools are included, the scope becomes an identity graph that must be maintained continuously. Practitioners should treat scoping as a control over reach, not a static inventory exercise.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared with nearly 1 in 4 for securing human identities.
A question worth separating out:
Q: Who is accountable when PCI scope expands after a system change?
A: Accountability sits with the teams that own the change, the payment environment, and the delegated access into it. PCI scoping should be embedded in change management, because new integrations, vendors, or workflows can extend the compliance boundary without anyone noticing.
👉 Read our full editorial: PCI DSS scope is really an identity governance problem
