Cardholder data

Expanded Definition

Cardholder data is more than payment card numbers at rest. In PCI DSS practice, it includes the data elements that determine whether a system is in scope, how it must be segmented, and which identities can touch it. That makes the term operational, not just descriptive. The boundary typically includes the primary account number, and may extend to related authentication and transmission controls depending on where the data flows and who can access it. The PCI Security Standards Council’s PCI DSS v4.0 remains the core reference, but implementation details vary across payment environments, especially when modern workloads use APIs, containers, and service identities.

For NHI governance, the key issue is that cardholder data scope is enforced through machine access as much as through human access. Service accounts, API keys, and CI/CD pipelines often become the pathways that move or expose payment data. NHI Management Group research shows that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is why payment-data scope must include machine identity review. The most common misapplication is treating cardholder data scope as a storage problem, which occurs when teams ignore the identities and integrations that can read, route, or log payment data.

Examples and Use Cases

Implementing cardholder-data controls rigorously often introduces operational friction, requiring organisations to weigh transaction flow speed against tighter identity, logging, and segmentation controls.

• A payment gateway service account pulls authorisation data from an application queue, so the queue, the service account, and the downstream logs all become part of the cardholder-data control review.
• A CI/CD pipeline accidentally injects test credentials into a production deployment, and the resulting release must be assessed for whether it exposed cardholder data in code, logs, or transient storage.
• A merchant uses a tokenisation service, but the token vault still exchanges data with a fraud-scoring API, making the API key and its rotation process part of the PCI evidence set.
• An analytics job reads masked payment records from a data lake, and the access policy must prove that the job cannot reconstruct or export cardholder data outside approved workflows.
• In breach response, teams map which NHIs had access to cardholder systems using lessons from the Ultimate Guide to NHIs — Key Research and Survey Results, then compare those paths to the PCI DSS v4.0 scope definition.

Why It Matters in NHI Security

Cardholder data becomes a security issue whenever machine identities are allowed to move it without strong governance. NHI Management Group’s research shows that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, which increases the chance that systems handling payment data are reachable through leaked credentials. That matters because cardholder-data scope is not static: when a secret is exposed, the associated service account, pipeline, or integration can instantly widen the attack surface.

This is also why payment environments need more than endpoint hardening. The right question is not only where the data sits, but which non-human identities can retrieve it, transmit it, or leave it in logs. The same research notes that only 5.7% of organisations have full visibility into their service accounts, a gap that directly affects PCI evidence and incident response. Organisations typically encounter the real cost of cardholder-data mismanagement only after a breach, failed audit, or emergency containment event, at which point identity scope becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Who is accountable when a machine identity exposes cardholder data?
• How should organisations govern access to cardholder data when service accounts are involved?
• Cardholder Data Environment
• Cardholder-Data Scope