PCI DSS Scoping and Segmentation Guide

Most PCI DSS assessments that go wrong do so at the boundary: a system the entity treated as out of scope turns out to connect to, administer or secure the cardholder data environment. Scope decides which systems must meet every requirement, how much the assessment costs and, more importantly, where an attacker can reach card data from. This guide explains the PCI Security Standards Council's three scoping categories, how to test whether a system is really out of scope, what makes segmentation adequate, how shared identity services, service accounts and cloud platforms pull systems into scope, and how to keep scope confirmed between assessments. It is for security architects, PCI programme owners and internal assessors at merchants and service providers. For the standard as a whole, see the PCI DSS 4.0 Guide; this page goes deeper on scope.

Key takeaways

Everything is in scope until verified otherwise. The Council's scoping guidance starts from that position, and a system is out of scope only when it meets every out-of-scope criterion.
Connected-to and security-impacting systems are in scope. Directory services, jump servers, admin workstations, patch, logging and time servers that serve the CDE must meet the applicable requirements.
Segmentation is a control, not a VLAN. Separate network segments alone do not create PCI DSS segmentation; purpose-built controls must stop out-of-scope systems from communicating with or affecting the CDE.
Identity is the boundary most often crossed. A shared Active Directory, a cloud IAM role or a CI/CD service account that can change CDE systems brings its whole management plane into scope.
Scope is confirmed, not assumed. PCI DSS v4.x requires documented scope confirmation at least every 12 months and on significant change, and penetration testing of segmentation controls.

The three scoping categories

The Council's information supplement Guidance for PCI DSS Scoping and Network Segmentation (version 1.1, May 2017) defines three categories. They are hierarchical: a system that meets any CDE criterion is a CDE system even if it also fits a lower category, and a system is out of scope only if it meets all of the out-of-scope criteria and none of the others. The categories remain the working model under PCI DSS v4.x.

Category	Criteria (any one is enough)	Treatment
CDE systems	Stores, processes or transmits cardholder data (CHD) or sensitive authentication data (SAD); or sits on the same network segment, subnet or VLAN as systems that do	In scope for every applicable requirement
Connected-to and/or security-impacting systems	Can connect to or access the CDE from another segment; can reach the CDE through another system such as a jump server; can affect the configuration or security of the CDE or how CHD is handled (for example DNS or web redirection); provides security services such as traffic filtering, patch distribution or authentication; supports PCI DSS requirements such as time synchronisation or log storage; provides segmentation (firewalls)	In scope for the requirements relevant to their function, and must not provide an access path between the CDE and out-of-scope systems
Out-of-scope systems	Must meet all: does not store, process or transmit CHD or SAD; not on a CDE segment; cannot connect to or access any CDE system; cannot reach the CDE or affect a CDE control through an in-scope system; meets no connected-to or security-impacting criterion	Not assessed, but the controls that keep them out must themselves be validated

The Council is explicit that being out of scope is not a reason to leave a system unprotected, and that "a common pattern seen in data breaches is where the attacker targets systems deemed by the entity to be out-of-scope."

The out-of-scope test in practice

Ask the attacker question: the guidance describes a properly segmented system as one that could not affect the security of the CDE even if an attacker obtained administrative access on it. If admin on the system gives a path to a CDE credential, rule, image or log, it is not out of scope.
Follow every credential: a server that stores a service account password usable on a CDE host can reach the CDE, whatever the firewall says.
Follow every management channel: configuration management, endpoint management, backup agents and monitoring agents are paths into the CDE.
Follow the "connected to connected to" chain carefully: the Council's assessor commentary notes that this was a frequent point of confusion. A system that only connects to a connected-to system is not automatically in scope, but it is if it can reach the CDE or influence a CDE control through that system.

Scoping step by step

The Council's supplement lays out the scoping process in eight steps. The ordered list below follows it, with the evidence each step should produce.

Identify payment channels: every way the entity receives card data, including card present, e-commerce, call centre, mail order and any legacy or low-volume channel. Low-volume channels are often cheaper to remove than to secure.
Document data flows: trace CHD through people, processes and technologies, including where it is stored and where it leaves for processors. PCI DSS v4.x expects current network diagrams (Requirement 1.2.3) and data-flow diagrams (1.2.4).
Identify everything that can interact with the CDE: connected-to and security-impacting systems, including shared services, admin endpoints and third-party connections.
Limit connectivity: restrict flows between the CDE and other in-scope systems to what is necessary, with a business justification for each rule.
Segment the rest: separate the CDE from people, processes and technology that do not need to interact with it.
Apply requirements: map applicable PCI DSS requirements to every in-scope component and record any that do not apply, with the reason.
Maintain controls: keep segmentation, access and monitoring effective over time.
Update scope on change: treat new applications, network changes, acquisitions and cloud migrations as scope events.

