# 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.

<!--
Guidance: How to use this template
- Write one scoping document per assessed entity (merchant or service
  provider). Keep it current: Requirement 12.5.2 expects scope to be
  documented and confirmed at least once every 12 months and after any
  significant change (every six months for service providers under
  12.5.2.1).
- Start with the payment channels and data flows (sections 3 and 4).
  Scope follows the data, not the network diagram. A system is in scope
  because of what it stores, processes, transmits or can affect, never
  because of the subnet it sits in.
- Treat "out of scope" as a claim that needs proof. Every out-of-scope
  category in section 5 must point to a segmentation control in section
  8 and a passing test in section 9.
- Do not copy requirement text from the standard into this file. Cite
  the requirement number and describe your own implementation.
- Related documents: Security Architecture
  (`security/security-architecture`), Network Architecture Design
  (`architecture/network-architecture-design`), Asset Inventory
  (`compliance/asset-inventory`), Supplier Security Assessment
  (`compliance/supplier-security-assessment`), Risk Register
  (`compliance/risk-register`), Penetration Test Report
  (`security/pentest-report`), Incident Response Plan
  (`compliance/incident-response-plan`), Payment Ledger Design
  (`system-design/design-payment-ledger`).
-->

## Document control

<!-- Guidance: Identify the assessed entity, the assessment type and the people who own scope. A change to payment channels, data storage or segmentation method is a new major version. -->

| Field | Value |
|---|---|
| Document ID | [PCI-SCOPE-001] |
| Assessed entity | [Legal name, DBA] |
| Entity type | [Merchant / Service provider / Both] |
| Validation type | [Report on Compliance (ROC) by QSA / Self-Assessment Questionnaire (SAQ) type] |
| PCI DSS version and assessment period | v4.0.1; YYYY-MM-DD to YYYY-MM-DD |
| QSA company and lead assessor | [Name] |
| Acquirer or payment brands | [Names] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@pci-programme-lead] |
| Approvers/reviewers | [@ciso], [@network-lead], [@payments-product-owner], [@internal-audit] |
| Classification | [Confidential] |
| Last updated | YYYY-MM-DD |
| Next scope confirmation due | YYYY-MM-DD |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Executive sponsor for PCI DSS | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| CISO | [@name] | [Decision] | YYYY-MM-DD |
| Network and platform owner | [@name] | [Decision] | YYYY-MM-DD |
| Payments business owner | [@name] | [Decision] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved scope for the annual ROC; segmentation test SEG-T-2026-01 passed |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* Contact centre moved to DTMF masking; agent desktops reclassified out of scope after retest |

## Contents

<!-- Guidance: Keep this list aligned with the headings below. -->

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

## 1. Purpose, basis and summary

<!-- Guidance: State in a few lines what this document decides: the boundary of the cardholder data environment (CDE), what is kept out of it and how that is proven. Write the summary last. -->

### 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

| Source | Use in this document |
|---|---|
| PCI DSS v4.0.1 (PCI SSC, June 2024) | Scoping section of the standard; Requirements 1, 2.2.3, 11.4, 12.3, 12.5, 12.8, 12.9; Appendices A1 and D |
| PCI SSC Information Supplement: Guidance for PCI DSS Scoping and Network Segmentation (December 2016, version 1.0) | Scope categories and segmentation verification concepts |
| PCI SSC Information Supplement: PCI DSS Scoping and Segmentation Guidance for Modern Network Architectures (published September 2024) | Zero trust, micro-segmentation, multi-cloud and ephemeral workloads |
| [Internal network and data classification standards] | Zone model and data handling |

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

| Item | Value |
|---|---|
| Payment channels in scope | *Example:* E-commerce (hosted payment fields), contact centre (telephone), 120 stores (card-present) |
| Locations where account data is stored | *Example:* Partner batch files held encrypted until authorisation, then deleted (24 hours maximum); tokens only elsewhere |
| CDE components | *Example:* 14 (store POI devices counted as one class) |
| Connected-to or security-impacting components | *Example:* 31 |
| Segmentation method | *Example:* Cloud security groups and network firewalls between VPCs; store network segmented by SD-WAN policy; DTMF masking removes contact centre from CDE |
| Scope reduction in use | *Example:* PSP tokenisation, listed P2PE solution in stores, PSP-hosted payment fields |

