How do you define PCI DSS scoping and segmentation for your environment?
When a customer, acquirer or contract asks for PCI DSS validation, the first decision is which systems it covers. PCI DSS scope is the cardholder data environment plus any connected or security-impacting system components, and segmentation reduces that scope only when the isolation is documented and its controls are tested. The organization owns this decision. Under Requirement 12.5.2, your entity must confirm its PCI DSS scope at least every 12 months and after significant change, covering data flows, account data locations, connected components, segmentation controls and third-party connections. Service providers must repeat that confirmation every six months under 12.5.2.1. An independent assessor, typically a QSA for a Report on Compliance, then validates the result.
The answer changes with your data flows, hosting model and third parties. A card-present terminal network, a cloud-hosted checkout, and a payment page loaded from a processor's domain each produce different boundaries, and a shared cloud account can pull unrelated workloads into scope through identity, logging or management paths. Start by mapping where account data enters, is stored, is processed and leaves, then build the network and data-flow diagrams that Requirements 1.2.3 and 1.2.4 expect. Next, produce an inventory of in-scope system components with each one's function, as Requirement 12.5.1 asks. Ask your QSA which of these artifacts they will sample and how they expect segmentation to be shown.
Segmentation only helps if it holds, so plan for the testing that proves it. Where segmentation separates the CDE from other networks, Requirement 11.4.5 requires penetration tests of those controls at least every 12 months and after changes, and Requirement 11.4.6 raises that to every six months for service providers. The PCI SSC's 2024 information supplement on scoping and segmentation for modern architectures covers zero trust, micro-segmentation and ephemeral cloud systems, which matter if your environment uses them. DeployOpen can prepare diagrams, inventories and segmentation evidence, and can run security testing in its own scope. It does not decide your scope on your behalf, and it does not issue reports or attestations.
Which evidence proves your scope is complete?
Scope is only as credible as the records behind it. The artifacts below show what sits inside the cardholder data environment, how data moves through it, and which outside parties connect to it, and each one should agree with the others.
Component inventory with function
Requirement 12.5.1 asks for an inventory of in-scope system components, each with a description of its function or use. The inventory is the starting list for every other check: if a server, virtual machine, container or cloud service is missing, it is likely unmonitored and unassessed. Check that cloud and ephemeral workloads are included, that each entry says what it does, and that the list is compared against live discovery. A gap looks like an entry with no stated purpose or a host found on the network that no record mentions.
Network diagram of CDE connections
Requirement 1.2.3 expects an accurate network diagram that shows every connection into and out of the cardholder data environment, including wireless networks. The diagram proves where the boundary sits and which paths a segmentation control must block. Compare the diagram with actual firewall rules and routing tables, since a diagram drawn at build time often misses later additions. A gap looks like a link to a corporate, vendor or cloud network that the diagram does not show, or a segment labeled as isolated with no matching control.
Account data flow diagram
Requirement 1.2.4 asks for an accurate data-flow diagram showing how account data moves across systems and networks. Where the network diagram shows paths, this one shows what travels along them, such as PAN, authentication data, logs or exports. Confirm that each flow has a starting system, a destination, a protocol and a stated business reason. A gap looks like a flow discovered in logs or traffic captures, such as a reporting job or backup copy, that appears in no diagram.
Account data location discovery
Scope must include every place account data is stored, including databases, file shares, logs, backups, email, ticketing systems and developer environments. Discovery is the process of searching these locations and recording what is found, then removing data that does not need to be kept. Document the search method, the tools used and the date of each run, so an assessor can see how thorough it was. A gap looks like a discovery scan that covered only production databases, or card data found in a support ticket that nobody recorded.
Third-party connection records
Vendors, processors, managed service providers and remote support tools that connect to the CDE or can affect its security belong in scope evidence. Keep a record for each connection that names the party, the access method, the accounts used, the data exchanged and the responsibility split. Responsibility matrices from providers help show which controls they handle. A gap looks like a remote support account that no current contract or access record covers, or a provider that appears in the network diagram but has no written responsibility agreement.
Segmentation test and scope review trail
Segmentation controls are only evidence of scope reduction if they are tested, and scope is only current if it is reviewed after significant change. Keep the records of segmentation penetration tests, the scope confirmations and the change reviews that triggered them. Under Requirement 11.4.5, segmentation testing follows changes, so a missing test after a network change is a clear gap. Ask whether each review covered the inventory, diagrams and third-party list together.
How segmentation reduces scope and what it must prove
Segmentation lets you exclude systems from PCI DSS scope only when it isolates the cardholder data environment (CDE) from everything else. Network separation alone does not do this. The boundary has to hold under test, so the segmentation controls themselves become a scoped item that an assessor will check. Before you rely on any boundary, confirm that your network diagram under Requirement 1.2.4 shows every connection into the CDE and that the segmentation controls you list in your scope confirmation are the ones that actually enforce the boundary.
Requirement 11.4.5 asks for penetration tests of the segmentation controls at least every 12 months and after changes. Requirement 11.4.6 raises that frequency to every six months for service providers. The test should try to reach the CDE from out-of-scope networks, including through any remote access, shared administration paths or cloud routing that your diagrams show. Ask your tester to document each attempted path and its result, and ask your team to keep the change records that trigger a retest, since an assessor will compare the two. Confirm the exact testing scope with your assessor before work starts, because the boundary you test must match the boundary you declare.
The PCI SSC published an information supplement on 9 September 2024 covering scoping and segmentation for modern network architectures, including zero trust, micro-segmentation, multi-cloud designs and inventories of ephemeral cloud systems. If your environment uses any of these, read the supplement directly rather than relying on a summary, and map its guidance to your own design. Then confirm with your QSA how the supplement applies to your architecture, particularly how ephemeral workloads are inventoried and how their boundaries are tested. Treat that conversation as a design decision, not a formality, because it determines what you must keep documented and retested.
How scope is confirmed and retested each cycle
The sequence turns a loosely defined cardholder data environment into a documented, tested boundary that the entity can confirm each cycle and hand to its QSA or SAQ process. Each step produces an artifact that the next step depends on.
Map account data flows and storage locations
Start by tracing every path that primary account number data and sensitive authentication data takes, from the point of capture through processing, storage, transmission and deletion. Include payment pages, APIs, batch files, backups, logs, support tooling and any third party that receives card data. Owners are usually the payments or engineering lead with input from operations and finance. The step is done when a data-flow diagram covers every flow and each storage location is named, which is the basis required by Requirements 1.2.3 and 1.2.4.
Build the component inventory and network diagrams
Using the data flows as a guide, list every system component that stores, processes or transmits account data, or that is connected to or could affect the CDE. Record each component's function, owner and location, including virtual machines, containers, cloud services and security tooling. Pair the inventory with a current network diagram showing every connection into and out of the CDE. The output is an inventory that satisfies Requirement 12.5.1 and a diagram that an assessor can check against the live environment.
Define segmentation controls and their boundaries
Decide which controls separate the CDE from the rest of the network, such as firewalls, cloud security groups, network access rules, and identity boundaries, and document what each one permits. Mark the connections that cross the boundary, including administrative access, monitoring and third-party links, and state why each is needed. Where segmentation is claimed to reduce scope, record the rule set and the systems it isolates. The output is a segmentation specification tied to the inventory, so that any system outside the boundary can be justified against the rules.
Confirm scope against Requirement 12.5.2
The entity formally confirms its PCI DSS scope by walking through the data flows, storage locations, connected components, segmentation controls and third-party connections, and recording any system that was added, removed or changed. Confirmation must occur at least every 12 months and after significant change, and service providers must confirm every six months under Requirement 12.5.2.1. Significant changes include new CDE hardware or software and changes to data flows or the CDE boundary, as listed in PCI SSC FAQ 1317. The output is a signed scope confirmation record with dated sign-off by an accountable executive, and any out-of-scope decisions are documented with reasons.
Test segmentation controls with penetration testing
Where segmentation is used to isolate the CDE, commission penetration testing of the segmentation controls under Requirement 11.4.5, at least every 12 months and after changes to segmentation. Service providers test every six months under Requirement 11.4.6. The tester should attempt to reach CDE systems from out-of-scope networks, and the test must cover the controls the segmentation specification identifies. Testers should be qualified and independent of the team that built the controls. The output is a report listing the paths tested, the findings, and retest evidence showing that each finding was fixed.
Reconcile findings and update the boundary
Compare the segmentation test results and the scope confirmation with the inventory and diagrams. Every discrepancy, such as an unexpected route, an undocumented system or a rule that is broader than needed, should lead to a documented fix or a scope change, followed by an update to the diagrams and inventory. Confirm that the update is reflected in the change record for any affected system. The output is a reconciled set of artifacts with a log of changes, which shows the next cycle starts from an accurate baseline.
Hand the results to the QSA or SAQ process
Provide the scope confirmation, diagrams, inventory, segmentation specification and testing reports to the assessor or to the person completing the SAQ. The QSA examines the evidence and tests it against the environment during a ROC, while an SAQ entity keeps the same material to support its answers and its Attestation of Compliance. Organizations should confirm with their acquirer or payment brand which validation path applies. The output is an assessment package that matches the scope the entity claims, and any gap found by the assessor is tracked to closure before the attestation is signed.
Which changes force a scope review?
PCI DSS scope is not a one-time exercise. Certain changes to hardware, software, data flows, network paths and segmentation can move systems into or out of the cardholder data environment, and each one should prompt a documented scope review. The cards below cover the triggers named in PCI SSC FAQ 1317 and the cloud changes that most often slip past change control.
New CDE hardware or software
Any new server, network device, virtual component or application that stores, processes or transmits account data, or that connects to the cardholder data environment, is a system component and belongs in scope review. Adding a payment application, a logging agent or a jump host can each change the picture. Confirm that every new asset is added to the in-scope inventory before it goes live, and record its function so the inventory required by Requirement 12.5.1 stays accurate.
Changes to data flows or storage
A new integration, a new reporting feed or a change in where card data is written can extend the cardholder data environment into systems that were previously out of scope. Temporary copies in backups, analytics stores and support tickets are common sources of stray account data. Check whether your data-flow diagram and account data location records are updated for each change, since Requirements 1.2.3 and 1.2.4 depend on them.
Changes to the CDE boundary
Moving a service inside or outside the boundary, adding a new network segment, or changing the routing that defines where the CDE begins and ends alters scope directly. Supporting infrastructure such as DNS, authentication, time synchronization and security tooling can also fall within scope when it affects the security of account data. Treat any boundary change as a scope event, even when the change looks operational rather than payment-related.
Changes to segmentation controls
Firewall rule changes, VLAN or subnet redesigns, and modifications to access control lists can weaken the isolation that keeps other systems out of scope. A single permissive rule added during troubleshooting may connect the CDE to a flat network. Confirm that each segmentation change is reviewed against the segmentation penetration test scope, because Requirement 11.4.5 expects segmentation controls to be tested after changes.
New or changed third-party connections
A new vendor connection, remote support session, API integration or change to an existing service provider's access path can create a new route into the CDE. Each connection should appear in the scope documentation with its purpose and the controls that limit it. Confirm with each third party whether it stores, processes or can affect account data, and record the answer, because the outcome determines whether the connection is in scope.
Cloud and container network path changes
Ephemeral containers, new cloud accounts, peering links, load balancers and changed security groups can alter network paths without any visible change to the application. Autoscaling and infrastructure-as-code deployments can add in-scope components faster than manual inventories track them. Ask your team to confirm whether each cloud or Kubernetes change modifies routing into the CDE, and check the 2024 information supplement on modern network architectures for how assessors view these components.
How scoping differs across hosting models
In a self-hosted data center, the organization owns every layer that touches account data, so scope usually follows physical and logical boundaries it already controls: racks, hypervisors, storage arrays, firewalls and the network segments between them. Scope tends to be large when flat VLANs connect payment servers to corporate workstations, and it shrinks when the CDE sits behind dedicated firewalls with documented rules. Segmentation is typically enforced at the core and perimeter firewalls, with jump hosts controlling administrative access.
- Physical inventory: Racks, backup tapes, printers and management consoles that can reach the CDE are usually in scope and must appear in the Requirement 12.5.1 inventory.
- Network diagrams: An assessor will compare the diagram required by Requirements 1.2.3 and 1.2.4 against live firewall rules and routing tables.
- Segmentation testing: Penetration tests of segmentation controls under Requirement 11.4.5 should show that traffic from out-of-scope VLANs cannot reach the CDE.
- Change records: Hardware additions, VLAN changes and firewall edits are significant changes that trigger scope review under FAQ 1317.
Confirm that your scope list matches what the network team can demonstrate, not only what the diagram shows.
In public cloud, scope is defined by accounts, subscriptions, projects, virtual networks and the identity permissions that can change them. A single organization account can contain both payment workloads and unrelated services, so account boundaries, network peering, shared logging and shared identity providers often decide what is in scope. Managed services such as databases, load balancers and key stores are system components when they store, process or transmit account data or could affect its security.
- Account structure: Separate accounts or subscriptions for the CDE make the boundary easier to explain and to test.
- Shared services: Central logging, CI/CD pipelines, identity providers and secrets managers can affect CDE security and are usually in scope.
- Ephemeral workloads: Containers, serverless functions and autoscaling groups appear and disappear, so the Requirement 12.5.1 inventory must be generated from deployment records rather than typed by hand.
- Configuration evidence: Exports of security groups, route tables and IAM policies support the segmentation claim.
Ask your team how an auto-created instance is added to the inventory within a working day of launch, and whether the scope review runs when a new account is provisioned.
Hybrid networks connect an on-premises CDE to cloud or partner environments, usually through VPN tunnels, dedicated links or interconnect gateways. The scope problem is that each link is a connection into or out of the CDE, so the connection itself, the routing between sites and the systems at both ends can all fall in scope. Segmentation often depends on the gateway policy as much as on either network alone.
- Connection inventory: Each VPN, dedicated link and API connection to the CDE must be listed as a third-party or internal connection in the scope confirmation.
- Routing and gateways: Transit routing that lets out-of-scope cloud subnets reach CDE addresses breaks the boundary and must be documented.
- Data-flow diagrams: Requirement 1.2.4 expects a diagram of every account data flow that crosses the site boundary, including backups replicated to the cloud.
- Split responsibility: Where the cloud side is run by a provider or a platform team, the responsibility matrix should state who maintains each control.
Test that a host in the cloud subnet cannot reach a CDE address through the gateway, and keep that test result as evidence.
When a merchant redirects customers to a payment provider's hosted page or embeds the provider's iframe, most account data never reaches the merchant's systems. Scope shrinks to the merchant's website, the script and page content it controls, and any system that could alter the payment page. A SaaS platform that stores or processes account data for the merchant is a different case, and its own environment usually stays in scope for the merchant even if the provider handles the card data.
- Page ownership: The merchant's checkout pages, tag managers and third-party scripts can affect the payment page and are typically in scope.
- Vendor attestation: The provider's current Attestation of Compliance and responsibility matrix show which controls it operates. Request them before the assessment, not during it.
- Redirect evidence: Screenshots, configuration exports and code references show that card fields never load on merchant systems.
- Data stored on premises: Any copy of account data kept in the merchant's own systems, such as logs or exports, brings those systems back into scope.
Confirm with your provider which SAQ eligibility criteria your payment flow meets, because the answer depends on the exact integration method.
Why scope drifts and how to stop it
Scope rarely grows in one dramatic step. It drifts as administrators add tools, engineers open temporary paths and vendors connect for support, and the documentation falls behind. Each card below names one common error and the control that catches it before an assessor does.
Forgotten management and logging systems
Jump hosts, configuration management servers, SIEM collectors, backup agents and log aggregators often sit outside the payment application in the inventory. Any system that stores, processes or transmits account data, or could affect the security of the CDE, is a system component in scope. Check the inventory against the systems that administer or log the CDE, and record each one's function as Requirement 12.5.1 expects.
Flat networks assumed to be segmented
A VLAN label or a separate subnet does not isolate the CDE by itself. If firewall rules or other controls allow broad traffic between the payment network and corporate networks, the corporate systems stay in scope. Confirm the segmentation controls with a test of traffic in both directions, and keep the result for the segmentation penetration test required under Requirement 11.4.5.
Stray card data in logs and email
Primary account numbers often appear in application debug logs, support tickets, exported spreadsheets, chat transcripts and mailboxes. Each copy creates a location that must be known, protected and included in scope. Run discovery scans on file shares, log stores and mail systems, then remove the data or bring the location into scope and document its controls.
Undocumented third-party connections
Vendor remote support tools, managed monitoring agents, payment gateway APIs and file transfer links can reach into the CDE without appearing in the network diagram or the inventory. Requirement 12.5.2 requires the entity to identify third-party connections during each scope confirmation. Keep a register of every connection with its owner, purpose, direction, access method and the approval on record.
Diagrams that lag behind change
Network and data-flow diagrams are accurate only if they are updated when the environment changes. Requirements 1.2.3 and 1.2.4 expect diagrams that show all connections to the CDE and all account data flows. Treat a new service, a changed firewall rule or a new storage location as a trigger for diagram updates and a scope review, since significant changes under FAQ 1317 call for one.
Encryption mistaken for removal from scope
Strong encryption of cardholder data satisfies Requirement 3.5.1, but the encrypted data and the systems that hold the keys usually remain in scope. Teams often assume that encrypted storage or a database field can be left out of the review. Before excluding any system, confirm with the assessor how the data is handled and where the keys and decryption paths sit.
Who owns scope, who prepares it and who validates it
The organization owns the scope decision. Only the entity itself can declare what is in its cardholder data environment (CDE), and Requirement 12.5.2 makes that entity responsible for confirming scope at least every 12 months and after significant change. Under the same requirement, service providers must confirm scope every six months. Confirmation means identifying data flows, locations of account data, connected components, segmentation controls and third-party connections, and it must be recorded in a form the organization can hand to an assessor. Assign a named owner in the company, usually from security or compliance, who signs off the boundary and keeps it current. An outside party can advise, but it cannot take over that decision.
An implementation partner such as DeployOpen can prepare the material the scope decision depends on. In practice this means drafting the network diagram required by Requirement 1.2.3, the account data flow diagram required by Requirement 1.2.4, the inventory of in-scope system components required by Requirement 12.5.1, and the segmentation configuration with the test support needed to show that the segmentation works. Ask the partner to state in writing which artifacts it produces, which the organization must review and approve, and which records it expects your team to keep current after the engagement ends. The partner prepares evidence. It does not issue reports or attestations.
A QSA or other independent assessor reviews the scope and validation method. For a Report on Compliance, the QSA performs the assessment and issues the ROC. For a Self-Assessment Questionnaire, the entity completes the SAQ and its Attestation of Compliance, and the QSA's role depends on the SAQ type and the payment brand rules that apply. Only the assessor or the entity itself signs the report or attestation, and no partner can do so. Independence also matters for testing. If the partner designed the segmentation, it should not be the only party that tests it under Requirement 11.4.5. Confirm with your QSA whether the partner's involvement affects its independence, and agree the segmentation test scope with both parties before fieldwork begins.
Common questions about PCI DSS scope and segmentation
Does segmentation remove systems from PCI DSS scope?
Segmentation can reduce scope, but it does not remove a system by itself. Segmentation controls isolate the cardholder data environment (CDE) from other networks, and systems outside that boundary can be out of scope only if the controls work as designed and are tested. The PCI SSC glossary defines the CDE as the people, processes and system components that store, process or transmit cardholder data or sensitive authentication data, plus any component with unrestricted connectivity to them. Any system that could affect the security of the CDE stays in scope. Under Requirement 11.4.5, segmentation controls must be penetration tested at least every 12 months and after changes, so the reduction must be proven, not assumed.
How often must PCI DSS scope be confirmed?
Your organization must confirm PCI DSS scope at least every 12 months and after any significant change. Under Requirement 12.5.2, the entity identifies data flows, account data locations, connected components, segmentation controls and third-party connections during that review. Service providers must confirm scope every six months under Requirement 12.5.2.1. PCI SSC FAQ 1317 lists triggers for a review, including new CDE hardware or software, changes to data flows or storage, and changes to the CDE boundary or supporting infrastructure. Ask your assessor which scope confirmation evidence they expect to see for the current year, and keep the inventory and network and data-flow diagrams current between reviews.
Does encrypting card data take it out of PCI DSS scope?
No. Encryption with strong cryptography meets Requirement 3.5.1 for protecting stored account data, but PCI SSC FAQ 1086 states that encryption alone does not take the data out of scope. The systems that hold the encryption keys, perform encryption and decryption, and handle the data in clear text remain in scope. PCI SSC FAQ 1089 makes a similar point for hashing: hashed PAN moved to a separate environment is no longer cardholder data there, but the systems that perform the hashing stay in scope. Encryption is a control that protects data within scope, and scope reduction requires removing the data or the systems from the environment, which is a separate design decision. Confirm the treatment of key management systems with your assessor before you design around encryption.
What does segmentation testing need from our internal staff?
Internal staff must provide accurate scope inputs and access, while a qualified tester performs the segmentation test. Your team typically needs to supply current network and data-flow diagrams (Requirements 1.2.3 and 1.2.4), a complete inventory of in-scope system components with their function (Requirement 12.5.1), and a list of the segmentation controls and their rules. Staff should also be ready to explain changes made since the last test, provide test accounts or access paths the tester requests, and confirm which systems are isolated. Ask your penetration tester to define their methodology and the qualifications and independence they meet, and confirm with your assessor which segmentation testing evidence they will accept.
Can DeployOpen confirm our PCI DSS scope for a QSA?
DeployOpen can prepare the scope evidence, but the QSA decides whether scope is correct. DeployOpen is an implementation and testing company that prepares systems, controls and evidence for compliance assessments. It does not issue audit reports, attestations or certifications, and it does not act as the assessor. Under the PCI SSC rules, the Report on Compliance and the Attestation of Compliance come from a Qualified Security Assessor, and an assessor will test the scope boundary independently. Work that DeployOpen might prepare includes diagrams, asset inventories, segmentation documentation and test readiness. Confirm with your QSA which artifacts they need and whether they accept materials prepared by a third party.
What drives the effort of defining and testing PCI DSS scope?
The effort depends mainly on how many systems and data flows touch the cardholder data environment and how often they change. Key drivers include the number of connected systems and third-party connections, the number of locations where account data is stored or processed, whether you run cloud or containerized environments with ephemeral workloads, and how mature your existing inventory and diagrams are. Frequent changes raise the effort because each significant change can trigger a scope review. The PCI SSC published a 9 September 2024 information supplement on scoping and segmentation for modern architectures, covering zero trust, micro-segmentation and multi-cloud, which is useful when defining the boundary. When requesting a quote, ask for the scope inputs assumed, the number of tests per year and who performs each activity.
How DeployOpen prepares scope evidence for your assessment
DeployOpen plans, implements and documents the self-hosted open-source platforms that sit inside your cardholder data environment, and prepares the scope evidence your team and assessor will review. DeployOpen does not issue reports or attestations; your QSA or the applicable validation body decides the final scope.
How we scope
- Written scope agreed before work starts, naming the systems, networks and segments in the review
- Mapping of account data flows, storage locations and connected components for your environment
- Confirmation of which validation method applies, so the scope work matches what your assessor will test
How we build
- Segmentation controls implemented in your own cloud accounts, data centers or networks, with rules documented as they are deployed
- Network and data-flow diagrams kept current with each change, including the inventory of in-scope system components
- Segmentation testing prepared with your penetration testing provider, with results mapped back to the controls they check
How we hand over
- Scope documentation package covering boundaries, justifications for out-of-scope systems and the evidence behind each decision
- Change-triggered scope review procedure so your team can recognize significant changes and record their impact
- Runbooks and training so your staff can maintain the scope evidence after the engagement ends
How we support
- Ongoing support available as a retainer for scope reviews, segmentation changes and evidence refreshes
- Support for responding to assessor questions about data flows, segmentation and system inventory
- Periodic re-testing and documentation updates scheduled around your annual and six-monthly scope confirmation cycles
