Ask any PCI DSS compliance vendor how their tool handles Cardholder Data Environment scope. You’ll get a confident answer. What you probably won’t get is an honest one.
CDE scope determination is one of the most consequential — and most frequently misrepresented — aspects of PCI DSS compliance. The scope defines which systems, networks, and processes fall within the assessment boundary. Get it wrong, and the entire compliance exercise is built on a false foundation. Undersell the scope and you have gaps a QSA will find. Oversell it and you’re paying to assess infrastructure that doesn’t touch cardholder data.
What PCI DSS v4.0.1 Actually Requires
PCI DSS Requirement 1.2.4 is direct: the organization must maintain a current diagram of all connections between the cardholder data environment and other networks, including any wireless networks. This is the CDE Data Flow Diagram (DFD). It is an operator-produced, operator-attested document. No infrastructure scanner can generate it for you.
The reason is straightforward: the DFD requires business-context knowledge that the infrastructure doesn’t encode. Which services process Primary Account Numbers (PANs)? Which databases store cardholder data? Which network segments are connected to those systems — and are therefore in-scope even if they don’t touch card data directly? These questions require a human with knowledge of the payment flows, the application architecture, and the data classification scheme to answer them.
Req 12.5.1 reinforces this: the organization must maintain an inventory of system components in scope for the PCI DSS, including a description of each component’s function. Again: operator-attested, not scanner-derived.
The Three CDE Scope Classes
Once the DFD exists, every system component falls into one of three scope categories:
Always in scope: systems that store, process, or transmit cardholder data directly — payment processing servers, card tokenization services, databases containing PANs or PADs (Primary Account Data).
CDE-conditional: systems connected to in-scope systems in ways that could affect their security — network segmentation controls, jump hosts, authentication infrastructure, key management systems. Whether these are in scope depends on segmentation effectiveness, which Requirement 11.4.5 requires annual penetration testing to verify.
Out of scope: systems with no connection path to the CDE — isolated development environments, unconnected corporate workstations, cloud services not reachable from payment infrastructure.
An infrastructure scanner can enumerate the systems it can reach. It can identify open network paths and segment boundaries. What it cannot do is answer the question “is this system in the CDE?” — because that question requires the DFD as input, and the DFD is not derived from infrastructure scanning.
Requirement 3: The Stored CHD Problem
Requirement 3 governs the protection of stored account data. It covers encryption of stored PANs (Req 3.5.1), rendering PANs unreadable (Req 3.4.1), protecting cryptographic key materials (Req 3.6.1), and prohibiting storage of sensitive authentication data post-authorization (Req 3.2.1, 3.3.x).
An infrastructure scanner can verify that a KMS key exists, that the key policy follows least-privilege principles, and that EBS volumes or RDS instances have encryption enabled. What it cannot verify is whether the encrypted data actually contains PANs. That determination requires the CDE attestation: only after the operator identifies which databases are in scope for Req 3 can the scanner’s findings about those databases carry Req 3 compliance weight.
This is why honest PCI DSS tooling marks Req 3 stored-CHD controls as CDE-conditional at the coverage layer and surfaces explicit operator-attestation requirements before treating any Req 3 finding as compliance-relevant evidence.
What Honest Per-Control Scope Classification Looks Like
NSAuditor AI Enterprise Edition 0.11.0 introduces a cdeScope field in its PCI DSS compliance mapping for every covered sub-requirement. Values are:
always-in-scope: the control applies to any infrastructure in the network perimeter (e.g., network security controls per Req 1, logging per Req 10)cde-only: the control’s compliance relevance depends on whether the assessed system is operator-attested as in the CDE (e.g., Req 3 stored CHD controls)cde-conditional: the control applies where network connectivity to the CDE exists but the scope boundary is operator-defined (e.g., Req 8 authentication controls)
Every scan report surfaces the Cardholder Data Scope section explicitly: what the scanner can and cannot determine, which sub-requirements require CDE attestation as a prerequisite, and where the operator must contribute the DFD to make the findings compliance-meaningful.
The Tokenization Consideration
Many payment architectures use tokenization to reduce CDE scope. If PANs are tokenized before reaching the merchant’s systems — using Visa Token Service, Mastercard MDES, or a payment gateway’s tokenization layer — the systems that only ever see tokens may be out of scope for most Req 3 sub-requirements.
But “may be” is doing a lot of work in that sentence. The tokenization platform must be assessed. The token-to-PAN detokenization path must be scoped. And the merchant must document the tokenization architecture in their DFD. Infrastructure scanning can verify that API endpoints use TLS (Req 4), that IAM policies restrict who can call the detokenization API (Req 7-8), and that logging captures who called it (Req 10). It cannot determine whether the tokenization architecture actually removes those systems from Req 3 scope without the operator’s data classification input.
The Honest Answer
The one question every PCI DSS vendor pretends to answer is: “Is this system compliant?” The honest answer, for most PCI DSS sub-requirements, is: “This system has the infrastructure controls in place. Whether those controls satisfy PCI DSS depends on your CDE scope attestation, your DFD, and your data classification — which only you can provide.”
That’s not a weakness in the tooling. It’s an accurate representation of what PCI DSS compliance actually requires. The vendors who pretend otherwise are setting their customers up for QSA findings that could have been anticipated and addressed before the assessment began.
NSAuditor AI Enterprise Edition 0.11.0 introduces PCI DSS v4.0.1 as its fourth compliance framework with per-control cdeScope classification and operator-attestation framing. Coverage documentation: nsauditor.com/ai/docs/pci/
