PCI DSS scope is really an identity governance problem

At a glance

What this is: This is a PCI DSS scoping guide that frames scope as the set of people, processes, systems, and third parties that can affect cardholder data security.

Why it matters: It matters because IAM, IGA, and PAM teams often control the boundaries that decide what is in scope, what is connected to scope, and how quickly scope drift is corrected.

Context

PCI DSS scope is the boundary around every person, process, system, and third party that can store, process, transmit, or influence cardholder data. In practical terms, scope is not just a network diagram, because identity access, connected systems, and lifecycle gaps can all expand the cardholder data environment.

The article argues that scoping is where compliance and governance meet. That makes it an IAM and IGA problem as much as a payment security problem, because access reviews, entitlement control, third-party access, and change tracking determine whether the environment stays contained or drifts outward.

Key questions

Q: What breaks when PCI DSS scope is not mapped to access and lifecycle controls?

A: The boundary becomes a paper exercise. Systems that connect to cardholder data, accounts with lingering privileges, and third-party access paths can all expand the cardholder data environment without anyone formally noticing, which is how organisations end up auditing the wrong assets and missing the real risk.

Q: When should organisations re-run a PCI DSS scoping review?

A: They should re-run it whenever a new application, vendor, workflow, or integration can change who can reach cardholder data or where it flows. Scope is dynamic, so any material change in access paths, data movement, or supporting systems can invalidate the previous boundary.

Q: What are the signs that PCI DSS scope is drifting?

A: Common signals include undocumented backup locations, broad admin access, unreviewed third-party connections, and systems that were declared out of scope but still connect to in-scope tools. If teams cannot explain why an account or system remains necessary, scope has probably expanded beyond policy.

Q: How should organisations use access reviews to support PCI DSS compliance?

A: Use access reviews to prove that only approved identities can reach cardholder data, and that revocation happens when access is no longer needed. The review process should include users, privileged accounts, and non-human identities, with remediation evidence stored alongside the decision so auditors can verify the full control path.

Technical breakdown

How PCI DSS scope expands through connected systems and people

PCI DSS scope includes direct cardholder data systems and anything that can influence them, which is why backup servers, monitoring tools, admin consoles, and third parties can become relevant even when they do not process card data themselves. The operational issue is not only where data sits, but where administrative trust and technical connectivity extend into the cardholder data environment. That is why “out-of-scope” often becomes conditional rather than absolute in real environments.

Practical implication: map every system and role that can touch the cardholder data environment, not just the systems that store card data.

Why access control and segmentation do most of the scoping work

The article repeatedly ties scope reduction to limiting who and what can reach cardholder data. Segmentation reduces the number of connected systems, while access control limits which users, admins, and service providers can interact with in-scope assets. In identity terms, scope is controlled by entitlement boundaries, not by policy language alone. If privileged access is broad or stale, the scoping boundary is already weak even when the network looks separated.

Practical implication: review privileged access and segmentation together, because one weak control can expand the effective PCI boundary.

How lifecycle changes create scope drift

Scope is not static. New applications, new integrations, new vendors, and changed business processes can move systems into scope even when the original documentation still says otherwise. That makes joiner-mover-leaver discipline, recertification, and change management part of PCI scope governance. The governance failure is not only missing a system, but failing to re-evaluate whether a person, process, or third party still belongs inside the boundary after change occurs.

Practical implication: trigger PCI scoping review whenever access, integrations, or third-party relationships change.

Threat narrative

Attacker objective: The objective was to access payment transaction data and steal customer card details from the payment environment.

1. Entry began when attackers exploited an SQL injection weakness in Heartland's payment processing environment, gaining a foothold in systems tied to cardholder data.
2. Credential or control abuse persisted because the environment lacked properly configured application controls and effective intrusion detection and monitoring, allowing the compromise to continue unnoticed.
3. Impact followed when attackers remained inside the system for months and exposed customer card details across the payment transaction environment.

Breaches seen in the wild

• Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