## 2. Entity profile and validation context

<!-- Guidance: Record the facts that decide which validation route applies and who is accountable. Your acquirer or the payment brands set merchant levels; service provider levels come from brand programmes. Quote the source of the level, not a number from memory. -->

| Field | Value |
|---|---|
| Business description | [What the entity sells or provides] |
| Merchant level or service provider level | [Level], source: [acquirer letter / brand programme, date] |
| Annual transaction volume by brand and channel | [Figures] |
| Validation route | [ROC / SAQ A / SAQ A-EP / SAQ B-IP / SAQ C-VT / SAQ P2PE / SAQ D] |
| Service provider services in scope (if any) | [Hosting, payment processing, managed security] |
| Multi-tenant service provider (Appendix A1) | [Yes / No] |
| Designated Entities Supplemental Validation (Appendix A3) | [Required by acquirer or brand / Not required] |

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

| Activity | PCI lead | Network lead | Application owners | Security operations | Procurement | Executive sponsor |
|---|---|---|---|---|---|---|
| Maintain data flow diagrams (1.2.4) | A | C | R | C | I | I |
| Maintain network diagrams (1.2.3) | A | R | C | C | I | I |
| Maintain component inventory (12.5.1) | A | R | R | C | I | I |
| Classify components (section 5) | R | C | C | C | I | A |
| Operate segmentation controls | C | R | I | C | I | I |
| Commission segmentation tests (11.4.5) | R | C | I | C | C | A |
| Maintain TPSP list and responsibility matrix (12.8) | R | I | C | I | R | A |
| Confirm scope (12.5.2) | R | C | C | C | C | A |

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

## 3. Payment channels and account data flows

<!-- Guidance: Draw every path account data takes, from the cardholder to authorisation, settlement, refunds, chargebacks and disputes. Include the human paths: phone calls, email, paper, screenshots, call recordings. Requirement 1.2.4 expects data-flow diagrams for all account data flows across systems and networks. Pitfall: drawing only the authorisation path and forgetting refunds and chargebacks. -->

### 3.1 Channel register

| ID | Channel | Description | Who touches account data | Account data at rest in entity? |
|---|---|---|---|---|
| CH-01 *(Example)* | E-commerce | Checkout page on entity website embeds PSP-hosted payment fields; PSP returns a token | Cardholder browser and PSP only | No (token only) |
| CH-02 *(Example)* | Contact centre | Agent takes orders by phone; caller keys card number on phone keypad; DTMF masking service sends digits to PSP | Masking provider and PSP | No |
| CH-03 *(Example)* | Stores | P2PE-validated terminals encrypt at the point of interaction; decryption at P2PE provider | Cardholder and terminal | No |
| CH-04 *(Example)* | Refunds and disputes | Back office refunds by token through PSP portal; chargeback evidence downloaded from acquirer portal shows truncated PAN only | Finance staff (truncated PAN) | Truncated PAN only |
| CH-05 *(Example)* | Exception path | Customer emails card details unsolicited | Customer service mailbox | Possible (unsolicited) |
| CH-06 *(Example)* | B2B partner orders | Corporate partner sends nightly order files with PAN by SFTP; the payment API authorises them through the PSP and deletes the file | Payment API (CDE) | Transient, encrypted |

### 3.2 Data flow diagram

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

```mermaid
flowchart LR
  CH["Cardholder"] -->|"Card data in browser iframe"| PSP["PSP hosted fields"]
  CH -->|"Keypad tones"| DTMF["DTMF masking service"]
  CH -->|"Card at terminal"| POI["P2PE terminal"]
  DTMF -->|"Card data"| PSP
  POI -->|"Encrypted data"| P2PE["P2PE decryption provider"]
  P2PE --> ACQ["Acquirer"]
  PSP --> ACQ
  PSP -->|"Token and result"| WEB["Checkout service"]
  WEB --> ORD["Order database (tokens)"]
  FIN["Finance back office"] -->|"Refund by token"| PSP
  PTN["B2B partner"] -->|"SFTP order files with PAN"| API["Payment API (CDE)"]
  API -->|"Authorisation, then tokens"| PSP
```

