Scoping is the leverage point of PCI DSS compliance. Every decision made during the scoping exercise determines the number of systems, people, and processes subject to PCI DSS requirements. A well-executed scoping exercise can legitimately reduce the in-scope footprint by 60–80% compared to a poorly scoped environment — with corresponding reductions in compliance cost and ongoing maintenance burden.
Scope decisions are revisited annually, and the decisions made during the initial scoping exercise often persist throughout the organization's compliance lifecycle. A poorly defined scope from the beginning creates years of unnecessary compliance work. This article walks through the scoping methodology and the technical strategies that have the largest impact on scope reduction.
The Scoping Methodology
Step 1 — Identify All Account Data Locations
Before defining the CDE, you must find all locations where account data exists. Methods include: automated data discovery tools (searching for PAN patterns using regular expressions), database catalog review (querying system tables for all databases and their contents), application inventory review with payment functionality identification (asking developers which applications process payments), log analysis (searching logs for PAN values), file system search (searching for PAN patterns in files), and backup media review (verifying that backups contain CHD). Document every location where any element of CHD or SAD is found.
This step is tedious but essential. Many organizations discover unexpected locations where cardholder data accumulates: third-party log aggregation systems that capture application logs containing PANs, backup systems that archive encrypted databases before encryption was enabled, development databases that were populated from production, and integration logs that capture transaction data. Each discovery expands the scope.
Step 2 — Map Data Flows
For every identified CHD location, map how data arrived there and where it goes next. The data flow diagram must show: all system components that receive, process, store, or transmit CHD; all network connections and data transmission paths (including encrypted vs. unencrypted); all external connections (to acquirers, payment networks, payment service providers); and all data storage locations (databases, files, archives, backups).
A complete data flow diagram is typically 20–50 systems in a moderately complex environment. Each system is a box; each data flow is an arrow. The diagram should show not just the happy path (how a payment should flow) but all actual paths (including error handling, debugging, testing, and integration flows). The diagram becomes the master reference for all subsequent PCI DSS work.
Step 3 — Identify Connected-to and Security-Impacting Systems
Every system that has network connectivity to CDE systems is potentially in scope. Systems that can affect the security of the CDE (even without direct connectivity) — such as monitoring systems, authentication infrastructure, and change management systems — are also in scope. This step is where scope can grow unexpectedly if the network is flat.
A flat network (where all systems on a common VLAN can communicate with each other) means that every system on that VLAN is potentially in-scope for PCI DSS. The consequences are significant — suddenly the office printers, development workstations, and HR systems are all in-scope. This is why network segmentation is the primary scope reduction tool.
| KEY IDEA | The "connected-to" system scope extension is where most organizations are surprised. Active Directory — used by all Windows systems — is typically in scope because CDE systems depend on it for authentication. The patch management server is in scope. The monitoring system is in scope. The only way to get these systems out of scope is to eliminate their connectivity to or impact on the CDE. |
Step 4 — Define Scope Reduction Opportunities
With the full data flow picture, evaluate where scope reduction techniques can be applied to remove systems from scope or reduce the depth of required controls. The primary scope reduction techniques are: network segmentation (isolating the CDE from other systems), tokenization (replacing PANs with tokens), hosted payment pages (outsourcing payment capture), truncation (storing only the last 4 digits), and reducing the number of systems that directly touch cardholder data.
Network Segmentation — The Primary Scope Reduction Tool
Network segmentation physically or logically separates the CDE from all other networks. Without segmentation, the entire network is in scope. With effective segmentation, only the CDE network segment — and systems directly connected to or impacting it — is in scope. This is the single most effective scope reduction technique and is the foundation of any modern PCI DSS implementation.
Segmentation Technologies
Accepted segmentation technologies include: dedicated firewalls with deny-all rules between CDE and non-CDE segments (the most common approach for on-premises environments), VLANs with access control lists (subnet-level isolation with Layer 3 enforcement through a managed switch or firewall), physical network separation (completely separate switches, routers, and infrastructure for CDE vs. non-CDE), and cloud security groups/VPCs with strict routing controls (AWS Security Groups, Azure NSGs, GCP Firewall rules).
VLANs alone, without a Layer 3 firewall enforcing access controls, are generally insufficient for PCI DSS. VLANs can be bypassed by attackers with physical access or by misconfigured devices. A well-implemented VLAN architecture includes managed access control lists on the router or Layer 3 switch enforcing deny-all between VLANs, with explicit permit rules for required traffic.
Segmentation Documentation and Testing
Segmentation must be documented with: network architecture diagrams showing CDE boundaries (clear visual representation of which systems are in and out of scope), firewall rules or ACL configurations demonstrating CDE isolation (the actual rules that enforce the boundary), and the evidence that will be presented to a QSA for segmentation verification (test results showing that out-of-scope systems cannot initiate connections to CDE systems).
| Segmentation Approach | Technical Implementation | QSA Evidence Required | Strength |
|---|---|---|---|
| Dedicated firewall | Physical or virtual firewall at CDE perimeter with deny-all default ruleset | Firewall configuration, ruleset with business justifications, rule review records | Strong — industry standard |
| Cloud security groups | AWS/GCP/Azure security groups with explicit deny, no CDE VPC peering to non-CDE | Security group rules, VPC flow logs, no cross-VPC routing evidence | Strong for cloud-native CDEs |
| VLAN only | CDE on separate VLAN, inter-VLAN routing through L3 switch ACLs | ACL configuration, traffic analysis — QSA may require additional evidence | Moderate — requires careful ACL management |
| Physical separation | Dedicated physical hardware for CDE systems, no shared infrastructure | Physical inventory, cable documentation, network diagrams | Very strong — most unambiguous |
Segmentation testing is a critical part of the QSA assessment. QSAs will verify that the CDE is actually isolated by attempting to connect from out-of-scope systems to in-scope systems. Your segmentation documentation and test results must demonstrate that these attempts will fail.
Tokenization for Scope Reduction
Replacing PANs with tokens at the earliest point in the payment flow is the most effective way to reduce the scope of internal application and database systems. Only the tokenization vault — which holds the token-to-PAN mapping — and systems that process real PANs before tokenization remain in scope. All downstream systems that work with tokens only are out of scope.
Implementation Approaches
Organizations can implement tokenization using: third-party tokenization services (Stripe, Braintree, Adyen — where the PSP handles the PAN and returns a token), cloud tokenization services (AWS Payment Cryptography, Google Cloud payment solutions), or internal tokenization solutions using a Hardware Security Module (HSM) and a secure token vault.
For most organizations, particularly Indonesian merchants and smaller fintech companies, using a third-party PSP's tokenization service is the simplest approach. The PSP becomes responsible for PCI DSS compliance, and the merchant's environment only stores and uses the token.
| IMPORTANT | A critical scoping consideration: a "token" that can be systematically reversed to recover the original PAN without access to a secure vault is not a token for PCI DSS purposes — it is still a form of cardholder data. True tokens must be cryptographically random and non-reversible without the tokenization vault. Encrypted PAN values that any system can decrypt are not tokens. |
Hosted Payment Page Architecture
For e-commerce merchants, the most effective scope reduction is a properly implemented hosted payment page. When the customer enters card details on a page hosted entirely by a PCI-compliant payment service provider, the merchant's environment never receives the PAN. This transforms the compliance requirements dramatically.
SAQ A Eligibility Requirements
To qualify for SAQ A (the shortest SAQ, approximately 20 questions, vs. 100+ for other SAQ types), an e-commerce merchant must: use a payment page fully hosted by a third-party PSP, have no direct access to CHD in any form, not store, process, or transmit CHD on any merchant system, and confirm that all payment processing is fully outsourced to a PCI DSS compliant third party.
SAQ A is the most favorable compliance position for e-commerce merchants. If you can achieve SAQ A, you reduce compliance effort by 80% or more. However, SAQ A is only possible if the architecture genuinely meets the requirements — no SAQ A shortcuts or workarounds are acceptable to QSAs.
| The hosted payment page approach is the most commonly recommended scope reduction strategy for Indonesian e-commerce merchants. Major Indonesian PSPs (including Midtrans, Xendit, and Doku) offer hosted payment page solutions that, properly implemented, support SAQ A eligibility. The key is verifying that your implementation truly meets the SAQ A criteria — particularly that no card data ever touches your servers, and that the v4.0 JavaScript security requirements (6.4.3) are met. If you are unsure about your implementation, request SAQ A pre-qualification from your PSP before relying on it for compliance planning. |
Other Scope Reduction Techniques
Truncation
Storing only the first 6 and last 4 digits of a PAN is truncation. Truncated values are not PANs and are not subject to PCI DSS scope. If your systems store and process only truncated PANs, those systems are out of scope. The tradeoff is that truncated data cannot be used for certain functions (like refunds or card matching), so truncation only works in environments where the full PAN is not required for business functions.
One-Way Hashing
Using a one-way hash (like HMAC-SHA256) to transform PANs is similar to truncation in terms of scope — hashed values that cannot be reversed are not PANs. However, hashing requires that the hash function is properly keyed and that the key is managed securely. Hashing is useful for systems that need to match or verify PANs without storing the actual value, such as fraud detection systems.
Documenting Scope for QSA Assessment
The scope documentation package for a QSA assessment should include: data flow diagrams (current and complete, showing all systems and data paths), network diagrams with CDE boundaries marked (clear visual representation of in-scope vs. out-of-scope), system component inventory (list of all systems in scope with brief description), scope justification narrative (written explanation of the scope decisions and boundaries), scope reduction strategy documentation (what techniques are used and why), and (for segmented environments) the segmentation testing plan and test results.
Clear, well-organized scope documentation sets the tone for the entire assessment. QSAs will ask probing questions if scope documentation is vague or incomplete, leading to assessment delays. Investment in clear scope documentation upfront saves time and reduces friction during the assessment.