PCI DSS Scope Determination: Cardholder Data Environment (CDE) Mapping

I was sitting across from the CTO of a rapidly growing e-commerce company in 2020, watching the color drain from his face. We'd just finished mapping his cardholder data environment, and the scope was far bigger than he'd imagined.

"Wait," he said, staring at the diagram. "You're telling me that because our payment processing server can talk to our inventory system, and our inventory system connects to our entire backend... we need PCI controls on everything?"

"Not quite everything," I replied. "But yes, it's significantly more than you thought."

This is the moment I see in almost every PCI DSS assessment. Organizations assume their scope is small—just the payment page, right? Then reality hits. After fifteen years of conducting PCI DSS assessments across industries, I can tell you with certainty: improper scope determination is the #1 reason companies fail PCI audits and the #2 reason they get breached (right after outdated systems).

Let me walk you through everything I've learned about properly mapping your Cardholder Data Environment—the hard way, so you don't have to.

What Actually Is the Cardholder Data Environment?

The PCI Security Standards Council defines the CDE as the people, processes, and technologies that store, process, or transmit cardholder data or sensitive authentication data. But that definition, while technically correct, is about as useful as a chocolate teapot for most people trying to implement it.

Here's how I explain it to clients:

"Your CDE is like a medieval castle. The innermost keep holds your treasure (cardholder data). But your scope includes not just the keep—it's the keep, the walls around it, the moat protecting those walls, and the guard towers watching over everything. If an attacker can use something to get to your treasure, it's in scope."

The Three Critical Zones of Your Environment

Based on hundreds of assessments, I've found it helpful to think about your environment in three distinct zones:

Let me share a war story that illustrates why this matters.

The $340,000 Scope Creep: A Cautionary Tale

In 2019, I was called in to help a hospitality company that had just failed their PCI assessment. They'd been processing payments for eight years and thought they had a handle on compliance.

Their original scope assessment looked simple:

• 4 payment processing servers

• 1 database

• 5 point-of-sale terminals per location (20 locations = 100 terminals)

Clean and straightforward, right?

During my comprehensive scope review, we discovered:

• The payment database was on the same network segment as their reservations system

• The reservations system connected to their property management system

• The property management system had access to their corporate network

• Their corporate network had inadequate segmentation

The actual scope? 347 systems instead of 105.

The cost to properly implement PCI controls across this expanded scope: $340,000.

The CTO's response is burned into my memory: "We could have implemented proper network segmentation three years ago for $80,000. Instead, we ignored it, and now we're paying four times as much while our QSA has put us on notice."

"Scope creep doesn't happen accidentally. It happens when you ignore network architecture and hope the auditor doesn't look too closely. Spoiler alert: good auditors always look closely."

Step-by-Step: How to Actually Map Your CDE

Let me walk you through the exact process I use. I've refined this over hundreds of assessments, and it works whether you're a small restaurant or a global e-commerce platform.

Step 1: Identify Where Cardholder Data Lives (The Obvious Part)

Start with the obvious stuff. Where does payment card data explicitly exist in your environment?

Primary Account Number (PAN) locations:

• Payment terminals (POS systems, card readers)

• Payment gateway servers

• E-commerce checkout servers

• Databases storing transaction data

• Payment application servers

• Call center recording systems (yes, really)

Sensitive Authentication Data (SAD) locations:

• Magnetic stripe data (you shouldn't be storing this)

• CVV/CVV2/CVC2 codes (you definitely shouldn't be storing this)

• PIN data (absolutely, positively shouldn't be storing this)

Here's a quick reference table for what you can and cannot store:

I once found a company storing full magnetic stripe data in their database "for fraud analysis purposes." That's a PCI compliance violation that could result in immediate termination of their payment processing ability. They were shocked when I explained they needed to purge all that data immediately.

Step 2: Trace the Data Flow (The Hard Part)

This is where most organizations stumble. You need to follow every path that cardholder data takes through your environment.

I use a technique I call "Data Flow Interrogation." For every system you identified in Step 1, ask:

1. Where does the data come from?

2. Where does the data go?

3. What systems touch it in between?

4. What systems can access the systems that touch it?

Let me show you a real example. Here's a simplified data flow I mapped for a retail client:

Customer Card → POS Terminal → Payment Switch → Payment Processor
                      ↓
                Store Server → Regional Server → Corporate Database
                      ↓
                Backup Server → Backup Storage
                      ↓
                Management Workstation (for troubleshooting)

Each arrow represents a system that must be in scope. But wait, there's more:

• The store network that connects POS to store server

• The WAN connecting store server to regional server

• The database server hosting corporate database

• The network segment containing backup servers

• Any jump boxes or bastion hosts used to manage these systems

• Any monitoring systems collecting logs from these systems

That "simple" payment flow touched 23 systems. All in scope.

Step 3: Identify Connected Systems (Where Scope Explodes)

Here's the brutal truth: any system that connects to a CDE system is also in scope unless you can prove otherwise through network segmentation.

I created this checklist based on the most commonly overlooked connected systems:

Infrastructure Systems:

• Active Directory/LDAP servers (if CDE systems authenticate against them)

• DNS servers (if CDE systems use them)

• NTP servers (time synchronization for CDE)

• SIEM/logging servers (collecting CDE logs)

• Backup systems (backing up CDE data)

• Monitoring systems (monitoring CDE systems)

• Patch management servers (updating CDE systems)

• Antivirus management consoles (managing CDE endpoints)

Access Systems:

• Jump boxes/bastion hosts (used to access CDE)

• VPN concentrators (providing access to CDE)

• Remote desktop servers (accessing CDE systems)

• Administrative workstations (managing CDE)

• Service accounts (accessing CDE systems)

Security Systems:

• Firewalls (protecting CDE)

• IDS/IPS (monitoring CDE traffic)

• WAF (protecting web applications in CDE)

• DLP systems (monitoring for card data exfiltration)

Here's a real-world example that shocked a client:

Their web developer had been using his laptop to SSH into production payment servers for troubleshooting. That laptop was now in scope. But the laptop connected to their corporate Wi-Fi. The Wi-Fi was in scope. The Wi-Fi connected to their corporate network. Without proper segmentation, their entire corporate network was potentially in scope.

One developer's convenience had just added 450+ systems to their PCI scope.

"Every convenience you add to access your CDE is a potential scope expansion. That doesn't mean you shouldn't add convenience—it means you need to do it thoughtfully with proper segmentation and access controls."

Step 4: Map Network Segmentation (Your Scope-Reduction Superpower)

Network segmentation is the most powerful tool you have for reducing PCI scope. Done properly, it can cut your scope by 70-90%. Done poorly, it's worthless.

I've seen organizations think they have segmentation when they actually don't. Here's what real segmentation requires:

Proper Network Segmentation Checklist:

I worked with a healthcare organization that thought they had perfect segmentation. Their network diagram showed VLANs separating their payment systems from everything else.

But when I tested it, I discovered:

• The firewall had an "any any permit" rule added during a network upgrade two years ago

• Their backup software had created a connection between segments that nobody documented

• A misconfigured switch was bridging VLANs

Their "segmentation" was theater. In a real audit, it would provide zero scope reduction.

After we fixed it properly:

• Before: 892 systems in scope

• After: 127 systems in scope

• Annual compliance cost reduction: $680,000

That's the power of proper segmentation.

Step 5: Document System Connectivity (The Auditor's Favorite Question)

Every PCI assessment includes the dreaded question: "Show me your network diagrams and data flow documentation."

I cannot count how many times I've heard: "We know how it works, we just haven't documented it."

That doesn't fly. Here's what you actually need:

Required Documentation:

I have a template I use for system inventory that has saved clients hundreds of hours:

System Name: [Unique identifier]
Function: [What it does]
Scope Status: [In scope / Out of scope / Connected]
Scope Justification: [Why it's in this category]
CHD Present: [Yes / No / Transient]
Location: [Physical/Virtual location]
IP Address: [Network address]
OS/Version: [Operating system]
Responsible Party: [Owner]
Last Review Date: [Date]

One client told me: "Your inventory template has become our single source of truth. Our security team, compliance team, and auditors all reference the same document. It's eliminated 80% of the back-and-forth during assessments."

The "Out of Scope" Trap: Proving the Negative

Here's something that surprises people: it's not enough to say a system is out of scope. You must prove it.

I've had this conversation at least 200 times:

Client: "Our HR system is out of scope. It has nothing to do with payments."

Me: "Can anyone log into the HR system and then access payment systems?"

Client: "Well, administrators can..."

Me: "Can the HR system communicate with any payment systems on the network?"

Client: "I mean, they're on the same network, but—"

Me: "Then it's in scope unless you can prove effective segmentation."

Client: [expletive deleted]

To prove a system is truly out of scope, you need to demonstrate:

1. No cardholder data is stored, processed, or transmitted

2. No network connectivity to any CDE systems

3. No shared credentials with CDE systems

4. No management access to CDE systems

5. Physical/logical isolation can be verified

I created this decision tree that I share with every client:

Does the system store/process/transmit CHD?
├─ YES → In Scope (Zone 1)
└─ NO → Continue
    │
    Does it connect to any system that handles CHD?
    ├─ YES → Is there effective segmentation?
    │   ├─ YES → Can you prove it?
    │   │   ├─ YES → Out of Scope (document proof)
    │   │   └─ NO → In Scope (Zone 2)
    │   └─ NO → In Scope (Zone 2)
    └─ NO → Out of Scope (document isolation)

Cloud Environments: A Whole New Nightmare

Cloud environments have made scope determination simultaneously easier and more complex.

Easier because:

• You can create isolated environments quickly

• Network segmentation through VPCs is straightforward

• You can truly isolate payment processing

Harder because:

• Shared responsibility models complicate scope

• Developers can spin up resources that touch CDE

• Infrastructure as Code can accidentally create connections

I assessed a fintech startup in 2023 running entirely on AWS. Their initial scope assessment showed 8 EC2 instances handling payments. Seemed reasonable.

During my review, I found:

• 14 Lambda functions that processed payment webhooks (in scope)

• An API Gateway that routed payment requests (in scope)

• A CloudWatch log group capturing payment data (in scope)

• An S3 bucket receiving payment-related files (in scope)

• IAM roles that could access payment resources (in scope)

• A NAT Gateway providing internet access to payment systems (in scope)

• The VPC itself and all its components (in scope)

Final count: 47 cloud resources instead of 8.

Cloud Scope Determination Table

"In the cloud, everything is software-defined. That means your scope can change with a single Terraform deployment. Document your infrastructure as code, and treat every deployment as a potential scope change event."

Common Scope Determination Mistakes (That Cost Real Money)

After hundreds of assessments, I've seen the same mistakes repeatedly. Here are the top 10:

1. The "We Tokenize So We're Safe" Myth

The Mistake: "We use tokenization, so we don't have card data."

The Reality: If you handle the real card data at any point before tokenization, that system is in scope.

Real Example: E-commerce company used a tokenization service but captured the full card number on their web server before sending it for tokenization. Their web server was 100% in scope.

2. The Forgotten Test Environment

The Mistake: "Our test environment uses fake data, so it's out of scope."

The Reality: If your test environment connects to production systems or uses production configurations, it's in scope.

Real Example: A company's test environment could SSH into production payment servers. Every test server came into scope. Additionally, they'd occasionally copy production data to test (including real card data). Instant compliance violation.

3. The Developer Laptop Oversight

The Mistake: "Developers need production access to troubleshoot issues."

The Reality: Every developer laptop with production payment system access is in scope.

Real Example: A SaaS company had 15 developers with production database access. All 15 laptops came into scope. After implementing jump boxes with session recording, scope reduced to 2 hardened bastion hosts instead of 15 developer laptops.

4. The Wireless Network Wildcard

The Mistake: "Our wireless is separate from our payment network."

The Reality: If your wireless can reach payment systems (even through multiple hops), it's in scope.

Real Example: Retail chain thought their store Wi-Fi was isolated. During penetration testing, we accessed their POS systems through the guest Wi-Fi network due to misconfigured VLANs. Every wireless access point came into scope.

5. The Third-Party Service Blindspot

The Mistake: "Our payment processor handles everything, so we have no scope."

The Reality: If you touch card data before it reaches the processor, you have scope.

Real Example: Restaurant chain used a payment processor but their POS system temporarily stored card data before transmitting. They thought they were "pass-through only." They weren't. Full PCI scope applied.

Scope Reduction Strategies That Actually Work

Let me share the strategies I've used to help clients dramatically reduce their PCI scope:

Strategy 1: Point-to-Point Encryption (P2PE)

Best for: Retail, hospitality, any business with physical card acceptance

Scope Reduction: Can eliminate 70-90% of systems

How it works: Card data is encrypted at the point of interaction (card reader) and remains encrypted until it reaches your payment processor. Your systems never see unencrypted card data.

Real Example: Restaurant chain with 200 locations

• Before P2PE: 847 systems in scope (POS terminals, store servers, regional servers, corporate network)

• After P2PE: 89 systems in scope (only the P2PE devices themselves and minimal management infrastructure)

• Annual compliance cost reduction: $520,000

Gotcha: You must use a validated P2PE solution. "Our payment terminal encrypts data" doesn't count unless it's PCI-certified P2PE.

Strategy 2: Tokenization

Best for: E-commerce, recurring billing, any business storing cards for future transactions

Scope Reduction: Can eliminate card data storage scope

How it works: Replace card data with tokens immediately after authorization. Store tokens instead of card data.

Real Example: SaaS company with subscription billing

• Before Tokenization: Stored encrypted card data in their database (database and all connected systems in scope)

• After Tokenization: No card data storage, tokens only (reduced database scope, eliminated several backup systems from scope)

• Systems removed from scope: 34

Gotcha: The system that captures the card data and sends it for tokenization is still in scope. True scope reduction requires capturing cards outside your environment (like using a tokenization vendor's hosted fields).

Strategy 3: Network Segmentation

Best for: Everyone, no exceptions

Scope Reduction: Typically 60-80% when done properly

How it works: Isolate payment systems on dedicated network segments with firewall enforcement and minimal necessary connections.

Real Example: Healthcare organization

• Before Segmentation: 892 systems in scope (payment systems could access and be accessed from anywhere on network)

• After Segmentation: 127 systems in scope

• Implementation cost: $180,000

• Annual compliance cost savings: $680,000

• ROI: 3.2 months

Strategy 4: Dedicated Payment Environment

Best for: Organizations with complex networks and multiple business units

Scope Reduction: Can create a small, manageable scope

How it works: Build a completely separate environment for payment processing with its own infrastructure, administration, and access controls.

Real Example: Manufacturing company that added e-commerce

• Instead of integrating payment processing into existing network (which would bring entire corporate infrastructure into scope)

• Built dedicated AWS VPC for payment processing only

• Result: 12 cloud resources in scope instead of 400+ corporate systems

The Hidden Scope: Where Everyone Forgets to Look

After years of assessments, I've compiled a list of commonly forgotten scope items:

Systems Everyone Forgets

I once found card data in:

• Excel spreadsheets on a shared drive (scope expansion: 1 file server + all connected systems)

• Email archives going back seven years (scope expansion: email servers + backup systems)

• Application logs that were supposed to mask card data but didn't (scope expansion: logging infrastructure)

• A forgotten staging environment that had been copying production data for three years (scope expansion: entire staging environment)

Each discovery added dozens of systems to scope and thousands of dollars to compliance costs.

Creating Your Scope Document: What Auditors Actually Want

Here's the uncomfortable truth: most scope documents I review are inadequate. They're vague, incomplete, or clearly designed to minimize scope rather than accurately reflect it.

Good auditors see through this immediately. And when they do, they expand your scope to be "safe"—which usually means you end up with more scope than necessary.

Here's the scope document template I've refined over the years that passes auditor scrutiny:

Essential Components of a Scope Document

1. Executive Summary

   • Brief business description

   • Payment channels (e-commerce, retail, phone, etc.)

   • High-level scope summary

   • Merchant level and validation requirements

2. Network Environment Overview

   • Network architecture description

   • Segmentation strategy

   • Physical and logical security boundaries

   • Cloud/hosted environment details

3. In-Scope Systems

   • Complete inventory with details

   • Grouped by function (payment processing, databases, infrastructure, security, etc.)

   • Include: hostname, IP address, function, connection to CHD, OS, owner

4. Data Flow Diagrams

   • Primary payment flows for each channel

   • Backup and recovery flows

   • Administrative access flows

   • Monitoring and logging flows

5. Out-of-Scope Justification

   • Systems claimed as out of scope

   • Documentation of isolation/segmentation

   • Test results proving separation

6. Third-Party Services

   • Payment processors

   • Tokenization services

   • Cloud providers

   • Managed service providers

   • Responsibility matrix (what they control vs. what you control)

7. Segmentation Details

   • Firewall rules relevant to CDE

   • VLAN configurations

   • Network ACLs

   • Segmentation testing results

8. Scope Change Process

   • How scope changes are identified

   • Review and approval workflow

   • Documentation requirements

"A good scope document doesn't minimize your scope—it accurately reflects your scope. An accurate scope that you can defend is infinitely better than a minimized scope that falls apart under audit."

My Annual Scope Review Process

Scope isn't static. I recommend reviewing it quarterly at minimum, but annually is mandatory. Here's my process:

Quarter 1 (Deep Dive):

• Full network scan and discovery

• Compare results to documented scope

• Interview stakeholders about changes

• Update all diagrams and documentation

• Test segmentation controls

Quarter 2 (Focused Review):

• Review change management tickets

• Verify new systems are assessed for scope impact

• Update inventory for any changes

• Sample test segmentation

Quarter 3 (Focused Review):

• Review change management tickets

• Verify new systems are assessed for scope impact

• Update inventory for any changes

• Sample test segmentation

Quarter 4 (Deep Dive):

• Full network scan and discovery

• Compare results to documented scope

• Interview stakeholders about changes

• Update all diagrams and documentation

• Test segmentation controls

• Prepare for annual assessment

I also recommend these triggers for immediate scope review:

• New payment channel added

• New application deployed

• Network architecture changes

• Merger or acquisition

• New third-party services

• Failed segmentation tests

• Security incidents

The Bottom Line: Get Your Scope Right or Pay Forever

I've seen too many organizations treat scope determination as a necessary evil—something to minimize rather than understand. This always backfires.

Organizations that get scope right:

• Spend less on compliance (focused controls on necessary systems)

• Have faster audit cycles (clear documentation, confident auditors)

• Experience fewer breaches (properly secured critical systems)

• Make better architecture decisions (security-first design)

Organizations that get scope wrong:

• Pay for controls on unnecessary systems

• Face expanded scope during audits

• Fail assessments due to missing systems

• Struggle with remediation on incorrectly scoped systems

After fifteen years, here's my advice: invest the time to get scope right from the beginning. Hire a qualified QSA or consultant if needed. Build proper segmentation. Document everything. Test your assumptions.

The few thousand dollars you spend getting scope right will save you hundreds of thousands in ongoing compliance costs and potentially millions in breach remediation.

A healthcare CFO once told me something that stuck: "We spent $15,000 on a proper scope assessment. It identified $400,000 in annual savings through proper segmentation and scope reduction. It's the best money we've ever spent on compliance."

That's the power of proper scope determination.

Now go map your CDE properly. Your future self will thank you.