### 3.3 Flow register

| ID | From | To | Data elements | Protocol and protection | Stage | Owner |
|---|---|---|---|---|---|---|
| FLOW-001 *(Example)* | Cardholder browser | PSP hosted fields | PAN, expiry, CVC | TLS 1.2 or later, PSP domain (4.2.1 met by PSP) | Authorisation | PSP |
| FLOW-002 *(Example)* | PSP | Checkout service | Token, last four digits, result | TLS mutual authentication over API | Authorisation | Payments team |
| FLOW-003 *(Example)* | Store terminal | P2PE provider | Encrypted account data | P2PE solution encryption | Authorisation | Store operations |
| FLOW-004 *(Example)* | Phone network | DTMF masking service | PAN, expiry, CVC as tones | Masking provider platform | Authorisation | Contact centre |
| FLOW-005 *(Example)* | Finance user | PSP portal | Token, refund amount | TLS, MFA on portal | Refund | Finance |
| FLOW-006 *(Example)* | B2B partner | Payment API | PAN, expiry, cardholder name | SFTP with key authentication; files PGP-encrypted; partner IP allow list | Authorisation | Payments team |

### 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.

| Discovery run | Coverage | Findings | Action |
|---|---|---|---|
| DISC-2026-01 *(Example)* | File shares, mailboxes, ticketing, data lake, logs | 3 tickets containing full PAN pasted by agents | Purged; ticketing redaction rule added; agent training; retest clean |

## 4. Account data inventory

<!-- Guidance: List each element of account data, where it exists, for how long and how it is protected. Sensitive authentication data must not be stored after authorisation (3.3.1) unless a documented issuer exception applies. Pitfall: forgetting logs, crash dumps, analytics events and call recordings. -->

| Element | Present in entity systems? | Locations | Retention and justification (3.2.1) | Protection (3.5.1) |
|---|---|---|---|---|
| Primary account number (PAN) | *Example:* Full PAN transiently; truncated to a brand-approved format (for example first six, last four) for disputes | Payment API file store (full, until authorisation); order database and acquirer reports (truncated) | Full: deleted after authorisation, 24 hours maximum; truncated: 18 months for disputes | Full: strong encryption with keys in HSM-backed KMS; truncated: truncation |
| Cardholder name | *Example:* Yes, from order form | Order database | Order record life | Not account data in isolation; treated as confidential |
| Expiry date | *Example:* No | None | Not stored | Not applicable |
| Full track data | *Example:* No | None (P2PE) | Never stored | Not applicable |
| Card verification code | *Example:* No | None | Never stored after authorisation | Masked in contact centre |
| PIN or PIN block | *Example:* No | None | Never stored | P2PE terminal |
| Tokens | *Example:* Yes | Order database, finance tools | Order record life | Token cannot be used to derive PAN by the entity |

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

<!-- Guidance: Define the categories you use and the questions that place a component in each. The categories below follow the concepts in the PCI SSC scoping supplement, described in original words. Apply the same decision questions to every component, including cloud services and SaaS tools. -->

### 5.1 Categories

| Category | Meaning in this document | PCI DSS applies |
|---|---|---|
| CDE system | Stores, processes or transmits account data, or sits on the same network segment as such a component without isolation | All applicable requirements |
| Connected-to or security-impacting system | Has any connectivity to a CDE system, or can affect the security of the CDE (for example identity, logging, patching, DNS, jump hosts, CI/CD that deploys into the CDE) | The requirements relevant to the connection or function |
| Out-of-scope system | Has no access to account data, no connectivity to the CDE and cannot affect its security; proven by segmentation tests | None, but must remain isolated |

### 5.2 Decision questions

```mermaid
flowchart TD
  Q1{"Stores, processes or transmits account data?"} -->|Yes| CDE["CDE system"]
  Q1 -->|No| Q2{"Same segment as a CDE system without isolation?"}
  Q2 -->|Yes| CDE
  Q2 -->|No| Q3{"Any connectivity to a CDE system?"}
  Q3 -->|Yes| CON["Connected-to or security-impacting"]
  Q3 -->|No| Q4{"Can it affect CDE security or configuration?"}
  Q4 -->|Yes| CON
  Q4 -->|No| OUT["Out of scope (prove with segmentation test)"]
```

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

