PCI DSS scope is really an identity governance problem

At a glance

What this is: This article explains how PCI DSS scope is defined and reduced, and its key point is that scope depends on identifying every process, person, and technology that can touch or affect cardholder data.

Why it matters: For IAM practitioners, it shows that PCI scope is enforced through access reviews, segmentation, third-party oversight, and lifecycle controls, which are all identity problems as much as compliance problems.

👉 Read Zluri's guide to defining PCI DSS scope for your organisation

Context

PCI DSS scope is the boundary of systems, people, and processes that can store, process, transmit, or influence the security of cardholder data. If that boundary is wrong, every downstream control decision becomes unreliable, because teams end up protecting the wrong assets or missing connected systems that can still affect the cardholder data environment.

The article’s real value is not in restating compliance language. It shows how scoping depends on identity governance decisions, including who can reach payment systems, which third parties are trusted, and where access reviews must be tied to changes in system ownership or business process.

Key questions

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. Then include connected systems such as monitoring, backup, admin, and third-party services. If a component can change the security of the cardholder data environment, it belongs in scope until proven otherwise.

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. Payment gateways, outsourced IT, and vendor admin connections may still affect security, so scope has to cover delegated access, lifecycle offboarding, and change tracking across the relationship.

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. If connected systems, service accounts, or vendor users are missing from that model, the review gives false confidence and leaves real payment exposure untouched.

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.

Technical breakdown

How PCI DSS scope expands through connected systems

PCI DSS scope is not limited to the database or payment application that directly stores cardholder data. It also includes systems that connect to, administer, monitor, back up, or otherwise influence that environment, because indirect access can become a path to exposure. That is why a monitoring console, backup server, or shared admin platform may still be in scope even when it never handles card data directly. The practical challenge is boundary definition, not only control implementation. If connected systems are not catalogued, the compliance boundary becomes porous and audit assumptions collapse.

Practical implication: build a connection map that includes admin, backup, monitoring, and third-party pathways, not just the obvious payment stack.

Why access control and segmentation reduce PCI scope

The article treats segmentation and access restriction as scope reducers because they limit which identities and systems can reach cardholder data. In practice, network segmentation, firewalls, and role-limited access narrow the set of assets that inherit PCI obligations. The governance point is that least privilege only works when the access graph is accurate. If a user, service account, or vendor connection can move laterally into the cardholder data environment, the organisation has not really reduced scope. It has only hidden exposure behind architecture.

Practical implication: align network segmentation with identity segmentation so access paths into the cardholder data environment stay intentionally narrow.

Why PCI scope changes when workflows or vendors change

PCI scope is dynamic because payments, integrations, and outsourcing relationships change the set of systems and identities that can touch cardholder data. A new SaaS integration, payment gateway, or outsourced processor can silently bring new processes into scope, even if the business thinks the change is operational only. That makes scoping a lifecycle task, not a one-time project. Reviews must be repeated after system additions, vendor changes, and workflow redesigns, otherwise the documented boundary and the real boundary drift apart.

Practical implication: trigger scope reviews whenever vendors, workflows, or connected systems change, and tie them to access recertification.

Threat narrative

Attacker objective: The attacker’s objective is to reach cardholder data or payment processing systems and keep access long enough to extract sensitive payment information.

1. Entry occurs when an attacker reaches a payment-related system or connected component through weak application settings, exposed interfaces, or insufficiently segmented access paths.
2. Escalation follows when monitoring, logging, or access controls fail to detect or limit movement into the cardholder data environment.
3. Impact is the exposure or theft of cardholder data, often with prolonged dwell time when scoping and detection are both incomplete.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Access review without scope accuracy is compliance theatre. The article’s access review example is useful because it shows that certification only matters when the in-scope population is right. If a role, vendor, or service account is omitted from the scoping model, the review process will certify the wrong universe and miss the real risk. The implication is that recertification, offboarding, and scope definition must be governed together.

Connected-to-scope systems are where PCI programmes usually drift. The strongest insight in the article is that indirect links can still create material exposure, even when the system is not a primary payment processor. That means monitoring tools, backup platforms, and administration layers deserve the same governance attention as direct handlers of cardholder data. Practitioners should stop treating “not directly in CDE” as “not relevant to PCI.”

Scope reduction is only durable when lifecycle changes are controlled. Segmentation, tokenization, and outsourced processing reduce exposure, but they do not remove the need to re-evaluate identities and dependencies when business workflows change. The article shows why a payment boundary can widen again after a new integration or service provider is added. Practitioners should make PCI scope review part of change management, not a periodic afterthought.

Vendor access without lifecycle offboarding is the most common blind spot. The article repeatedly points to third parties as in-scope participants, which means access does not end when the contract or workflow changes unless governance does. This is the failure mode that turns a narrow payment boundary into a persistent exposure surface. Practitioners should enforce offboarding as a PCI control, not merely an IAM hygiene task.

From our research:

• 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.
• For a deeper lifecycle view, see NHI Lifecycle Management Guide for how provisioning, rotation, and offboarding control identity sprawl.

What this signals

Identity scope reviews will become a recurring control, not a compliance exercise. As payment architectures shift toward SaaS integrations and delegated access, the real risk is not only card data handling but unmanaged reach. Teams that can already see third-party OAuth connections and service-account paths will have a much cleaner PCI boundary than teams that still rely on annual inventory checks.

The practical signal for practitioners is that change management, access governance, and payment compliance are converging. If a new vendor, workflow, or support path can touch cardholder data, it needs to be treated as a scope event and not just an operational change.

A useful way to frame the programme is as scope drift: the point where the documented PCI boundary no longer matches the actual identity and system pathways. Once that happens, access reviews and segmentation controls lose credibility until the boundary is re-baselined.

For practitioners

• 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. Keep the map current as workflows and integrations change.
• 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.
• Offboard third-party access as soon as scope changes Revoke vendor accounts, API connections, and delegated access immediately when a payment integration ends or changes ownership, then verify the removal in logs and entitlement records.

Key takeaways

• PCI DSS scope is an identity and dependency problem, not only a data-location problem.
• Connected systems, third parties, and delegated access are the main reasons scope expands beyond the obvious payment stack.
• The most effective controls are continuous scope review, access recertification, segmentation, and immediate offboarding when relationships change.

Key terms

• Cardholder Data Environment: The cardholder data environment is the part of an organisation that stores, processes, or transmits payment card data, plus anything that can affect its security. In practice, it includes direct handlers and connected systems, such as monitoring, administration, backups, and third-party services.
• Connected-to-scope System: A connected-to-scope system does not directly handle card data, but it can still affect the security of the payment environment. These systems often include support tooling, shared infrastructure, or delegated services whose access paths or misconfigurations can widen PCI exposure.
• PCI Scope Drift: PCI scope drift happens when the documented payment compliance boundary no longer matches the real systems, identities, and workflows that can touch cardholder data. It usually appears after vendor changes, integrations, or operational updates that were not followed by a fresh scoping review.
• Scope Review: A scope review is the process of re-checking which systems, people, and services belong inside PCI DSS coverage after a change occurs. For identity teams, it should be tied to access recertification and offboarding so that the compliance boundary and actual access paths stay aligned.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Zluri: How to Define PCI DSS Scope for Your Organization? Read the original.