What is a cardholder data environment

01. what falls in scope

Systems that fall inside the CDE.

Scope is determined by data flow and network connectivity — not by assumption. These six categories cover the most frequently missed in-scope systems.

Cardholder data systems

Any system that stores, processes, or transmits Primary Account Numbers (PAN), cardholder names, expiration dates, or service codes. If a system touches raw card data, it is core CDE.

Systems connected to CDE systems

Any system with network access to a CDE system, regardless of whether it handles card data itself. Jump hosts, admin consoles, monitoring systems, logging aggregators — if they have a network path to the CDE, they are in scope.

Authentication infrastructure

Active Directory, LDAP, RADIUS, or identity providers that CDE systems authenticate against. Compromising the auth layer gives an attacker access to CDE systems without touching payment data directly.

Segmented systems with connections

Systems assumed to be "out of scope by segmentation" that have even one active network connection to an in-scope system are in scope. Segmentation must be tested — not assumed.

CI/CD pipelines and deployment systems

Any pipeline that deploys code to a CDE application is connected to the CDE. Compromise of the pipeline means compromise of everything it can deploy to.

Logging and monitoring systems

Systems that receive logs, metrics, or security event data from CDE systems have a read path into the CDE. If an attacker compromises the logging system, they can surveil CHD flows. In scope.

The three most common CDE scoping mistakes

These three come up in almost every PCI engagement where the client has done their own scoping before the test. They are not obscure edge cases — they are structural assumptions that are wrong often enough to matter.

Mistake 1: Assuming a hosted payment page eliminates all scope

Hosted payment pages (Stripe Checkout, Braintree Drop-in UI, Adyen HPP) do reduce scope in a meaningful way: your servers never receive raw PANs, which removes you from the requirements around cardholder data storage and PAN encryption at rest. That is real scope reduction and your QSA will recognize it.

What it does not do is eliminate scope entirely. Consider what stays connected: your checkout flow redirects to the hosted page, which means the system handling the redirect is in the flow. Webhook receivers that the payment processor calls back when a transaction completes are connected to CHD flows. Any admin portal where your team can view order history, payment status, or transaction records has a read path into payment data — or to systems that do. Any API that your backend calls to retrieve payment records from the processor connects you back to CHD flows.

The QSA draws the boundary. The penetration test validates that the boundary is real: that the systems your QSA placed outside scope cannot reach in-scope systems through paths that should not exist. We regularly find that redirect systems, webhook handlers, and internal admin tools are in scope at clients who assumed they were out because the PAN never touches their database.

Mistake 2: Treating segmentation as scope reduction without testing it

PCI DSS Requirement 11.3.4 exists because many organizations claim segmentation without verifying it holds under adversarial conditions. The standard is clear: if you are using segmentation to reduce PCI scope, you must test that the segmentation controls work. A firewall rule between a VLAN and the CDE is a configuration. A passing segmentation test is evidence.

The test must demonstrate that an attacker positioned in the non-CDE network segment cannot reach CDE systems. This is not a paper review of firewall rules. The tester attempts to cross the boundary from the non-CDE side: probing for misconfigurations, checking for dual-homed hosts that bridge both segments, testing for lateral movement paths that bypass the firewall. ACLs, micro-segmentation controls, and cloud security groups all need to be validated this way.

We find failures here more often in cloud environments than in traditional network segments, because cloud security groups are easy to misconfigure and changes are easy to make without triggering a change-management review. A one-line Terraform change that opens an ingress rule can collapse a segmentation boundary that was otherwise sound.

Mistake 3: Forgetting that logging and backup systems are in scope

SIEMs, log aggregators, and SIEM agents that receive events from CDE hosts are in scope by connectivity. Backup systems that copy data from CDE servers — even if they only store encrypted backups — have a network path to CDE systems and are therefore in scope.

