Compliance Framework Alignment
PCI DSS v4.0.1 — Req 12.5.1 (inventory of in-scope system components) PCI DSS v4.0.1 — Req 12.5.2 (annual scope confirmation; 12.5.2.1 six-monthly for service providers) PCI DSS v4.0.1 — Req 1.2.3 (accurate network diagram) PCI DSS v4.0.1 — Req 1.2.4 (cardholder-data-flow diagram) PCI DSS v4.0.1 — Req 3.3.1 (sensitive authentication data not stored after authorisation) This is a customisable template to help document PCI DSS scope; it is not a compliance certification or professional advice, and it does not reproduce the copyrighted text of the PCI DSS standard or PCI SSC forms. Confirm scope against your validated assessment and, where required, your QSA.
ACME PAYMENTS PVT LTD PCI DSS CARDHOLDER DATA ENVIRONMENT (CDE) SCOPE & DATA-FLOW
Effective Date [Effective Date]
Standard PCI DSS v4.0.1
Entity Type Merchant
Validation Route Self-Assessment Questionnaire (SAQ) 1. Purpose and Scope
This document defines the boundary of the cardholder data environment (CDE) operated by Acme Payments Pvt Ltd and records the systems, people and processes that are in scope for PCI DSS v4.0.1. It supports the applicable Self-Assessment Questionnaire (SAQ) by identifying every system component that stores, processes or transmits account data, together with those that could affect the security of that data. Acme Payments Pvt Ltd accepts payment through the following channels: E-commerce web checkout, card-present POS, telephone (MOTO) . Accurate scoping is the foundation of the assessment: any component omitted in error remains a live risk to cardholder data, so this document is maintained as a controlled record and reviewed on the cadence set out below.
2. The Cardholder Data Environment (CDE) Defined
The CDE comprises the people, processes and technologies that store, process or transmit cardholder data or sensitive authentication data, together with any system components directly connected to, or that could affect the security of, that environment. For Acme Payments Pvt Ltd , the CDE is summarised as: Segmented VLAN hosting the payment gateway connectors, tokenisation service and supporting jump hosts. Cardholder data means the primary account number (PAN), and where present the cardholder name, expiry date and service code. Sensitive authentication data (SAD) means full track data, card verification codes/values (for example CAV2/CVC2/CVV2/CID), and PINs or PIN blocks. Any system that touches these data elements, in any state, falls inside the CDE and is in scope.
3. System Components in Scope
In line with PCI DSS v4.0.1 scoping guidance, in-scope system components are classified into three categories, all of which are assessed against the applicable requirements. Components are treated as in scope until segmentation or another control is demonstrated to place them out of scope, and never the reverse.
Scope category Definition Examples at Acme Payments Pvt Ltd CDE components Systems that store, process or transmit cardholder data or SAD. Payment gateway connectors, tokenisation service, POS controllers, e-commerce checkout servers, databases holding PAN. Connected-to / contributing Systems on the same network as the CDE, or that connect into it, without themselves handling account data. Jump hosts, directory/authentication servers, patch and update servers, monitoring and logging collectors. Security-impacting Systems that could affect the security of the CDE even if not directly connected. Firewall and router management, name resolution (DNS), time synchronisation (NTP), anti-malware consoles, CI/CD pipelines deploying to the CDE.
4. Inventory of System Components (Req 12.5.1)
Acme Payments Pvt Ltd maintains a current inventory of all system components that are in scope for PCI DSS, as required by Requirement 12.5.1. For each component the inventory records the identifier or hostname, function or role, the scope category (CDE, connected-to, or security-impacting), the owner, and the account-data states it handles (stored, processed or transmitted). The inventory is kept up to date so that it can be reconciled against the network and data-flow diagrams and against the assessed sample, and it is updated whenever components are added, removed or repurposed rather than only at assessment time.
5. Where Account Data Is Stored, Processed and Transmitted
The following locations are the authoritative record of every place account data exists within the environment. Any storage, processing or transmission not listed here is prohibited until the inventory, network diagram and data-flow diagram have been updated to reflect it. Storage of the PAN is minimised and, where retained, is rendered unreadable; sensitive authentication data is never retained after authorisation (see clause 8).
Data element State Location / handling PAN Stored Tokenised at capture; only tokens and, where a documented business need exists, truncated or strongly-encrypted PAN are retained in the payments database. PAN + cardholder data Processed Checkout and gateway-connector services during authorisation, in memory only, on segmented CDE hosts. PAN + cardholder data Transmitted Over TLS-protected sessions between the checkout tier, the CDE and the acquirer/processor; never sent over open public networks in the clear. SAD (track, CVV, PIN) Processed / transmitted only Handled transiently during authorisation and then discarded; never written to disk, logs, backups or the database.
6. Cardholder-Data Flow Description (supporting Req 1.2.4)
Account data enters the environment at defined capture points (for example the e-commerce checkout, POS terminals, or telephone-order capture), is transmitted over encrypted channels to the CDE where it is processed for authorisation, and exits to the acquirer or processor. The data-flow diagram maintained under Requirement 1.2.4 depicts every flow of account data across systems and networks: for each flow it records the origin and destination, the direction, the account-data elements carried, and the transmission method (for example TLS-encrypted). This written description and the diagram are kept consistent with each other and with the component inventory, and are reviewed at least once every 12 months and after any significant change to the environment.
7. Network Diagram (Req 1.2.3)
Acme Payments Pvt Ltd maintains an accurate network diagram, as required by Requirement 1.2.3, that shows all connections between the CDE and other networks, including any wireless networks. The diagram identifies the CDE boundary, the segmentation controls, ingress and egress points, and all in-scope system components. It is reviewed and, where necessary, updated at least once every 12 months and whenever there is a significant change to the network, so that the documented boundary always matches the deployed environment.
8. Prohibition on Storing Sensitive Authentication Data (Req 3.3.1)
In accordance with Requirement 3.3.1, sensitive authentication data is not stored after authorisation, even if encrypted. This prohibition covers the full contents of the track (magnetic-stripe or equivalent chip data), the card verification code or value, and the PIN or PIN block, and it applies across all storage locations without exception, including application logs, audit trails, database tables, message queues, temporary files, memory dumps and backups. Controls are in place to prevent SAD from being persisted, and where any pre-authorisation retention of SAD is unavoidable it is protected and securely deleted as soon as authorisation completes. This requirement does not apply to issuers or entities that support issuing services and have a legitimate, documented business need to store SAD; Acme Payments Pvt Ltd is not such an entity unless expressly recorded here.
9. Network Segmentation to Reduce Scope
The organisation uses network segmentation to isolate the CDE from out-of-scope systems, thereby reducing the number of components subject to PCI DSS. Where segmentation is relied upon to place systems out of scope, the controls that enforce isolation (for example firewalls, access-control lists and separate network zones) are documented, and their effectiveness is validated so that out-of-scope systems cannot reach the CDE. Segmentation is a scope-reduction technique, not a PCI DSS requirement in itself; if it is not implemented, the entire network is treated as in scope. The effectiveness of segmentation is confirmed as part of the periodic scope-confirmation exercise and after any change that could affect the isolation boundary.
10. Annual Scoping-Confirmation Process (Req 12.5.2)
As merchant, Acme Payments Pvt Ltd documents and confirms the accuracy of its PCI DSS scope at least once every 12 months and upon any significant change to the in-scope environment, in line with Requirement 12.5.2. The scope was last confirmed on [date scope was last confirmed]. Each confirmation, at a minimum, identifies all locations and flows of account data; updates the data-flow and network diagrams; identifies every in-scope system component (CDE, connected-to and security-impacting); identifies and validates the segmentation controls used to reduce scope; and identifies all connections from third parties with access to the CDE. The results are documented and retained as evidence, and any newly identified in-scope components are brought under the applicable controls.
11. Significant Change and Scope Re-Assessment
Beyond the periodic confirmation, scope is re-assessed whenever a significant change occurs. Significant changes include new or altered payment channels, changes to network architecture or segmentation, migration of workloads (for example to a new cloud environment), the addition of new system components to the CDE, and changes to third-party connections. Following such a change, Acme Payments Pvt Ltd confirms that PCI DSS requirements are applied to any affected or newly in-scope components, updates the inventory and diagrams, and records the outcome so that the scope documentation remains an accurate reflection of the live environment.
12. Roles, Responsibilities and Records
The document owner is accountable for maintaining this scope document, the component inventory, and the network and data-flow diagrams, and for driving the periodic confirmation process. System and application owners are responsible for reporting changes that affect scope. All scoping records, confirmation results and supporting diagrams are retained as controlled evidence and made available to assessors during the applicable Self-Assessment Questionnaire (SAQ). This document is reviewed at least once every 12 months, or sooner where a significant change requires it.
Prepared by
Head of Information Security
______________________
Scope confirmed / approved by
___________
______________________