PCI DSS Scoping and Segmentation Design: [Entity or environment name]

Design and evidence document for the scope of a PCI DSS assessment: payment channels, account data flows, the inventory of system components, how each component is categorised, the segmentation that keeps other systems out of scope, the tests that prove it, scope reduction through tokenisation, point-to-point encryption and outsourced payment pages, third-party service provider responsibilities, targeted risk analyses and the yearly scope confirmation. Structure aligned with PCI DSS v4.0.1 (June 2024, the only active version of the standard) and the PCI SSC information supplements on scoping and network segmentation. Requirement numbers are cited; requirement text is not reproduced. Replace every [bracketed] value and every row marked Example. This is a documentation format, not legal or assessment advice: your Qualified Security Assessor (QSA), acquirer or payment brand decides what is acceptable.

Document control

Approvals

Revision history

Contents

1. Purpose, basis and summary
2. Entity profile and validation context
3. Payment channels and account data flows
4. Account data inventory
5. Scoping method and categories
6. System component inventory and scope register
7. Scope reduction strategy
8. Segmentation architecture
9. Segmentation and scope testing
10. Third-party service providers
11. Targeted risk analyses and customized approach
12. Scope confirmation and change triggers
13. Evidence register and traceability
14. Risks, exceptions and open issues
15. Glossary and references

1. Purpose, basis and summary

1.1 Purpose

This document defines and justifies the PCI DSS scope of [Entity]. It is the working record the assessor reviews at the start of each assessment and the source the security team uses to decide whether a new system, connection or supplier changes scope. It covers all locations, channels and system components that store, process or transmit account data, or that can affect its security.

1.2 Basis

Future-dated requirements introduced in v4.0 became effective on 31 March 2025 and now apply in full. PCI DSS v4.0 was retired on 31 December 2024. Check the PCI SSC Document Library for the current version, FAQs and any later revision before each assessment.

1.3 Scope summary

2. Entity profile and validation context

Responsibility for scope sits with the assessed entity. The assessor validates scope; the assessor does not define it. Record who in the entity signs off the scope in section 12.

2.1 RACI for scope

R responsible, A accountable, C consulted, I informed.

3. Payment channels and account data flows

3.1 Channel register

3.2 Data flow diagram

The diagram shows the designed paths in the worked example; dashed or missing paths are findings to resolve.

3.3 Flow register

3.4 Data discovery

Run a data discovery exercise to find account data that flows outside the designed paths. Record tool, coverage and findings. Unexpected account data found anywhere brings that system into scope until it is removed and the cause is fixed.

4. Account data inventory

State explicitly whether any token can be de-tokenised by the entity. If the entity, or any system it controls, can call a de-tokenisation function, the systems with that capability are in scope.

5. Scoping method and categories

5.1 Categories

5.2 Decision questions

Record the answer to each question in the scope register (section 6). "Connectivity" includes indirect paths: a management agent, a shared identity provider, a shared hypervisor, a peered network, a site-to-site VPN or a remote support tool all count.

5.3 Treatment rules

• A system that can change CDE configuration (configuration management, CI/CD, infrastructure as code pipeline, cloud console with privileges) is security-impacting even if it never sees account data.
• An administrator workstation used to reach the CDE is in scope. Either harden it as a connected-to system or use a dedicated jump host and keep general workstations out.
• A shared service used by both CDE and out-of-scope systems (directory, time, DNS, logging, antivirus console) is connected-to. Its clients outside the CDE stay out of scope only if the shared service cannot become a path between them and the CDE.
• Cloud provider control planes are covered through the provider's attestation and the responsibility matrix (section 10), not by assessing the provider yourself.

6. System component inventory and scope register

Totals: CDE [n], connected-to or security-impacting [n], out of scope [n]. Reconcile the totals against the CMDB at each confirmation.

7. Scope reduction strategy

7.1 Decision criteria for each technique