<!-- Guidance: Requirement 12.5.1 expects an inventory of in-scope system components with a description of function or use. Keep it in the CMDB and export it here at each confirmation. Group identical components into classes only when their configuration is centrally enforced. -->

| ID | Component or class | Function | Location or account | Category | Reason (section 5.2 question) | Owner |
|---|---|---|---|---|---|---|
| PCI-ASSET-001 *(Example)* | Checkout service containers | Builds checkout page, receives tokens | Cloud account prod-payments | Connected-to | Serves the page that embeds PSP fields; script integrity in scope (6.4.3, 11.6.1) | Payments team |
| PCI-ASSET-002 *(Example)* | Order database | Stores tokens and truncated PAN | prod-payments | Out of scope after token review | No PAN; tokens not reversible by entity | Data platform |
| PCI-ASSET-003 *(Example)* | Store P2PE terminals (class, 480 units) | Card acceptance | 120 stores | CDE (P2PE solution scope) | Process account data; covered by listed P2PE solution | Store operations |
| PCI-ASSET-004 *(Example)* | Identity provider | Authenticates admins to cloud accounts | SaaS | Security-impacting | Controls access to CDE-connected accounts | IAM team |
| PCI-ASSET-005 *(Example)* | CI/CD runners for payments | Deploy checkout service | prod-tooling | Security-impacting | Can change connected-to components | Platform team |
| PCI-ASSET-006 *(Example)* | SIEM | Receives logs from in-scope components | SaaS | Security-impacting | Required for Requirement 10 | Security operations |
| PCI-ASSET-007 *(Example)* | Contact centre agent desktops | Order entry | Contact centre LAN | Out of scope | DTMF masking prevents agents from hearing or seeing card data; segmentation test SEG-T-2026-01 | Contact centre |
| PCI-ASSET-008 *(Example)* | Payment API and partner file store | Receives partner files, authorises, deletes | Cloud account prod-cde | CDE | Stores and processes PAN | Payments team |
| PCI-ASSET-009 *(Example)* | Customer service mailbox | Receives customer email, including unsolicited card details (CH-05) | SaaS mail tenant | CDE until proven clean | Can receive PAN; stays in scope until the purge-and-block rule is proven by data discovery (section 3.4) | Customer service |

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

<!-- Guidance: List each technique, what it removes from scope, what remains and what evidence the assessor will expect. Scope reduction moves requirements to a provider; it never removes your duty to manage that provider (12.8) or the parts of the flow you still control. -->

| ID | Technique | Scope effect | What remains in scope for the entity | Evidence |
|---|---|---|---|---|
| RED-01 *(Example)* | Tokenisation by PSP | Order and finance systems hold tokens, not PAN | Proof that entity cannot de-tokenise; TPSP management of the PSP | PSP AOC; token design statement; de-tokenisation access review |
| RED-02 *(Example)* | PCI-listed P2PE solution in stores | Store network carries only encrypted data; store LAN out of scope | Terminal inventory, inspection and tamper checks per the P2PE Instruction Manual; SAQ P2PE eligibility where applicable | P2PE listing, PIM, inventory records |
| RED-03 *(Example)* | PSP-hosted payment fields (iframe) | Checkout service never receives PAN | Integrity of the page that embeds the fields: script inventory and authorisation (6.4.3), change and tamper detection (11.6.1) for ROC or SAQ A-EP; SAQ A eligibility includes confirming the site is not susceptible to script attacks (the January 2025 SAQ A removes 6.4.3, 11.6.1 and the related 12.3.1 from the questionnaire and adds this eligibility criterion instead; the underlying requirements are unchanged) | Script inventory, CSP and SRI configuration, tamper-detection alerts |
| RED-04 *(Example)* | DTMF masking in contact centre | Agents, desktops, call recordings out of scope | Masking provider as TPSP; procedure for callers who read numbers aloud | Provider AOC; call flow test; recording sample review |
| RED-05 *(Example)* | Data retention reduction | No stored PAN beyond truncated form, except transient partner files | Discovery scans (section 3.4) | Discovery reports |

