A client's payment application sits behind a carefully documented firewall, so the team marks the corporate network as out of scope. During the penetration test, an assessor discovers that administrators can reach the payment environment through a shared identity service and a remote management path. The payment application itself was mapped correctly. The attack path into it wasn't.
That mistake can derail an assessment, expand testing obligations, and leave a trust boundary that exists on a diagram but not in practice. PCI DSS scope is therefore more than an inventory exercise. It determines which systems, people, processes, access routes, and dependencies must be assessed, secured, tested, and supported with evidence.
Many organizations either underestimate scope and create blind spots, or overestimate it and burden teams with unnecessary compliance work. The practical answer lies in tracing cardholder data and the paths that could affect its security. For merchants using external payment providers, the guide to MoR for global selling can also help clarify which payment responsibilities sit with the merchant and which sit with a service provider. For a broader grounding in the standard, review this PCI DSS compliance resource.
Table of Contents
- Introduction to PCI DSS Scope
- Understanding PCI DSS Scope Fundamentals
- Determining the Cardholder Data Environment
- Avoiding Common Scoping Pitfalls
- Applying Segmentation for Scope Reduction
- Implementing a Practical Scoping Checklist
- Integrating Scope with Penetration Testing and Compliance
Introduction to PCI DSS Scope
A useful scoping review begins with a question that most checklists avoid: how could an attacker reach, influence, or pivot toward the cardholder data environment? That question changes the conversation from “Which servers process payments?” to “Which systems and identities create a route to those servers?”
An MSSP might find that a client's checkout API stores no cardholder data, while a database does. The API still deserves close attention if it transmits account data or controls access to the database. A build server may never see a payment record, yet it could affect the security of a payment application if it can deploy code to it. An authentication server can become relevant when compromise of that service would give an attacker privileged access to CDE systems.
This is why a scoping error affects more than an assessor's worksheet. It can produce an incomplete penetration testing plan, omit critical internal attack paths, weaken segmentation evidence, and create a false sense of containment. A test that excludes an administrative route can report a clean external perimeter while missing the path an attacker would use after compromising a corporate account.
Instructor's rule: Treat every trust boundary as a claim that needs evidence. A diagram shows intent. A test demonstrates whether the boundary holds.
The sections that follow use that mindset. You'll see how to identify the CDE, map adjacent assets, challenge segmentation assumptions, document decisions, and connect the final scope to external, internal, and segmentation testing. The emphasis is practical, because MSSPs need a repeatable method that works across on-premises, cloud, hosted checkout, and hybrid environments.
Understanding PCI DSS Scope Fundamentals
The PCI Security Standards Council formally defines scoping as the process of identifying all system components, people, and processes that must be included in an assessment. The Council also states that accurately determining scope is the first step of any PCI DSS assessment, as described in its official scoping and segmentation guidance.
Start with the cardholder data environment, or CDE. It includes the people, processes, and technologies that store, process, or transmit cardholder data or sensitive authentication data. It also includes system components connected to those systems or capable of affecting their security. That second category is where many scoping reviews fail.
A connected system isn't automatically irrelevant because it doesn't store payment data. Consider these examples:
- Authentication services: A directory or identity platform can influence access to CDE systems.
- Management systems: A privileged access platform, jump host, or orchestration service can create an administrative path.
- Virtual infrastructure: Virtual machines, hypervisors, and supporting components may affect the security of payment workloads.
- Network controls: Firewalls, routers, switches, and security groups enforce the boundary and must be understood.
- People and processes: Developers, administrators, help-desk staff, deployment workflows, and incident procedures can affect CDE security.
PCI DSS v4.0.1 also applies requirements to system components that don't store, process, or transmit cardholder data but have unrestricted connectivity to in-scope systems. Scope isn't limited to the payment application tier. It follows security impact and connectivity.
The review must be maintained as an ongoing governance activity. PCI SSC guidance says organizations should revisit scope at least annually and before the annual assessment, so a prior scope statement shouldn't be copied forward without checking architecture, access, vendors, and data flows.
Determining the Cardholder Data Environment
Mapping the CDE works best as a graph rather than a list. Put the payment process at the center, then follow every data flow, management path, trust relationship, and supporting dependency until the route ends or a defensible boundary blocks it.
Start with payment applications and data flows
Inventory every application that stores, processes, or transmits cardholder data or sensitive authentication data. Include payment APIs, checkout services, authorization components, databases, queues, batch jobs, backups, and logging destinations that receive relevant data.
Don't assume the visible checkout page tells the whole story. A hosted redirect, embedded iframe, or payment script can introduce different responsibilities for page owners, content management systems, release pipelines, and monitoring teams. For teams documenting the physical side of payment acceptance, a practical overview of in-store payment acceptance can help distinguish terminal flows from online application flows.
Trace connected systems
PCI SSC guidance makes clear that scope includes systems with unrestricted connectivity to systems handling payment data. Map the relationships, not just the servers. On-premises, this may include a payment database, an application cluster, a hypervisor, a backup service, a directory server, and a privileged jump host. In a cloud environment, trace VPC or virtual network connections, security groups, identity roles, management APIs, secrets stores, deployment services, and monitoring integrations.
For each connection, record:
- Source and destination: Which component initiates communication?
- Purpose: Is the flow required for payment processing, administration, monitoring, or recovery?
- Trust relationship: Could compromise of the source help an attacker reach or alter the CDE?
- Boundary control: Which firewall, VLAN, security group, proxy, or identity policy restricts the flow?
- Evidence: Which configuration, log, or test result proves the control works?
Add people and processes
A user who administers a payment server, a developer who deploys its code, and a support employee who can reset privileged access all belong in the scoping conversation. So do third-party operators, managed service teams, and incident responders whose actions could affect CDE security.
A strong data-flow diagram should therefore have two layers. The first shows systems and traffic. The second overlays identities and operational processes, including remote access, change management, backup restoration, vulnerability scanning, and emergency access. The result is a perimeter based on who can influence the CDE and how, not where the payment database happens to sit.
Avoiding Common Scoping Pitfalls
Many PCI DSS explainers still present scope as a static checklist. Current guidance puts more weight on attack paths and trust boundaries, which exposes adjacent assets, administrative routes, and outsourced components that a checklist can miss. The following eight failures appear repeatedly in MSSP scoping work.
Assuming segmentation equals isolation. A VLAN or firewall zone proves design intent, not effective separation. Test from out-of-scope networks, review routes and rules, and attempt administrative pivots.
Excluding embedded payment scripts. A page may not store cardholder data, yet its JavaScript, iframe, or embedded form can affect payment-page integrity. Identify page owners, script approval, deployment, and monitoring workflows.
Ignoring third-party dependencies. Payment gateways, hosting providers, identity vendors, support firms, and managed platforms can influence the CDE. Document responsibility boundaries and the access each provider receives.
Accepting an incomplete asset inventory. Forgotten virtual machines, backup stores, test systems, and management tools often create the route an attacker needs. Reconcile CMDB records with cloud inventories, network telemetry, and penetration testing observations.
Treating scope as permanent. Architecture changes, new integrations, remote access tools, and cloud migrations can invalidate an old boundary. Revisit the register annually, before assessment, and after material changes.
Over-scoping without analysis. Including every corporate asset may feel safer, but it obscures the actual trust boundaries and increases assessment effort. Record why each system is in scope and what evidence could support exclusion.
Underestimating cloud complexity. Shared responsibility doesn't remove the customer's duty to understand identities, management planes, security groups, workload paths, and provider dependencies. Map both the data plane and the control plane.
Failing to document decisions. An unexplained exclusion won't withstand assessor questions. Preserve diagrams, inventories, flow descriptions, ownership, assumptions, and validation results in a scope register.
A boundary that can't be explained, tested, and reproduced isn't a reliable boundary.
Applying Segmentation for Scope Reduction
Segmentation reduces scope by limiting which systems can reach the CDE or affect its security. The technique might use VLANs and firewalls in a traditional data center, VPC or virtual network isolation in the cloud, or narrowly defined security groups and workload policies in a modern application environment.
Design the boundary around required flows
Start with the smallest payment zone that can support the business process. Place internet-facing components in a controlled edge segment, payment services in the CDE core, and corporate or development systems behind a boundary that permits only justified communication. In cloud environments, separate workloads with VPC or virtual network design, route controls, security groups, private endpoints, and tightly governed administrative access.
Micro-segmentation can take the model further. Instead of trusting an entire network segment, define which specific workloads may communicate with payment services. That approach helps expose unnecessary east-west paths, such as a developer workstation reaching an administrative service that can reach the CDE.
Use tokenization carefully
Tokenization can reduce the amount of sensitive cardholder data retained by internal systems by replacing it with tokens. It doesn't automatically remove the payment page, application, people, or processes from scope. The provider relationship, token service, integration, credentials, and remaining data flows still need analysis.
A payment gateway decision should likewise be evaluated through the lens of data flow, provider responsibility, embedded components, and administrative access. Teams comparing options may find this resource on secure payment gateways useful as background before drawing the final boundary.
Validate the proposed reduction
A segmentation design becomes a scope-reduction control only when testing demonstrates that the out-of-scope environment cannot reach the CDE or impact its security. Test both directions where relevant, include administrative and management paths, and assess whether a compromised system can alter a firewall, identity policy, deployment process, or monitoring control.
PCI SSC published supplemental scoping and segmentation guidance on 18 July 2022, followed by an updated guide in 2024 focused on modern network architectures, as documented in the Council's scoping guidance announcement. The message for penetration testers is straightforward: segmentation isn't a diagramming preference. It's a claim about reachable attack paths that must survive adversarial validation.
Implementing a Practical Scoping Checklist
A repeatable review gives every participant a defined output. The engagement lead coordinates the review, application owners explain payment flows, infrastructure teams provide topology and control evidence, identity teams map privileged paths, and stakeholders approve the final scope statement.
Build the evidence in sequence
Begin with discovery interviews and payment-flow workshops. Ask where cardholder data enters, where it travels, where it is stored, which systems transform or forward it, and who can administer each component. Capture unknowns rather than filling gaps with assumptions.
Next, reconcile the asset inventory. Compare application records, cloud resources, network devices, virtual machines, databases, authentication servers, management tools, backups, and third-party services. Mark every asset as directly handling data, connected to the CDE, able to affect CDE security, or potentially isolated pending validation.
Then create two diagrams:
- Data-flow diagram: Shows cardholder data and sensitive authentication data movement.
- Trust-boundary diagram: Shows network, identity, administrative, cloud, and vendor paths that could affect CDE security.
Scoping Checklist Overview
| Step | Description | Responsible Party |
|---|---|---|
| Discovery interviews | Confirm payment processes, users, vendors, and operational dependencies | MSSP lead, business owner |
| Asset inventory | Reconcile systems, applications, identities, and cloud resources | Infrastructure and application owners |
| Network mapping | Document routes, security controls, management paths, and data flows | Network and cloud teams |
| Segmentation testing | Validate that proposed exclusions cannot reach or affect the CDE | Penetration testing team |
| Scope register | Record inclusion, exclusion, rationale, evidence, and ownership | Compliance lead |
| Stakeholder sign-off | Approve the final boundary and unresolved assumptions | Executive and technical stakeholders |
| Ongoing review | Reassess annually, before assessment, and after relevant changes | Scope owner and MSSP |
Segmentation testing should happen before stakeholders approve an exclusion. If the test finds a reachable administrative path, update the boundary, correct the control, or retain the system in scope. A PCI DSS compliance testing resource can support teams aligning testing evidence with assessment expectations.
Maintain a scope register with version history. Each entry should identify the asset, owner, environment, data relationship, access path, boundary control, evidence location, decision, and review date. Trigger an ad hoc review when teams introduce a payment integration, change identity architecture, modify segmentation, migrate workloads, add remote access, or alter a third-party service relationship.
Integrating Scope with Penetration Testing and Compliance
The final scope statement should become the test plan's control document. It tells the MSSP which external assets to assess, which internal networks and critical systems to examine, and which segmentation boundaries require an isolation test.
PCI DSS penetration testing guidance includes the entire CDE perimeter plus critical systems, covering external public-facing attack surfaces and internal LAN-to-LAN attack surfaces, as described in the Council's penetration testing guidance. A test plan that covers only the checkout hostname can therefore be incomplete if authentication, administration, deployment, or connected infrastructure can affect the CDE.
For each boundary, define the attacker position and objective. An external test may assess public-facing payment services. An internal test may begin from a corporate workstation or an adjacent network. A segmentation test should begin from an out-of-scope location and attempt to reach CDE systems, bypass controls, or influence security through permitted management paths.
Collect evidence that maps findings to the scope decision:
- Screenshots and request evidence for exploitable application or network conditions.
- Logs and configuration records showing allowed and denied paths.
- Route and security-control evidence supporting isolation claims.
- Segmentation test results showing whether out-of-scope systems can reach or affect the CDE.
- Remediation links that connect each finding to an owner and boundary.
Organizations using segmentation to reduce scope must test the segmentation controls at least annually, and service providers must test them at least every six months, with testing also required after changes to segmentation controls, according to the segmentation testing guidance. The exact cadence matters because a firewall rule or identity relationship can change long before the next assessment.
A precise scope makes reporting more useful. Findings can be assigned to the correct asset owner, false exclusions become visible, and assessors can follow the evidence from the CDE definition to the attack path and the control that blocks it. For MSSPs standardizing delivery, a PCI DSS penetration testing workflow provides a focused reference for connecting scope, testing objectives, and compliance evidence.
ThreatExploit AI helps MSSPs run automated penetration tests across web applications, APIs, internal and external networks, and cloud environments, then produce evidence-backed reports with PCI DSS control mapping. Visit ThreatExploit AI to evaluate how its reconnaissance, exploitation, verification, and reporting workflow can support repeatable CDE and segmentation assessments.