Test the result before the assessor does: a scope that cannot be explained from the diagrams, the inventory (12.5.1) and the firewall rules will not survive fieldwork.

What makes segmentation adequate

Segmentation is not itself a PCI DSS requirement, but the Council strongly recommends it because without it the network is flat and the entire network is in scope. Adequate segmentation isolates systems that store, process or transmit CHD from those that do not, physically or logically, so that compromise of an out-of-scope system could not affect the security of the CDE.

Technique	Where it works	What the assessor will want to see
Internal firewalls or network security controls between zones	On-premises data centres and stores	Rule sets with justification, default deny, change records, review evidence
Access-controlled routers and ACLs	Branch and store networks	ACL exports matched to diagrams; proof the ACLs are applied on every path
Cloud network controls (separate accounts, subscriptions or projects, security groups, network policies)	IaaS and PaaS CDEs	Account structure, security group and route table exports, organisation policies preventing peering or new paths
Micro-segmentation and identity-aware policy	Data centres and Kubernetes clusters	Policy definitions, enforcement mode (not monitor only), workload identity mapping, testing results
Separate management plane	Any CDE administered by shared IT	Dedicated admin accounts, jump hosts, MFA, no shared credentials with corporate systems
Scope reduction by design (P2PE, tokenisation, outsourced payment pages)	Merchants that do not need to touch CHD	Validated solution listings and the provider's responsibility documentation

The Council's 2024 information supplement, PCI DSS Scoping and Segmentation Guidance for Modern Network Architectures, extends the model to zero trust, micro-segmentation, multi-cloud boundaries and asset inventories for cloud-hosted microservices. It is supplemental and does not replace the standard. In virtualised and container environments, remember that virtual components share underlying resources: the hypervisor, cluster control plane and orchestration accounts that can reach CDE workloads are in scope. See the Network Segmentation Guide.

Testing segmentation

Merchants: if segmentation is used to isolate the CDE, penetration tests on the segmentation controls are performed at least once every 12 months and after any change to segmentation controls or methods (Requirement 11.4.5).
Service providers: the Council's FAQ on Requirement 11.4.6 states that service providers using segmentation must test those controls at least once every six months and after any change to segmentation methods.
Method: the test must cover every segmentation control in use and confirm the CDE is isolated from out-of-scope systems. The tester must be organisationally independent; according to the Council a QSA or ASV is not required.
Coverage: test from each out-of-scope zone, including corporate user networks, guest Wi-Fi, partner connections and cloud accounts outside the CDE, and include management protocols such as SSH, RDP, WinRM, SMB and cloud API endpoints.

Where identity and NHIs pull systems into scope

Network diagrams show packets; attackers move with credentials. Identity services are explicitly listed by the Council as shared services that are connected-to or security-impacting, and service accounts are the most common unrecorded path across a boundary.

Identity element	Why it is in scope	Scope-reducing design
Shared Active Directory or LDAP domain	Provides authentication to the CDE; domain admins and domain controllers can change any joined CDE host	Dedicated CDE forest or tier, or strict tiering with CDE admin accounts that cannot sign in elsewhere
Cloud IdP and SSO (SAML or OIDC)	Controls who can reach CDE consoles and applications	Separate admin roles and conditional access for CDE apps; treat the IdP admin plane as security-impacting
Cloud IAM roles and access keys	Any principal that can modify CDE resources can affect CDE security	CDE in its own account or subscription; service control policies; no cross-account roles from non-CDE workloads
CI/CD pipelines and deployment service accounts	Pipelines that deploy code or images to CDE systems change how CHD is handled	Separate runners and credentials for CDE deployments, signed artefacts, approvals
Secrets managers and key management	Holding a CDE credential or encryption key is a path to the CDE and the data	Separate vault or namespace for CDE secrets, per-workload access, keys not readable by the systems holding encrypted data
Monitoring, backup and EDR agents	Agents run with high privilege on CDE hosts and their consoles can push actions	Treat consoles as security-impacting, restrict console admin roles, MFA

The account requirements that follow from this, including system and application accounts under Requirement 8, are covered in the PCI DSS Requirements for Service Accounts and NHIs Guide. For a register of the accounts themselves, see the Service Account Inventory Template.

Confirming and maintaining scope

PCI DSS v4.x turned scope confirmation from an assessor activity into an entity requirement. Requirement 12.5.2 expects the entity to document and confirm scope at least once every 12 months and on significant change to the in-scope environment, covering data flows, locations of stored account data, CDE components, segmentation controls, connections from third parties and the systems connected to the CDE. Service providers confirm scope at least every six months (12.5.2.1) and review the effect of organisational changes on scope (12.5.3).