### 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

<!-- Guidance: Describe each boundary between the CDE, connected-to systems and out-of-scope systems, the network security controls (NSCs) that enforce it and the rules that pass through. Requirement 1 covers NSC configuration (1.2), restricting access to and from the CDE (1.3), controlling trusted and untrusted networks (1.4) and devices that connect to both (1.5). Segmentation is not mandatory, but without it the whole flat network is in scope. -->

### 8.1 Zone model

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

```mermaid
flowchart TB
  subgraph UNTRUSTED["Untrusted: internet, phone network"]
    U1["Customers"]
    U2["B2B partner"]
  end
  subgraph CDEZ["CDE zone"]
    C1["Payment API and partner file store"]
  end
  subgraph CONZ["Connected-to zone"]
    K1["Checkout service"]
    K2["Jump hosts"]
    K3["Identity, logging, CI/CD"]
  end
  subgraph OUTZ["Out-of-scope zone"]
    O1["Corporate LAN"]
    O2["Contact centre desktops"]
  end
  U1 --> K1
  U2 -->|"SFTP from partner IPs only"| C1
  K2 -->|"Admin protocols, MFA"| C1
  K3 -.->|"Logs, identity"| C1
  O1 -.-x|"Denied"| C1
  O2 -.-x|"Denied"| C1
```

### 8.2 Segmentation control register

| ID | Boundary | Control type | Enforcement point | Default rule | Allowed exceptions | Req. | Review cycle (1.2.7) |
|---|---|---|---|---|---|---|---|
| PCI-SEG-001 *(Example)* | Out-of-scope VPCs to payments VPCs | Cloud security groups and network firewall | Transit gateway inspection VPC | Deny all | None | 1.3.1, 1.3.2 | Every six months |
| PCI-SEG-002 *(Example)* | Connected-to to CDE | Security groups | Payment API ENIs | Deny all | SSH from jump hosts; log forwarding to SIEM; deployment from CI/CD runners | 1.2.5, 1.3.1 | Every six months |
| PCI-SEG-003 *(Example)* | Internet to connected-to | WAF and load balancer | Edge | Deny all | HTTPS 443 | 1.4.1, 1.4.2 | Every six months |
| PCI-SEG-004 *(Example)* | Store LAN to head office | SD-WAN policy | Store edge device | Deny all | Encrypted P2PE traffic to provider; store systems management | 1.3.1, 1.4.1 | Every six months |
| PCI-SEG-005 *(Example)* | Contact centre LAN to payments | Firewall | Head office core | Deny all | None | 1.3.1 | Every six months |
| PCI-SEG-006 *(Example)* | Workload isolation inside the CDE account | Host-based micro-segmentation | Workload agent | Deny all | Defined service-to-service flows | 1.2.1, 2.2.3 | Every six months |
| PCI-SEG-007 *(Example)* | Internet to CDE | Network firewall and SFTP gateway | prod-cde edge | Deny all | SFTP from listed partner IP addresses | 1.4.1, 1.4.2, 1.4.4 | Every six months |

### 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

<!-- Guidance: Requirement 11.4.5 expects, where segmentation is used to reduce scope, penetration testing of segmentation controls at least once every 12 months and after any change to segmentation controls or methods; service providers test at least every six months under 11.4.6. The tester must be qualified and organisationally independent. Pitfall: testing only from one out-of-scope subnet; test from every out-of-scope zone toward every CDE zone. -->

### 9.1 Test plan

| Item | Value |
|---|---|
| Test ID | [SEG-T-YYYY-NN] |
| Trigger | [Annual / Change to segmentation control PCI-SEG-nnn / Service provider six-month cycle] |
| Tester and independence | [Internal team outside network operations / External firm] |
| Methodology | [Reference to the entity penetration testing methodology under 11.4.1] |
| Source zones | [Each out-of-scope zone and representative hosts] |
| Target zones | [Each CDE zone, all ports and protocols] |
| Techniques | [Port scans in both directions, protocol probes, cloud path analysis, attempted use of shared services as pivot, identity-based policy checks] |
| Pass criterion | No unapproved path from any out-of-scope or untrusted source to any CDE target, or to any connected-to target that a boundary in section 8.2 protects; isolation of mixed security levels confirmed (2.2.3) |