We find this most often in cloud environments where a single log group, S3 bucket, or storage account receives data from both CDE and non-CDE infrastructure. The single shared destination connects the non-CDE systems to the same storage that receives CDE logs, and that connection puts the non-CDE systems in scope. Separating logging infrastructure by CDE boundary is operationally inconvenient but required if you want to actually reduce scope rather than just claim to.

What penetration testing covers under PCI DSS v4.0

Requirement 11.3 has three distinct sub-requirements, each of which the penetration test must satisfy independently.

Requirement 11.3.1 (internal penetration testing) tests the CDE from inside the network. The premise is that an attacker who has already gained internal access — through phishing, a compromised endpoint, or a rogue insider — attempts to reach cardholder data. The test covers internal network paths, authentication weaknesses, privilege escalation within the CDE, and lateral movement between in-scope systems. A passing test demonstrates that internal attackers cannot reach CHD through the paths available to them.

Requirement 11.3.2 (external penetration testing) tests the CDE boundary from outside: simulating an internet-based attacker attempting to reach CHD through publicly accessible systems. This covers external-facing applications, APIs, and infrastructure that have any path into the CDE. It is not a vulnerability scan — the tester actively attempts to chain findings and reach in-scope systems, not just identify vulnerabilities in isolation.

Requirement 11.3.4 (segmentation testing) applies when segmentation is used to reduce PCI scope. As described above, the tester attempts to cross from non-CDE segments into CDE segments and must document that the boundary holds. This finding feeds directly into your QSA's scope assessment: a passing segmentation test is the evidence that supports the reduced-scope claim.

All three requirements must be satisfied at least annually and after any significant infrastructure or application change. What counts as significant is a judgment call your QSA makes, but additions to the CDE network segment, changes to segmentation controls, new applications deployed inside the CDE, and changes to authentication infrastructure all typically trigger a re-test requirement.

The penetration test report becomes evidence in the QSA assessment. Findings, their severity, remediation status, and retest results all appear in the report. The QSA reviews the report for coverage (did the test actually cover Req 11.3.1, 11.3.2, and 11.3.4?), methodology (was the testing methodology sound?), and remediation (are critical and high findings closed or mitigated?). Our PCI DSS penetration test page covers the full deliverable set and QSA-ready report format. For payment API and fintech-specific considerations, see our fintech penetration testing page.

03. faq

Questions about CDE scope.

Does using a hosted payment page eliminate my CDE?

It reduces scope, but rarely eliminates it. Hosted payment pages (Stripe Checkout, Braintree Drop-in UI) mean your servers do not touch raw card numbers — that removes you from PAN storage requirements. But if any of your systems redirect to the hosted page, receive webhooks from the processor, or access the customer's payment records through an API, those systems are connected to CHD flows and may fall in scope. Your QSA determines the boundary; penetration testing validates whether the segmentation controls actually hold.

What is PCI DSS Requirement 11.3 and how does penetration testing satisfy it?

Requirement 11.3 mandates penetration testing of the CDE boundary. 11.3.1 requires internal penetration testing — from inside the network, testing whether an attacker who has gained internal access can reach CHD. 11.3.2 requires external penetration testing — from outside the boundary, simulating an internet-based attacker. 11.3.4 requires testing network segmentation controls if segmentation is used to reduce PCI scope. All three must be conducted at least annually and after any significant infrastructure change.

What counts as "connected to the CDE" for scope purposes?

Any system with network access to a CDE system falls in scope for penetration testing, even if it does not itself store or process cardholder data. This includes: authentication servers that CDE systems authenticate against, monitoring and logging systems that receive logs from CDE systems, jump hosts used for administrative access to CDE systems, and CI/CD pipelines that deploy code to CDE applications. The connectivity, not the data, determines scope.

→ related

Scoping a PCI DSS penetration test?

30-minute scoping call covers your CDE boundary, segmentation controls, and QSA timeline. Fixed fee. Free first call.

Book a 30-min scoping call PCI DSS pentest page

What is a cardholder data environment?