How to Scope Your Cardholder Data Environment Correctly

A DNS server can be left out of scope even when it connects to systems handling card data. Scoping is the first step in a PCI DSS assessment, and errors here can be costly. Systems are often excluded because they do not store primary account numbers, without considering whether they connect to or can affect systems that do. PCI DSS scope follows connectivity and impact, not only where PANs reside.

How PCI DSS Defines CDE Scope

The cardholder data environment includes people, processes, and technology that store, process, or transmit cardholder data or sensitive authentication data. The definition is simple. Complexity begins with connected system components, meaning infrastructure, virtualization components, or applications connected to the CDE or providing support services to it.

A system does not need to handle card data to be in scope. Network connectivity to a CDE system makes it a connected system component. Unless those connections are properly restricted and segmented, the system inherits in-scope status and applicable DSS requirements. This causes many QSA scoping disputes. Merchants often include card-handling systems but omit supporting infrastructure with unrestricted access to them.

For each system, ask not only whether it touches card data, but whether it could affect card data security directly or indirectly. Evaluate DNS servers, authentication services, configuration management servers, log aggregators, monitoring tools, and patch management infrastructure against that question.

Three PCI DSS Scoping Categories

A practical scoping analysis puts each system into one of three categories.

Category one covers systems that directly store, process, or transmit cardholder data. They are always in scope and subject to all applicable DSS requirements. Examples include payment terminals, payment application servers, and databases containing PAN data.

Category two covers connected systems that do not handle card data but have a network path to category-one systems without sufficient access controls. They are in scope as connected system components. A system leaves this category only through effective segmentation that removes the path entirely or limits it to defined, controlled communication types unable to access or affect cardholder data.

Category three includes systems made out of scope through effective, verified segmentation. This status requires ongoing verification because isolation depends on working controls. Segmentation valid in January may fail silently after a routing change in March. Scope is not permanent.

The Connected System Error That Expands Scope Most Often

A frequent mistake is calling corporate network systems out of scope because a VLAN or firewall "separates" them from the payment environment while allowing some traffic. VLAN separation alone is not PCI DSS segmentation. The DSS requires segmentation methods to prevent or restrict in-scope traffic, making access from the other side technically infeasible or limited.

If a firewall between the corporate network and CDE permits inbound connections from corporate hosts, even on restricted ports, those hosts are in-scope connected system components. Shared directory services work the same way. An Active Directory domain controller handling corporate authentication is in scope if it can reach CDE systems because authentication requires that access. Many mid-market merchants have this setup without fully documenting it in scope.

E-Commerce Scope and Third-Party Scripts

Card-not-present e-commerce adds another scoping issue. Merchants using fully hosted payment pages with a complete redirect may have reduced scope because the payment service provider collects cardholder data and it never enters merchant servers. This is the SAQ-A scenario.

Third-party JavaScript on checkout pages creates another control requirement, including scripts from trusted payment SDKs. Under PCI DSS 4.0 Requirement 6.4.3, payment page scripts must be managed: document each origin, protect each script's integrity, and detect unauthorized changes. This applies even when card entry uses a hosted iframe. The payment page remains in scope because it can influence collection of card data.

An e-commerce merchant operating under SAQ-A may move into SAQ-A-EP after adding third-party analytics or personalization scripts to checkout pages. The distinction matters because SAQ-A-EP includes script management and page security requirements that SAQ-A does not.

Scoping Records Your QSA Needs

A completed scope definition must be documented and defensible, not merely understood internally. QSAs look for a system inventory covering all CDE components, a network diagram showing boundaries and every connection into and out of the CDE, evidence of segmentation for systems treated as out of scope, and data flow records showing how cardholder data enters and leaves.

Data flow records are especially important and often incomplete. It is not enough to describe payment processing generally. Documentation should trace a PAN from capture through every system touching it until it is protected in storage or deleted. Any step reaching a system missing from the CDE inventory is a scoping gap.

The three-category framework has one clear limitation: scope is only as accurate as its network topology and access-control configuration. An analysis from Q1 that misses infrastructure changes in Q2 and Q3 will not match the environment when the QSA arrives. Continuous segmentation verification and periodic scope review are necessary to keep the definition accurate.

Where Scoping Mistakes Cost Most

An overly narrow scope creates two types of consequences. More often, the QSA finds systems omitted from the assessment, requiring expanded scope, more evidence, added cost, and ROC delays. More seriously, omitted systems may lack required controls because nobody understood them to be in scope, leaving an actual attack surface unprotected.

Defining scope before the QSA engagement saves time, lowers assessment cost, and aligns compliance with the risk environment. Identifying connected systems, documenting data flows, and verifying segmentation may not be glamorous, but this work supports the rest of a PCI assessment.