PCI-DSS Penetration Testing: Requirement 11.4 Explained
Unlike SOC 2, PCI-DSS doesn't leave penetration testing implied — Requirement 11.4 names it outright. That clarity creates its own confusion, mostly around how it differs from the quarterly ASV scan you're also required to run, and what "segmentation testing" means as a separate obligation. Here's the requirement broken down plainly.
What Requirement 11.4 actually says
PCI-DSS v4.0 Requirement 11.4 requires penetration testing of the cardholder data environment (CDE) at both the network layer and the application layer. It's explicit in a way most other frameworks aren't: this isn't an inferred expectation built from adjacent controls, it's a named requirement with its own sub-clauses covering methodology, cadence, and scope.
- Network-layer testing — covering infrastructure components that support or connect to the CDE.
- Application-layer testing — covering applications that store, process or transmit cardholder data, including common exploitable weaknesses.
- Segmentation testing — verifying that controls isolating the CDE from the rest of the network actually hold, tested separately from the general penetration test.
- Methodology requirements — testing must follow an industry-accepted penetration testing methodology, address threats and vulnerabilities from the past 12 months, and be performed from both outside and inside the network.
ASV scan vs. penetration test — they are not the same obligation
| ASV Scan (Req. 11.3) | Penetration Test (Req. 11.4) | |
|---|---|---|
| Method | Automated, external scanning | Exploitation-led, manual/human-verified |
| Who performs it | Must be an Approved Scanning Vendor | Qualified internal or independent external tester |
| Cadence | At least quarterly, plus after network changes | At least annually, plus after significant changes |
| Scope | External-facing systems in the CDE | Network and application layer, internal and external |
| Segmentation coverage | Not covered | Required separately, every 6 months for service providers |
Treating a quarterly ASV scan as if it satisfies the annual penetration testing requirement is one of the most common PCI-DSS compliance gaps we see — they're both real obligations, running on different cadences, performed by different kinds of provider, and testing different depth. Passing quarterly scans does not mean the annual penetration test requirement has been met.
Cadence: annual, plus after significant change
Penetration testing under Requirement 11.4 is required at least annually. It is also explicitly required after any significant change to the network or the CDE — a new segment, a major application deployment, a new external connection. "Once a year and forget it" is not compliant if a significant change happened mid-cycle; the test needs to reflect the environment as it currently exists, not as it existed at the last scheduled test.
Segmentation testing specifically runs on its own clock: at least every six months for service providers, and at least annually for merchants relying on segmentation to reduce PCI-DSS scope. If your CDE scope argument depends on segmentation working, that's exactly the control an assessor will want independently verified on a tight cadence — not assumed from a network diagram.
"An ASV scan tells you the CDE's front door is locked. Requirement 11.4 asks whether someone can still get in a different way."
Who's qualified to run the test
PCI-DSS doesn't mandate a specific personal certification for the tester, but it does require the engagement to follow an industry-accepted penetration testing methodology and be performed by a resource with organizational independence from the systems being tested — meaning the team that built or manages the CDE shouldn't be the same team attesting it's secure. Qualified internal testers are permitted if that independence exists; otherwise, an external third party is the more defensible choice for the assessment.
How ComplyArmor supports PCI-DSS evidence
ComplyArmor's Smart PTaaS covers both network and application-layer testing required under Requirement 11.4, with every finding mapped to PCI-DSS control language alongside OWASP Top 10, ASVS, ISO 27001 and SOC 2 — see our full compliance mapping. Continuous testing through our PTaaS model means significant-change retesting isn't a separate scramble every time your CDE changes — coverage picks up the change as part of the ongoing engagement rather than waiting for the next scheduled annual test.
Frequently asked questions
Does PCI-DSS require penetration testing?
Yes, explicitly. PCI-DSS Requirement 11.4 mandates penetration testing of the cardholder data environment, covering both the network layer and the application layer, unlike SOC 2 or ISO 27001 where the requirement is implied rather than named outright.
How often is PCI-DSS penetration testing required?
At least annually, and additionally after any significant change to the cardholder data environment or the network — a new segment, a major application update, a new connection point. Segmentation testing specifically is required at least every six months for service providers under PCI-DSS v4.0.
What's the difference between a PCI ASV scan and PCI penetration testing?
An ASV (Approved Scanning Vendor) scan is an automated, externally-run quarterly vulnerability scan required under Requirement 11.3, performed by a PCI SSC-approved vendor using a defined methodology. Penetration testing under Requirement 11.4 is a separate, deeper, exploitation-led exercise covering both network and application layers, required annually rather than quarterly, and testing segmentation controls specifically.
Does the penetration tester need to be PCI-qualified or certified?
PCI-DSS doesn't mandate a specific certification for the tester, but it does require the test to follow an industry-accepted penetration testing methodology and be performed by a qualified internal resource or qualified external third party with organizational independence from the system being tested.
What is segmentation testing under PCI-DSS?
Segmentation testing verifies that network controls separating the cardholder data environment from the rest of your network actually work as designed — that an attacker who compromises a system outside the CDE genuinely cannot reach systems inside it. It's tested separately from general penetration testing and, for service providers, at a shorter cadence.
If your last penetration test predates a significant CDE change, that gap is worth closing before your next assessment, not after an assessor flags it.