What is in your CDE, and what a scoping exercise produces

Two answers first. Your cardholder data environment is not the systems that touch a card number: PCI DSS v4.0.1 defines scope in three parts, and the third sits outside the CDE while staying fully in scope. And a scoping exercise does not produce a diagram. It produces a dated, retained document set the standard expects the assessed entity to produce — explicitly not the assessor.

The three sets

Section 4 of the standard. PCI DSS requirements apply to:

• The cardholder data environment (CDE), comprised of “system components, people, and processes that store, process, or transmit cardholder data and/or sensitive authentication data”, and “system components that may not store, process, or transmit CHD/SAD but have unrestricted connectivity to system components that store, process, or transmit CHD/SAD”;
• AND “system components, people, and processes that could impact the security of cardholder data and/or sensitive authentication data”.

The capitalised AND is the standard's. The second set is why a flat network puts everything in the CDE: unrestricted connectivity, not data handling, is the test. The third set is in scope and not in the CDE — the distinction most scoping arguments turn on.

What people are surprised to find inside the boundary

None is an edge case. Each is named in the standard's list of system components or in its scoping guidance.

• DNS and the e-commerce redirect, both named as systems that could impact the security of account data. A redirect server that never sees a PAN decides where the shopper's browser goes next.
• Your security stack — SIEM, MFA, anti-malware, badge access, CCTV. Controls protecting the CDE are in scope for protecting themselves.
• The segmentation devices. The internal firewall enforcing your scope reduction sits inside the scope it reduces.
• Backup and failover sites, which the scoping guidance tells you to consider by name.
• Code repositories and deployment tooling — anything “for deployment of objects to the CDE”. Your CI runner has a path in.
• Account data in any format — paper, data files, audio files, images, video. A call recording is storage. And all three sets read “system components, people, and processes”: a refund workflow is in scope in the same sentence as a server.
• Encrypted cardholder data, in most cases. “Encryption alone is generally insufficient to render the cardholder data out of scope.” It stays in scope on any system that also holds the decryption key, in the same environment as the key, or where a party with the key can reach it — as do the systems performing encryption, decryption and key management.

The only way out is the standard's own bar: a component out of scope “must be properly segmented (isolated) from the CDE, such that [it] could not impact the security of cardholder data and/or sensitive authentication data, even if that component was compromised”. Segmentation is not itself a PCI DSS requirement; it is a scope-reduction choice, and an untested one is an assertion until Requirement 11.4.5 tests it.

What a scoping exercise produces

Requirement 12.5.2 sets the minimum content, and it reads as a specification for a document rather than an activity. The scoping validation must include:

• All data flows for every payment stage — authorisation, capture, settlement, chargebacks, refunds — and every acceptance channel: card-present, card-not-present, e-commerce.
• Updated data-flow diagrams per Requirement 1.2.4, additional to and reconciling with the network diagram at 1.2.3.
• All locations where account data is stored, processed and transmitted — expressly including locations outside the currently defined CDE, and file backups.
• All system components in the CDE, connected to the CDE, or that could impact its security — the three sets above, enumerated.
• All segmentation controls in use and the environments they segment the CDE from, including justification for environments being out of scope.
• All connections from third-party entities with access to the CDE.
• Confirmation that every one of the above is in scope.

Requirement 12.5.1 adds a current inventory of in-scope system components with a description of function or use for each. The guidance suggests holding account data locations as a table: each store and its retention period, which CHD elements it holds, how they are secured, and how access is logged.

Two things follow. The documentation is retained — “to show how PCI DSS scope was determined” — for the assessor's review and for the next confirmation. And it is your work: the applicability note says this confirmation “is an activity expected to be performed by the entity under assessment, and is not the same, nor is it intended to be replaced by, the scoping confirmation performed by the entity's assessor”.

How often

“Significant change” is not left to taste: the standard lists six triggers, among them any change to the flow or storage of account data, to the boundary of the CDE, to supporting infrastructure such as directory services, time servers, logging and monitoring, or to the third parties supporting the CDE. Twelve months of ordinary change will hit several, which is why annual validation is a re-scope rather than a repeat.

Why remediation started before scoping is half wasted

Four mechanisms, in the order they bite.

You harden the wrong population. Sampling is a concession to assessors, not to entities: “it is not acceptable for an entity to apply PCI DSS requirements to only a sample of its environment”. The population is the 12.5.1 inventory. Remediation planned against an unconfirmed one spends on systems a segmentation decision would have removed, and skips the third set — the DNS server, the jump host, the SIEM — because nobody thinks of those as payment systems.

Scope reduction is an architecture decision with an expiry date. Cutting scope, the standard notes, “may require reengineering of long-standing business practices”. Once controls are bought, configured and evidenced across a flat network, the budget that would have paid for segmentation has gone on the consequence of not having it.

Data discovery moves the boundary retrospectively. The guidance anticipates PAN found “outside the currently defined CDE or in unexpected places within the defined CDE — for example, in an error log or memory dump file”. Each find either pulls a new system into scope, where completed remediation must be repeated, or triggers an elimination that makes some of it moot. A gap analysis run before the scope is settled measures a boundary about to move.

The testing requirements inherit their scope from this document. Requirement 11.4.1 requires the methodology to give “coverage for the entire CDE perimeter and critical systems” and “testing to validate any segmentation and scope-reduction controls”. A penetration test scoped to an unconfirmed boundary tests an assumption, and a scope narrower than the documented CDE is the first thing that gets a PCI penetration test report sent back.

The order that works is unglamorous: confirm the scope, decide what leaves it, remediate what remains, test the boundary you kept. Even which SAQ applies to you falls out of the same document. Once the boundary is documented and needs testing rather than describing, that is where Security Brigade's PCI DSS readiness and segmentation testing work begins.