Scoping is arguably the most important step in PCI DSS compliance. Everything flows from scoping decisions: the size and complexity of the compliance project, the number of systems requiring controls, the cost of assessment, the frequency of validation, and the ongoing operational burden of maintaining compliance. A mistake in scoping can mean either unnecessary expense (including systems that should have been excluded) or dangerous exposure (excluding systems that should be in scope). For this reason, QSAs devote significant time during assessments to scoping validation, and many compliance failures stem from initial scoping errors.
What Is the Cardholder Data Environment (CDE)?
The Cardholder Data Environment (CDE) is the collection of people, processes, applications, systems, and network components that store, process, or transmit cardholder data (CHD) or sensitive authentication data (SAD). Cardholder data includes the primary account number (PAN—the 16-digit card number), cardholder name, expiration date, and service code. Sensitive authentication data includes the CVV (card verification value), PIN (personal identification number), and full track data from the magnetic stripe or EMV chip. The critical distinction: once your organization touches a PAN in any form, that system is in scope for PCI DSS. If a system can access or be accessed by a PAN-containing system, that system is also in scope.
| KEY IDEA | The PAN — the 16-digit card number — is the trigger for PCI DSS scope. Once a PAN is present in a system, that system is in scope. Everything connected to that system is also potentially in scope. Scope reduction is therefore always about reducing where the PAN lives. |
The Three Scope Categories
PCI DSS v4.0 defines three categories of systems relative to the CDE. Understanding these categories is essential for accurate scoping. First, CDE systems directly store, process, or transmit CHD or SAD. These systems are absolutely in scope for PCI DSS. Second, systems that are connected to CDE systems or can impact CDE security—such as Active Directory (providing authentication), SIEM systems (monitoring CDE logs), or patch management servers (updating CDE systems)—are fully in scope. Third, systems that are out of scope are completely isolated from the CDE with no path for connection or security impact.
| Scope Category | Definition | PCI DSS Controls Required | Examples |
|---|---|---|---|
| CDE Systems | Store, process, or transmit cardholder data or SAD | Full PCI DSS requirements apply | Payment servers, databases with PANs, POS terminals |
| Connected-to Systems | Can communicate with CDE systems | Full PCI DSS requirements apply | Active Directory, SIEM, jump servers, patch servers |
| Security-Impacting Systems | Can affect security of CDE (no direct connection) | Full PCI DSS requirements apply | Antivirus management, log management, change management |
| Out-of-Scope Systems | Isolated from CDE with no connectivity or impact path | No PCI DSS requirements | HR systems, marketing platforms (if properly isolated) |
Data Flow Diagramming — The Foundation of Scoping
You cannot scope accurately without understanding where cardholder data flows through your organization. Data flow diagrams (DFDs) map the ingestion, processing, storage, and transmission of CHD and SAD. A complete DFD shows: all systems and applications handling or storing cardholder data, all data stores (databases, files, caches) where cardholder data persists, all transmission paths (network connections, APIs, message queues) through which cardholder data moves, all external connections and third-party integrations, and all backups and archival systems where historical cardholder data may reside.
Creating an accurate DFD requires investigation beyond simply asking IT "where is the card data?" Cardholder data may reside in unexpected places: debug logs, temporary files, backup media, third-party system caches, or disaster recovery copies. Many organizations discover during scoping exercises that PANs are being stored in systems they didn't realize were handling cardholder data.
| Bitlion scoping engagements always begin with a data discovery exercise — not just asking the IT team where card data lives, but systematically searching for PANs in databases, file systems, logs, and backups. Uncontrolled PAN sprawl is the most common scoping failure we find. |
Scope Reduction Strategies
Tokenization
Tokenization is the replacement of the actual PAN with a non-sensitive token at the earliest point in the payment flow. Tokens have no meaning or value outside the specific tokenization system. Critically, the token cannot be reversed to recover the original PAN. Systems that handle only tokens, not PANs, are typically out of scope for PCI DSS, because PCI DSS scope is triggered by handling the PAN itself. The tokenization vault—the system that stores and manages the mapping between tokens and PANs—is itself in scope and must be highly secure. But the benefit is that every downstream system that uses tokens instead of PANs can be removed from scope.
Point-to-Point Encryption (P2PE)
With P2PE, cardholder data is encrypted at the point of interaction (the payment terminal or card reader) before it enters the merchant's systems. The encryption happens at the physical or logical point where the card is swiped or inserted. The merchant's systems receive only encrypted data, which they forward to the payment processor in encrypted form. The merchant never has access to the clear-text card data. With a validated P2PE solution, merchants can dramatically reduce their PCI DSS scope—often achieving SAQ P2PE compliance with minimal scope. The P2PE solution provider assumes responsibility for the secure handling and decryption of the encrypted data.
Hosted Payment Pages
For e-commerce merchants, a hosted payment page removes card data handling from the merchant's environment entirely. Customers are redirected to a third-party payment page (hosted and maintained by the payment service provider) where they enter their card details. The merchant never sees or handles the card data—it stays within the PSP's secure environment. This approach can enable e-commerce merchants to achieve SAQ A (the shortest SAQ) with minimal scope. However, merchants must still ensure that the implementation is secure, including management of any JavaScript that runs on pages that redirect to the hosted payment page (Requirement 6.4.3).
| Strategy | How It Works | Scope Impact | Residual Scope | Best For |
|---|---|---|---|---|
| Tokenization | Replace PAN with non-sensitive token | Systems handling only tokens are out of scope | Tokenization vault is in scope | Large merchants with internal systems handling card data |
| P2PE | Encrypt card at POI terminal before entering merchant systems | Reduces merchant scope to physical terminal area | POI device management remains | Brick-and-mortar merchants |
| Hosted Payment Page | Card entered on PSP's page, never reaches merchant systems | Merchant can qualify for SAQ A | JavaScript security still required (v4.0) | E-commerce merchants |
| Outsourcing to PSP | Entire payment flow handled by a PCI-compliant PSP | Merchant responsibility reduced significantly | Merchant still responsible for access to PSP portal | Smaller merchants, startups |
Network Segmentation and Scope
Network segmentation is not a requirement of PCI DSS—there is no mandate that you segment your network. However, segmentation is the most effective scope reduction technique available. Without effective segmentation, the entire network is technically in scope because there is no firewall or network boundary preventing an attacker from moving from a non-CDE system to a CDE system. Effective segmentation uses firewalls, VLANs, or other network security controls to create a boundary around the CDE. All traffic crossing the boundary must be explicitly allowed by firewall rules, and prohibited traffic is blocked.
| IMPORTANT | Network segmentation is optional under PCI DSS — but without it, your entire corporate network is in scope. An organization that processes card payments on the same flat network as its HR and marketing systems effectively has a CDE that encompasses everything. QSAs will test segmentation effectiveness during assessment, ensuring that traffic from CDE systems to non-CDE systems is properly blocked. |
Scoping for Indonesian Payment Organizations
Indonesian payment service providers, payment gateways, and banks often operate hybrid environments combining on-premise core banking systems with cloud-based payment orchestration, transaction processing, and reporting layers. These environments may span multiple cloud regions (Jakarta regions are available on AWS, GCP, Azure) and may involve data residency constraints under UU PDP (the Indonesian Personal Data Protection Law). Scoping these environments requires careful analysis of data flows across on-premise/cloud boundaries, clear documentation of which systems process or store PANs, and coordination with cloud providers regarding their own PCI DSS compliance.
For PSPs transitioning from on-premise infrastructure to cloud-native architectures, scope reduction through cloud-native tokenization services is often highly cost-effective. By storing PANs in a cloud HSM-backed tokenization service and exposing only tokens to application layers, organizations can often reduce the number of in-scope systems by 60–80%, dramatically reducing complexity and compliance costs.
| For Indonesian PSPs transitioning from on-premise to cloud payment infrastructure, scope reduction through cloud-native tokenization services is often the most cost-effective path. Storing PANs in a cloud HSM-backed tokenization service and exposing only tokens to application layers can reduce the in-scope system count by 60–80%. |
Documenting Your Scope
PCI DSS v4.0 requires organizations to document scope comprehensively. Documentation must include: a complete system inventory listing all systems in the CDE, all connected-to systems, and all security-impacting systems; detailed data flow diagrams showing how cardholder data moves through the organization; network diagrams showing all connections between systems and to external networks; a formal scope statement defining exactly which systems are in scope and why; and (for organizations using the Customized Approach) a Targeted Risk Analysis documenting risk assessments and control rationale.
This documentation serves multiple purposes. It guides implementation of controls (you cannot secure what you have not identified). It provides evidence of scoping decisions during QSA assessment. It supports ongoing compliance through change management—when systems are added, retired, or modified, you update the documentation to reflect the changes. The documentation is also essential for demonstrating scope reduction through tokenization or segmentation, as it provides the baseline from which reduction is calculated.