Define "significant change": write down what triggers a scope review, for example new payment channel, new network path to the CDE, new cloud account, new third-party connection, change of identity provider or directory structure, acquisition.
Tie scope to the inventory: the system component inventory (12.5.1) should flag each asset's scoping category and owner.
Use the responsibility matrix: for hosted CDEs, the provider's responsibility documentation decides which requirements you still own.

Detection and metrics

Monitor boundary flows: alert on any allowed connection from an out-of-scope zone to the CDE that is not in the approved rule set, and on new routes, peering connections or security group rules touching CDE resources.
Monitor identity paths: alert on sign-ins to CDE systems by accounts not in the CDE admin group, and on use of CDE service accounts from non-CDE hosts.
Metric: unexplained flows found by segmentation tests (target zero).
Metric: inventory coverage, share of discovered assets with an assigned scoping category.
Metric: identity overlap, number of accounts with rights both inside and outside the CDE.
Metric: change compliance, share of significant changes that triggered a recorded scope review.
Metric: rule justification, share of CDE network rules with a current business justification.

Decision guidance

Segment or accept a flat network: a small merchant with a single office may find a flat network cheaper to assess than to segment, but every workstation is then in scope. Most organisations above a handful of systems save money and risk by segmenting.
Reduce scope before segmenting: a validated P2PE solution, tokenisation, or a fully outsourced payment page can remove most systems from scope entirely, which beats securing them. See the Tokenisation and Data Masking Guide.
Dedicated identity versus shared identity: a separate CDE directory costs administration effort but keeps the corporate domain out of scope. Large estates with many CDE hosts usually benefit; small ones may tier a shared domain carefully instead.
Cloud: a separate account, subscription or project for the CDE gives the clearest boundary, because IAM and network controls are both scoped to it.

Framework mapping

Scoping activity	PCI DSS v4.x	NIST SP 800-53 Rev. 5	NIST CSF 2.0	ISO/IEC 27001:2022 Annex A	ATT&CK technique it limits
Network and data-flow diagrams	1.2.3, 1.2.4	CA-03, AC-04	ID.AM-03	A.8.20	n/a
Component inventory with scope tag	12.5.1	CM-08	ID.AM-01	A.5.9	n/a
Segmentation controls	1.3, 11.4.5, 11.4.6	SC-07	PR.IR-01	A.8.22	T1021 Remote Services
Separate CDE identities and credentials	7, 8	AC-02, AC-06	PR.AA-05	A.5.15, A.8.2	T1078 Valid Accounts, T1552.001 Credentials In Files
Third-party connections	12.8	CA-03	GV.SC-07	A.5.19	T1199 Trusted Relationship, T1133 External Remote Services

Common failure patterns

VLANs treated as segmentation: CDE hosts on their own VLAN but routed freely to the corporate network. The Council states that separate segments alone do not create segmentation.
Admin workstations left out: corporate laptops used to administer CDE systems are security-impacting and fully in scope; the rest of the LAN can stay out only if segmentation is verified.
Shared services ignored: DNS, NTP, patch, backup, logging and directory servers serving the CDE excluded from the assessment.
Credentials crossing the boundary: CDE service account passwords in scripts, configuration files or shared vaults reachable from out-of-scope hosts.
Segmentation tests that miss paths: testing from one corporate subnet only, or excluding management protocols and cloud APIs.
Scope frozen at the last assessment: cloud accounts, new integrations and acquisitions added without a scope review.

Lessons from incidents

The AI Agent Retail Card Theft Campaign 2026 shows why supporting systems belong in scope. The attackers did not start at the card data store: they moved through a web host, found database credentials in a configuration file, used them to pivot, dumped cloud secrets manager entries and extracted the encryption key that decrypted stored card numbers. Each of those hosts, credentials and the secrets vault could affect the security of card data, so under the Council's criteria they were security-impacting systems. The scoping lesson is to trace credentials and keys as carefully as network flows, and to keep the keys that protect stored card data out of reach of the systems that hold it.

Practitioner checklist

List every payment channel and remove any that do not justify their compliance cost.
Maintain current network and data-flow diagrams and a component inventory tagged with scoping category.
Classify every system as CDE, connected-to or security-impacting, or out of scope, recording the reason for each out-of-scope decision.
Trace every credential, key and management agent that can reach the CDE and bring its source system into scope or remove the path.
Separate CDE administration: dedicated accounts, jump hosts, MFA and no shared service account credentials.
Penetration test segmentation from every out-of-scope zone at least every 12 months (six for service providers) and after changes.
Define significant-change triggers and record a scope review for each one.
Confirm and document scope at least every 12 months, and reconcile it with the assessor before fieldwork.

PCI DSS Scoping and Network Segmentation Guide: Drawing and Proving the CDE Boundary