PCI scoping: identifying your cardholder data environment
By Sam Rivera, Founder, SentinelPanda · February 25, 2026 · 3 min read · PCI DSS
The PCI requirements only apply to systems in scope. Defining scope is the first and most consequential decision in any assessment, and the easiest one to get wrong.
What is in the CDE
The cardholder data environment is the set of systems that store, process, or transmit cardholder data or sensitive authentication data. Cardholder data is the Primary Account Number, plus cardholder name, service code, and expiration date when stored alongside the PAN. Sensitive authentication data — the full track contents, CVV/CVV2, and PIN/PIN block — must never be stored after authorisation.
Any system that handles those data elements, even briefly, is in the CDE. That covers the obvious (payment-page server, payment gateway integration, transaction database) and the less obvious (log aggregation if logs contain PANs, support tooling that surfaces transaction details, BI tools that query a payments warehouse).
Connected-to systems
PCI scope does not stop at the CDE itself. Systems that connect to the CDE — even without holding cardholder data directly — are also in scope. That includes identity and access management systems that provision access into the CDE, monitoring and logging systems collecting from the CDE, backup systems handling CDE snapshots, and administrative bastions used to operate the CDE.
The standard's logic: if a connected system is compromised, the attacker has a foothold from which to attack the CDE. Connected-to systems carry full PCI obligations.
Out of scope — what segmentation actually requires
Systems can be put out of scope through segmentation: technical controls that prevent communication between the segmented systems and the CDE. Segmentation is not "we drew a network diagram showing two segments." It is a set of enforced controls — firewalls, VLAN isolation, separate authentication domains, deny-by-default rules — that you can demonstrate and test.
Service providers must test segmentation every six months and merchants annually (Req 11.4.5 and 11.4.6). The test is an active, evidenced attempt to traverse the segmentation boundary; if traffic crosses, the segmentation has failed and the previously out-of-scope systems are in scope.
Common scoping mistakes
- Treating "we use a hosted payment page" as automatically SAQ A without checking whether your site can affect the page's integrity (iframe, redirect, direct-post all have different scopes).
- Forgetting that log destinations that receive CDE logs containing PAN fragments are in scope.
- Ignoring support tooling and back-office systems that can read transaction data.
- Treating a "DMZ" with permissive firewall rules as out-of-scope segmentation.
- Architecture drift since the last scope review — new microservice that quietly joined the CDE last quarter.
Documenting scope (Req 12.5.2)
The Scope Statement is a versioned, change-controlled document that captures what is in the CDE, what is connected to it, what is out of scope, and how the boundary is enforced. It is reviewed at least annually and after any significant change to the environment.
A good Scope Statement reads like an architecture document, not a checklist. It includes data flow diagrams, network diagrams, the list of in-scope systems with owners, and the segmentation evidence. An assessor reading it should be able to reach the same conclusions you did about applicability.