1. Does the technique remove account data from entity systems, or only hide it? Masking on screen is not removal.
2. Who holds the keys or de-tokenisation ability? If it is the entity, the vault and its clients stay in scope.
3. Is the provider validated for the service it performs (AOC covering that service, P2PE listing for that solution and version)?
4. What residual requirements stay with the entity, and are they named in the responsibility matrix (12.8.5)?
5. What is the fallback when the provider is unavailable? A manual fallback that writes card numbers on paper reverses the reduction.

8. Segmentation architecture

8.1 Zone model

Crossed arrows mark flows that must be denied and tested in section 9.

8.2 Segmentation control register

8.3 Design rules

• Default deny at every boundary; every allowed flow has a business justification, owner and review date (1.2.5).
• Keep NSC configuration as code, with peer review and automated drift detection, so configuration matches the approved design (1.2.2, 1.2.8).
• Do not rely on routing or VLANs alone. Use a control that enforces policy on the traffic.
• Shared identity: give CDE and connected-to administration separate privileged roles with MFA for all CDE access (8.4.2). A corporate directory compromise must not grant CDE access.
• Cloud: one account, subscription or project per zone where possible; block peering and private endpoints that bypass the inspection point; monitor for new network paths.
• Remote access: no direct remote access to the CDE; use jump hosts with MFA and session logging.
• Devices that connect to both untrusted networks and the CDE (for example laptops of administrators) need the controls of 1.5.1.

8.4 Modern architectures

For zero trust, service mesh and micro-segmentation designs, document the identity-based policy that replaces network zones, the policy decision point, how policy is versioned and how a test can show that an out-of-scope workload cannot reach a CDE workload. For ephemeral cloud workloads, inventory the template or image and the policy that applies to every instance, and how instances are prevented from starting outside that policy.

9. Segmentation and scope testing

9.1 Test plan

9.2 Results

A failed test means the systems behind the failed path are in scope from the date of the failure until a retest passes (record it in section 14). Between formal tests, run automated reachability analysis on every NSC or cloud network change and alert on new paths into CDE zones; this supports but does not replace the 11.4.5 penetration test.

10. Third-party service providers

10.1 Responsibility matrix extract

Use the Supplier Security Assessment (compliance/supplier-security-assessment) for due diligence on each new TPSP before contract (12.8.3).

11. Targeted risk analyses and customized approach

11.1 Frequency TRAs (12.3.1)

11.2 Customized approach (12.3.2, Appendix D)

The customized approach is available for ROC assessments, not for SAQs. Use the controls matrix and TRA templates published on the PCI SSC website (moved from Appendix E in v4.0.1), and agree the approach with your QSA before the assessment period.

12. Scope confirmation and change triggers

12.1 Confirmation record

Confirmed by: [@name], YYYY-MM-DD. Next due: YYYY-MM-DD.

12.2 Significant change triggers

Add a mandatory "PCI DSS scope impact" question to the Change Request (ops/change-request) process.

13. Evidence register and traceability

13.1 Traceability matrix

14. Risks, exceptions and open issues

Record risks in the Risk Register (compliance/risk-register) and treatment in the Risk Treatment Plan (compliance/risk-treatment-plan).

15. Glossary and references

15.1 Glossary

15.2 References

Standard and licence note

Structure aligned with PCI DSS v4.0.1 (PCI Security Standards Council, June 2024) and the PCI SSC information supplements on scoping and network segmentation. PCI DSS and its supplements are copyrighted by PCI Security Standards Council, LLC; this template cites requirement numbers only and describes them in original words, and no requirement text, testing procedure, table or diagram from PCI SSC documents is reproduced. Obtain the standard and supporting documents from the PCI SSC Document Library and check the current version, FAQs and SAQ revisions before use. PCI DSS is a trademark of PCI Security Standards Council, LLC; this template is not affiliated with or endorsed by PCI SSC. This is a documentation format, not legal or assessment advice. Template licence: MIT.