The Payment Card Industry Data Security Standard (PCI DSS) version 4.0 introduced a formal requirement for a documented scoping exercise under PCI 12.5.2. This critical step, performed before the Qualified Security Assessor (QSA) begins their assessment, ensures that the scope of the Cardholder Data Environment (CDE) is accurately defined and validated. This guide breaks down the scoping process, offering practical steps and tips to streamline compliance.
What is the PCI Scoping Exercise?
A PCI scoping exercise identifies all systems, processes, and personnel that interact with or impact the security of cardholder data (CHD) or sensitive authentication data (SAD). The goal is to define the CDE, document “connected to” systems, and verify segmentation controls that are used to limit the scope of the PCI DSS assessment. This exercise is not a one-time task—service providers must review it every six months, while others repeat it annually.
Key Components of the Scoping Exercise
- Identifying Systems with Cardholder Data (CDE)
The CDE includes any system that stores, processes, or transmits CHD or SAD. Here’s how to approach each:
- Storage: Identify static data in databases, log files, swap files, RAM, or cloud storage. Use automated data discovery tools to ensure no CHD is overlooked.
- Processing: Includes activities by payment processors or card processor.
- Transmission: Covers data movement, including viewing CHD on a monitor, keying card numbers, or transmitting data via VoIP.
A table like the one below is great for storage of CHD/PAN. Network diagrams are used to document the transmission.
Data store (database, file, cloud) | Purpose of the storage | Retention period | PAN, expiry, cardholder name, or SAD | How data is secured (encryption strength, hashing algorithm, truncation, tokenization) | If encrypted, can we decrypt it? If no, not in scope. | How access to data is logged |
Finding this helpful? Join our newsletter.
- Mapping “Connected to” Systems
These are systems that don’t store, process, or transmit CHD but can access CDE systems or impact their security. Examples include:
- Systems on the same VLAN as CDE systems.
- Security tools like firewalls, SIEMs, IDS/IPS, or patch management systems.
- Authentication servers or network traffic filters.
Tip: Use network mapping tools to identify connections and ensure no indirect access to the CDE exists.
- Implementing Segmentation Controls
Segmentation reduces the PCI assessment scope by isolating the CDE from other systems. Effective segmentation prevents all communication between in-scope and out-of-scope systems using. Segmentation is optional. Some examples of segmentation controls include:
- VLANs with strict filtering (VLANs alone are insufficient).
- Container isolation
- Physical separation
- Security groups
For a system to be out-of-scope, it must meet all of the following:
- Does not store, process, or transmit CHD/SAD.
- Is not in the same network segment as CDE systems.
- Cannot connect (directly or indirectly) to CDE systems.
- Does not impact CDE configurations or provide security/segmentation services.
- Does not fulfill any PCI DSS requirements.
Tip: Document segmentation controls with diagrams showing firewalls, VLANs, or security groups.
- Mapping Payment Channels
Map every payment channel (in-person, telephone, mail, e-commerce) to create data flow diagrams. Each diagram should trace CHD from entry to exit, categorizing each step as:
- In-Scope: Systems handling CHD/SAD (e.g., POS terminals, e-commerce servers).
- Connected to/Security-Impacting: Systems supporting the CDE (e.g., firewalls, authentication servers).
Example: For an e-commerce payment, the flow might include a customer’s browser, a web server, a payment gateway, and a database. Even a CVV or expiration date alone is considered CHD.
Tip: Look for opportunities to eliminate full Primary Account Number (PAN) storage (e.g., process changes, tokenization, or outsourcing) to reduce scope.
- Assessing Third-Party Service Providers
Include third parties with access to CHD/SAD or that can impact the security of the CDE in the scoping exercise. For each provider:
- Verify their PCI compliance status (e.g., Attestation of Compliance).
- If compliant, leverage their AOC to exclude requirements associated with their services from your assessment (will require their responsibility matrix or responsibility statement).
- If non-compliant, include their services in your assessment scope.
Tip: Using PCI-certified providers simplifies compliance but is not mandatory.
- Identifying In-Scope Personnel
Document personnel with access to CHD/SAD, such as job titles (e.g., “POS Operators”) or named individuals. These individuals require specialized security awareness training to handle CHD/SAD securely.
Tips for a Successful Scoping Exercise
- Start Small: Focus on one Merchant ID (MID) and map its payment channels before moving to others.
- Use Automation: Leverage tools for CHD/SAD discovery and network mapping.
- Verify Consistency: Ensure processes are identical across all locations.
- Include All Payment Stages: Cover authorization, capture, settlement, chargebacks, and refunds.
- Create a Comprehensive Inventory: List all hardware, software, databases, apps, POS terminals, card readers, cloud assets, and PCI-certified solutions (e.g., P2PE devices).
This inventory informs vulnerability assessments, Approved Scanning Vendor (ASV) scans, penetration tests, and web application scans, ensuring they are scoped correctly.
Why Scoping Matters
A well-executed scoping exercise reduces the PCI DSS assessment scope, saving time and resources. It also ensures compliance by identifying all systems and personnel that interact with CHD/SAD. For complex environments, professional assistance can make the process smoother.
Need help with your PCI scoping or assessment? Contact Auditwerx at [email protected] or visit www.auditwerx.com for experienced guidance.