### 9.2 Results

| Test ID | Date | Source | Target | Result | Finding | Remediation | Retest |
|---|---|---|---|---|---|---|---|
| SEG-T-2026-01 *(Example)* | YYYY-MM-DD | Corporate LAN | Payment API | Pass | None | Not applicable | Not applicable |
| SEG-T-2026-01 *(Example)* | YYYY-MM-DD | Contact centre LAN | prod-cde account | Pass | None | Not applicable | Not applicable |
| SEG-T-2026-01 *(Example)* | YYYY-MM-DD | Store LAN | Head office and prod-cde account | Pass | Only P2PE traffic to the provider and store management flows observed | Not applicable | Not applicable |
| SEG-T-2026-01 *(Example)* | YYYY-MM-DD | Internet | Checkout service (WAF and load balancer rules) | Pass | Only HTTPS 443 reachable | Not applicable | Not applicable |
| SEG-T-2026-01 *(Example)* | YYYY-MM-DD | Internet | Payment API SFTP gateway | Pass | SFTP refused from non-listed IP addresses | Not applicable | Not applicable |
| SEG-T-2026-01 *(Example)* | YYYY-MM-DD | Analytics VPC | Checkout service | Fail | Stale peering allowed TCP 443 | Peering removed; detection rule for new peering | Pass, YYYY-MM-DD |

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

<!-- Guidance: Requirement 12.8 expects a list of third-party service providers (TPSPs) that share account data or could affect its security, written agreements, due diligence, yearly monitoring of their compliance status and a record of which requirements each TPSP manages, which the entity manages and which are shared (12.8.5). Service providers support customers under 12.9. -->

| ID | TPSP | Service | Account data or security impact | Validation evidence | Agreement (12.8.2) | Status checked (12.8.4) | Responsibility matrix (12.8.5) |
|---|---|---|---|---|---|---|---|
| PCI-TPSP-001 *(Example)* | [PSP] | Hosted fields, tokenisation, authorisation | Processes account data | AOC for service provider, version 4.0.1, dated YYYY-MM-DD | Contract clause 14 | YYYY-MM-DD | RM-001 |
| PCI-TPSP-002 *(Example)* | [P2PE provider] | P2PE solution and decryption | Processes account data | P2PE listing [reference] and AOC | Contract | YYYY-MM-DD | RM-002 |
| PCI-TPSP-003 *(Example)* | [DTMF masking provider] | Telephone payment capture | Processes account data | AOC | Contract | YYYY-MM-DD | RM-003 |
| PCI-TPSP-004 *(Example)* | [Cloud provider] | Infrastructure for connected-to zone | Security impact | AOC and provider responsibility summary | Online terms | YYYY-MM-DD | RM-004 |

### 10.1 Responsibility matrix extract

| Requirement area | PSP (RM-001) | Entity | Shared | Notes |
|---|---|---|---|---|
| 3 Protect stored account data | Yes | No | No | Entity stores tokens only |
| 4.2 Encryption in transit of PAN | Yes | No | No | Fields served from PSP domain |
| 6.4.3 Payment page scripts | No | Yes | No | Entity page embeds the fields |
| 11.6.1 Payment page tamper detection | No | Yes | No | Entity page |
| 12.10 Incident response | Yes | Yes | Yes | Contact and escalation in contract |

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

<!-- Guidance: Requirement 12.3.1 expects a targeted risk analysis (TRA) for each requirement that lets the entity choose how often to perform an activity. Requirement 12.3.2 expects a TRA for each requirement met through the customized approach. Both are reviewed at least once every 12 months. Keep the TRA short, specific and tied to evidence. -->

### 11.1 Frequency TRAs (12.3.1)

