PCA Cyber Security provides PCI DSS-compliant penetration testing for cardholder data environments (CDEs). Our team helps payment device manufacturers and payment service providers verify that their CDEs meet or even exceed PCI DSS requirements.

We are also a PCI Associate Participating Organization (APO) and perform continuous testing for merchants and service providers across CDEs of every type and complexity. That experience has shown us the value of testing thoroughly against every PCI DSS requirement. 

This article explains why and walks through the current (2026) PCI DSS penetration testing requirements.

What Type of Penetration Testing Is Needed for Cardholder Data Environments Under PCI DSS?

PCI DSS mandates a mixture of internal and external penetration testing of the CDE as a whole. Note that penetration testing is separate from vulnerability scanning, which is covered under 11.3.

The penetration testing requirement (11.4) sits within PCI DSS Requirement 11, "Test Security of Systems and Networks Regularly," which breaks the testing required for compliance into five sub-sections.

Below, the sub-sections are numbered as PCI lists them, with a short explanation of what each requires.

11.4.1 Penetration testing that is “defined, documented, and implemented”

Organizations must define, document, and implement a penetration testing methodology for the cardholder data environment. PCI DSS v4.0.1 requires a documented penetration testing methodology that follows “Industry-accepted penetration testing approaches” such as NIST SP 800-115. Testing must also cover the full CDE perimeter at the network and application layers.

11.4.2 Internal testing

Internal testing starts from inside the network, or from a privileged position, and documents the effectiveness of internal controls. This kind of testing looks for the opportunities an attacker might find once inside a network.

For example, can an attacker move laterally across systems, escalate privileges, and ultimately reach systems that store, process, or transmit cardholder data?

Internal testing must be carried out at least once every 12 months and after any significant change to the network infrastructure. 

11.4.3 External testing

External testing begins outside the network perimeter, with no knowledge of internal systems. 

In a CDE, that means testing public-facing servers, firewalls, and network security controls, remote access points, and any exposed services or interfaces. Applications and payment devices need to be tested too, not just the network.

PCI DSS requires cardholder data environments to be tested externally on the same cadence as internal testing: at least every 12 months and after any significant change.

11.4.4 Remediation and retesting

When an environment is tested, vulnerabilities are very likely to be found. We have never tested a CDE, PCI-approved or not, without finding some. Requirement 11.4.4 addresses this by requiring documentation of how identified vulnerabilities were fixed and the environment retested.

11.4.5 Segmentation testing

When the cardholder data environment is segmented, which is the case in most deployments, testing must also attempt to cross the segmentation boundaries.

PCI DSS Compliant Penetration Testing Is Where CDE Security Starts

Exposing a CDE to the real world, with all of its interlinked devices, software, and processes, creates a large and lucrative attack surface. It evolves faster than any single point-in-time test can capture, and it attracts attackers who probe far deeper.

This has always been the case. Some of the most damaging POS breaches on record happened to organizations that were compliant with the standards of the day. The Target breach of 2013, for example, involved a malware deployment on POS devices after attackers crossed into the cardholder data environment. 

Since then, standards have changed, but because the threat landscape keeps moving, our team consistently finds vulnerabilities in already tested devices.

Attackers using LLMs can now find and exploit vulnerabilities faster than ever. According to M-Trends 2026, the average time-to-exploit has dropped to -7 days, meaning vulnerabilities are now routinely exploited before a patch is even released. 

PCI DSS validation provides a point-in-time assessment that a payment environment meets the standard's security requirements. However, given today's rapid time-to-exploit, no point-in-time assessment can fully account for the risks that deployed payment devices and the wider cardholder data environment (CDE) will face over time.

When PCA Cyber Security tested a sample of PCI-approved devices intended to sit within CDE infrastructure, we found vulnerabilities with a CVSS score above 7 in 100% of the devices tested. Any CDE connected to those devices would have been simultaneously compliant and exposed to compromise.

PCI DSS Penetration Testing for CDEs

PCI DSS compliant penetration testing is mandatory, structured, and essential. It is also point-in-time, and as the time-to-exploit data shows, attackers no longer wait for the next assessment cycle. 

Compliance brings a cardholder data environment up to the baseline. Staying secure in deployment takes continuous testing against the way attackers actually operate.

PCA Cyber Security works on both sides of that equation, identifying and mitigating vulnerabilities across the entire PCI-regulated environment, including APIs, networks, devices, and all connected and interlinked systems. Our team simulates real attack scenarios to assess network, application, and segmentation controls, ensuring compliance with PCI DSS v4.0.1 requirements and resilience against real-world cyber risks.