PCI DSS scope is an identity governance boundary, not just a network boundary. The article’s strongest point is that people, processes, systems, and third parties all contribute to whether cardholder data stays contained. That means scoping work belongs in IGA and access governance, not only in network engineering. Practitioners should treat PCI boundary design as a governance exercise with identity controls at the centre.

Connected-to-scope systems are where organisations usually underestimate exposure. The article shows that monitoring tools, backup servers, admin consoles, and outsourced services can influence cardholder data security even without direct processing. That creates a wider governance obligation than many compliance teams expect. The practical conclusion is that entitlement review must extend beyond obvious payment systems to adjacent control-plane access.

Access reviews are the operational control that keeps PCI scope honest. Zluri's examples show that the boundary erodes when access is left broad, stale, or poorly evidenced. In PCI terms, scoping is only credible when organisations can prove who can reach in-scope assets and why that access still exists. The implication is that access certification becomes a compliance control, not an administrative clean-up task.

Scope drift is a lifecycle problem disguised as compliance drift. New systems, vendor changes, and process changes can silently pull more of the environment into PCI scope. That is why scoping must be tied to change events, not annual audit cycles alone. Practitioners should treat every material integration, vendor onboarding, or role change as a boundary-review trigger.

Controlled access boundary: PCI DSS becomes manageable when organisations define and maintain the smallest defensible set of identities and systems that can influence cardholder data. That concept connects segmentation, entitlement control, and third-party governance into one operating model. Teams that cannot explain the boundary in access terms will struggle to defend it in audit terms.

What this signals

PCI DSS scope work is most reliable when identity governance and segmentation are assessed together. A clean network design does not help if stale admin rights, vendor credentials, or shared service accounts still reach the cardholder data environment.

Controlled access boundary: the phrase captures the real operating model behind PCI scoping, where only a small and well-governed set of identities should be able to influence cardholder data. That model becomes fragile as soon as change management and recertification fall out of sync with system integrations.

For practitioners

• Map cardholder-data touchpoints across identity and infrastructure Document every person, process, application, backup, admin path, and third party that can store, process, transmit, or influence cardholder data. Use the map to separate direct CHD handling from adjacent systems that only connect into the environment.
• Re-certify access for connected-to-scope systems Include monitoring tools, backup servers, admin consoles, and service-provider accounts in recurring access reviews. If a system can influence CHD security, its access should be reviewed on the same governance cycle as in-scope systems.
• Tie scoping reviews to change events Trigger a scope reassessment when new applications, integrations, vendors, or business processes are introduced. Update documentation immediately so the PCI boundary reflects current access paths rather than last quarter's architecture.
• Reduce scope through entitlement minimisation Limit access to payment systems to only the users and service accounts that truly need it, then segment the network so those identities cannot reach unrelated systems. Fewer reachable assets mean fewer systems that inherit PCI obligations.
• Validate third-party reach into the CDE Review how payment gateways, cloud hosts, and outsourced IT providers authenticate, administer, and troubleshoot in-scope systems. Third-party access should be justified, time-bounded, and revoked when the relationship or task ends.

Key takeaways

• PCI DSS scope is defined by the identities, systems, and third parties that can influence cardholder data, not by a single network control.
• Connected systems and delegated access are where scope usually expands, especially when access reviews and change tracking are weak.
• The practical fix is to govern PCI scope like an identity boundary, with segmentation, recertification, and third-party access controls working together.

Key terms

• PCI DSS Scope: PCI DSS scope is the set of systems, people, processes, and data flows that can store, process, or transmit cardholder data, or that can affect the security of that environment. It defines what must be assessed and controlled under the payment card security standard, including connected infrastructure and administrative access paths.
• Cardholder Data Environment: The cardholder data environment is the set of systems, users, and processes that store, process, or transmit payment card data. For NHI governance, it includes every machine identity that can influence those systems, even when the identity itself is invisible to end users.
• 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.
• Scope drift: Scope drift is the gradual mismatch between what an integration was meant to do and what its credentials still allow it to do. It happens when permissions are not revalidated as business needs change, creating hidden over-privilege across SaaS and API-connected systems.

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 building or maturing an IAM programme, it is worth exploring.