| ID | Requirement | Activity | Chosen frequency | Basis for the choice | Approved by | Review date |
|---|---|---|---|---|---|---|
| PCI-TRA-001 *(Example)* | 11.6.1 | Payment page tamper detection | Every 24 hours plus real-time CSP violation reports | Checkout changes daily; skimming attacks on e-commerce pages | [@ciso] | YYYY-MM-DD |
| PCI-TRA-002 *(Example)* | 9.5.1.2.1 | POI device inspection | Weekly in high-footfall stores, monthly elsewhere | Tamper incidents by store type; staff turnover | [@store-ops-lead] | YYYY-MM-DD |
| PCI-TRA-003 *(Example)* | 5.2.3.1 | Review of systems considered not at risk from malware | Every six months | Small population of appliances | [@security-ops] | YYYY-MM-DD |

### 11.2 Customized approach (12.3.2, Appendix D)

| ID | Requirement and objective | Control description | Why the defined approach is not used | TRA reference | Testing procedure proposed | Status |
|---|---|---|---|---|---|---|
| PCI-CA-001 *(Example)* | 1.3.1 objective (unauthorised traffic cannot enter the CDE) | Identity-based service mesh policy with mutual TLS replaces subnet firewall rules inside the CDE account | Workloads are ephemeral; IP-based rules cannot follow them | PCI-TRA-004 (12.3.2 analysis held with the controls matrix) | Policy review, attempted connection from unauthorised workload identity, log review | Agreed with QSA in scoping meeting |

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

<!-- Guidance: Requirement 12.5.2 expects scope to be documented and confirmed at least every 12 months and on significant change, covering data flows, storage locations, CDE components, connected and security-impacting components, segmentation controls and third-party connections. Service providers repeat it every six months (12.5.2.1) and review scope after significant organisational change (12.5.3). -->

### 12.1 Confirmation record

| Element checked | Source | Result | Changes since last confirmation |
|---|---|---|---|
| Account data flows for all stages (authorisation, capture, settlement, chargebacks, refunds) | Section 3 | [Confirmed / Updated] | [Summary] |
| All locations where account data is stored, processed or transmitted, including locations outside the CDE | Sections 3.4, 4 | [Result] | [Summary] |
| All CDE, connected-to and security-impacting components | Section 6 | [Result] | [Summary] |
| All segmentation controls and the environments they isolate | Sections 8, 9 | [Result] | [Summary] |
| All connections from third-party entities with access to the CDE | Section 10 | [Result] | [Summary] |
| Scope documented and signed off | Approvals | [Result] | [Summary] |

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

### 12.2 Significant change triggers

| Trigger | Action | Owner |
|---|---|---|
| New payment channel or payment method | Update sections 3 to 7; consider validation route change | Payments owner |
| New storage of account data, or change to tokenisation | Update section 4; data discovery | PCI lead |
| New network path, peering, VPN or remote access tool touching CDE zones | Update section 8; segmentation retest | Network lead |
| Change to segmentation control or method | Retest under 11.4.5 (11.4.6 for service providers) | Security testing lead |
| New or changed TPSP | Update section 10; due diligence | Procurement |
| Merger, acquisition, reorganisation | Full scope review; for service providers 12.5.3 | Executive sponsor |

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

## 13. Evidence register and traceability

<!-- Guidance: Link every scope claim to evidence the assessor can sample. Keep evidence in a controlled repository with dates and owners. -->

| Evidence ID | Requirement | Description | Location | Owner | Date |
|---|---|---|---|---|---|
| EV-001 *(Example)* | 1.2.3 | Network diagram, all CDE connections | [Repository path] | Network lead | YYYY-MM-DD |
| EV-002 *(Example)* | 1.2.4 | Data flow diagrams (section 3.2) | This document | PCI lead | YYYY-MM-DD |
| EV-003 *(Example)* | 12.5.1 | CMDB export of in-scope components | [Path] | IT operations | YYYY-MM-DD |
| EV-004 *(Example)* | 11.4.5 | Segmentation test report SEG-T-2026-01 | [Path] | Security testing | YYYY-MM-DD |
| EV-005 *(Example)* | 12.8.4 | TPSP AOC tracker | [Path] | Procurement | YYYY-MM-DD |
| EV-006 *(Example)* | 12.3.1 | TRA records PCI-TRA-001 to 003 | [Path] | CISO | YYYY-MM-DD |
| EV-007 *(Example)* | 12.5.2 | Signed scope confirmation | This document, section 12 | PCI lead | YYYY-MM-DD |

