Cardholder-data scope is the set of systems, identities, integrations, and controls that can store, process, or transmit payment data. The scope is not only technical infrastructure. It also includes the human and non-human identities that can influence those systems and therefore affect PCI obligations.
Expanded Definition
Cardholder-data scope defines every system, identity, integration, and control boundary that can store, process, or transmit payment card data under PCI expectations. In practice, that scope also extends to the service accounts, API keys, automation pipelines, and agentic workflows that can touch in-scope systems, because access paths matter as much as servers. That is why NHI Management Group treats scope as an identity and control problem, not only a network diagram. For a useful technical frame, practitioners often map scope to the system boundary concepts used in the PCI Security Standards Council ecosystem, then layer identity governance on top. This distinction matters because a narrowly drawn infrastructure boundary can still be invalid if an overlooked integration or secret can reach payment data. Guidance varies across vendors on where “connected” becomes “in scope,” so organisations should document the rationale for every inclusion decision.
The most common misapplication is treating a PCI boundary as only the production payment application, which occurs when service accounts, CI/CD credentials, and third-party integrations are excluded from scope reviews.
Examples and Use Cases
Implementing cardholder-data scope rigorously often introduces discovery and control overhead, requiring organisations to weigh audit simplicity against the cost of mapping every identity that can influence payment data.
- A payment microservice is clearly in scope, but so is the CI/CD service account that deploys it if that identity can change code or configuration in production.
- A secrets manager storing API keys for a billing gateway is in scope when those credentials can retrieve or submit cardholder data, even if the secrets manager is physically separate from the payment app.
- A vendor integration that tokenises card data may be partially out of scope for storage, yet still in scope for transmission paths and access controls if it can route transactions.
- An incident response runbook includes a compromised non-human identity because the same key used for reconciliation could expose transaction logs or settlement records; see NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks.
- A security architect uses the OWASP Non-Human Identity Top 10 to identify where excessive privileges or leaked secrets expand cardholder-data scope beyond the application boundary.
In practice, teams often discover that a “simple” billing environment contains multiple hidden scope extenders, such as automation tokens, observability agents, and support tooling.
Why It Matters in NHI Security
Cardholder-data scope is one of the fastest ways to surface whether NHI governance is real or merely documented. If an organisation cannot explain which service accounts, tokens, and external integrations can affect payment data, it cannot reliably prove least privilege, segmentation, or separation of duties. That is especially important because NHIMG research shows that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which makes hidden scope a direct security issue, not just an audit concern. From a governance perspective, the scope definition drives evidence collection, access reviews, secret rotation, and compensating controls for any identity that can reach payment systems. It also shapes how teams respond to architecture changes, because a new integration can instantly enlarge PCI obligations even when no new server is added. Organisations typically encounter the operational cost of mis-scoping only after a failed assessment, a breach investigation, or an access review that exposes undocumented identities, at which point cardholder-data scope becomes operationally unavoidable to address.
For deeper NHI governance context, review NHIMG’s Key Challenges and Risks alongside the survey findings in Key Research and Survey Results, then map the resulting identities to PCI controls and compensating safeguards.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack surface, NIST CSF 2.0 set the technical controls, and PCI DSS v4.0 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| PCI DSS v4.0 | 1.2.3 | Defines and constrains the cardholder data environment boundary and connected systems. |
| OWASP Non-Human Identity Top 10 | NHI-02 | Secret exposure and over-privileged NHIs often expand cardholder-data scope. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions and least-privilege controls are central to limiting in-scope identities. |
Inventory non-human identities and secrets that can access payment systems, then reduce their scope and privilege.