### 13.1 Traceability matrix

| Flow | Components | Segmentation control | Test | TPSP | Evidence |
|---|---|---|---|---|---|
| FLOW-001 *(Example)* | PCI-ASSET-001 | PCI-SEG-003 | SEG-T-2026-01 | PCI-TPSP-001 | EV-002, EV-004 |
| FLOW-002 *(Example)* | PCI-ASSET-001, PCI-ASSET-002 | PCI-SEG-001, PCI-SEG-003 | SEG-T-2026-01 | PCI-TPSP-001 | EV-002, EV-004 |
| FLOW-003 *(Example)* | PCI-ASSET-003 | PCI-SEG-004 | SEG-T-2026-01 | PCI-TPSP-002 | EV-002, EV-005 |
| FLOW-004 *(Example)* | PCI-ASSET-007 | PCI-SEG-005 | SEG-T-2026-01 | PCI-TPSP-003 | EV-004, EV-005 |
| FLOW-005 *(Example)* | Finance tools (tokens only) | Not applicable (PSP portal over internet with MFA) | Not applicable | PCI-TPSP-001 | EV-005 |
| FLOW-006 *(Example)* | PCI-ASSET-008 | PCI-SEG-002, PCI-SEG-007 | SEG-T-2026-01 | PCI-TPSP-001 | EV-001, EV-004 |

## 14. Risks, exceptions and open issues

<!-- Guidance: Record anything that could expand scope or invalidate a scope claim, with an owner and a date. Link each to the risk register. -->

| ID | Description | Effect on scope | Treatment | Owner | Due | Risk register link |
|---|---|---|---|---|---|---|
| PCI-RISK-001 *(Example)* | Agents could write card numbers on paper when DTMF masking is down | Contact centre back in scope | Fallback: transfer caller to PSP IVR; clear-desk checks | Contact centre lead | YYYY-MM-DD | RISK-042 |
| PCI-RISK-002 *(Example)* | Analytics tag manager on checkout page loads third-party scripts | Script tampering risk on payment page | Remove tag manager from payment page; CSP allow list | Web lead | YYYY-MM-DD | RISK-043 |
| PCI-RISK-003 *(Example)* | Shared identity provider used for corporate and CDE admin | Directory compromise could reach CDE | Separate admin tenant or conditional access for CDE roles | IAM lead | YYYY-MM-DD | RISK-044 |

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

## 15. Glossary and references

<!-- Guidance: Define terms for readers outside the payments team, and list the exact versions consulted. -->

### 15.1 Glossary

| Term | Meaning in this document |
|---|---|
| Account data | Cardholder data and sensitive authentication data together |
| Cardholder data | PAN, plus cardholder name, expiry date and service code when present with the PAN |
| Sensitive authentication data (SAD) | Security data used to authenticate cardholders or authorise transactions, such as full track data, card verification codes and PINs |
| CDE | Cardholder data environment: the systems, and the processes and staff around them, that handle account data, together with components that can reach them without restriction |
| NSC | Network security control: firewall, security group, cloud policy or other device that enforces network policy |
| TPSP | Third-party service provider that stores, processes or transmits account data for the entity, or can affect its security |
| AOC | Attestation of Compliance issued after a PCI DSS assessment |
| P2PE | Point-to-point encryption solution validated and listed by PCI SSC |
| TRA | Targeted risk analysis under Requirement 12.3.1 or 12.3.2 |

### 15.2 References

| Reference | Version or date | Use |
|---|---|---|
| PCI DSS, PCI Security Standards Council | v4.0.1, June 2024 | Requirement numbers and structure |
| Information Supplement: Guidance for PCI DSS Scoping and Network Segmentation, PCI SSC | Version 1.0, December 2016 | Scope categories |
| Information Supplement: PCI DSS Scoping and Segmentation Guidance for Modern Network Architectures, PCI SSC | Published September 2024 (no version number stated) | Zero trust and cloud scoping |
| Self-Assessment Questionnaire A, PCI SSC | Revision of January 2025, effective 31 March 2025 | SAQ A eligibility |
| PCI P2PE Standard and listed solutions, PCI SSC | Check the current version | Scope reduction in stores |

## 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.