PCI DSS v4.0 Requirement 11.4 mandates internal and external penetration testing at least every 12 months and after any significant change to the cardholder data environment (CDE), following a defined methodology (NIST 800-115, OWASP, PTES) and covering network and application layers. Exploitable findings must be fixed and retested. If you use segmentation to cut PCI scope, 11.4.5 segmentation testing proves it holds — annually for merchants, every 6 months for service providers. The tester must be organisationally independent and qualified (not necessarily a QSA). Miss any of this and your assessment stalls. Full breakdown below; for the segmentation deep-dive see PCI DSS 11.4.5 segmentation testing.
// 01 What Requirement 11.4 actually says
PCI DSS puts penetration testing in Requirement 11.4, and it's more prescriptive than most frameworks. You need both external and internal penetration tests: external, from outside the perimeter against internet-facing systems; internal, from inside the network simulating an attacker who's already past the edge. Both must run at least once every twelve months and after any significant change. The scope is the entire CDE perimeter and critical systems, and testing must cover both the network layer and the application layer — a network-only test doesn't satisfy it. Crucially, any exploitable vulnerability found must be corrected and the test repeated to verify the fix. A report full of open criticals is not a passing test.
// 02 The tests you actually need
External pentest
From outside the perimeter against internet-facing CDE systems — the classic attacker's-eye view.
Internal pentest
From inside the network, modelling an attacker who already has a foothold. See internal vs external.
Application layer
The payment and supporting applications and APIs in the CDE, not just the network.
Segmentation test
Proof that your scope-reducing segmentation controls actually isolate the CDE (11.4.5).
// 03 Segmentation testing — the scope multiplier
Most organisations use network segmentation to shrink PCI scope: wall the CDE off from the rest of the corporate network so only a small, controlled zone is “in scope.” That's smart — but PCI makes you prove it works. Requirement 11.4.5 requires testing the segmentation controls at least every twelve months (and every six months for service providers), plus after any change to segmentation, to confirm the out-of-scope network genuinely cannot reach the CDE. The stakes are high: if segmentation fails a test, the systems you assumed were out of scope fall back into PCI scope, ballooning your assessment. We break down the technique in PCI DSS 11.4.5 segmentation testing.
// 04 Who can test, and the methodology
PCI is specific about independence but flexible on credentials. The tester must be organisationally independent of the team that manages the tested systems and qualified — but PCI does not require a QSA or any single named certification. That means a suitably separate internal resource can do it, though most organisations use a qualified external specialist for genuine independence and credibility with their assessor. Whoever tests must follow a documented, industry-accepted methodology — NIST SP 800-115, OWASP, or PTES — and record their qualifications. This is the difference between a real penetration test and an automated scan: a scan alone never satisfies 11.4.
// 05 Cadence & the “significant change” trap
The headline cadence is annual — but the phrase that catches teams out is “after any significant change.” An infrastructure upgrade, a new system component in the CDE, a change in network topology, or a major application release can all count, and each resets the clock on the affected components. For organisations shipping frequently, that means testing the changed parts more than once a year. Segmentation adds its own rhythm: annually for merchants, six-monthly for service providers. The practical discipline is to build testing into your change process, not just an annual calendar entry — and to book with enough lead time to fix and retest before your assessment. Map it alongside your other obligations with the requirements-by-framework guide.
// 06 Frequently asked questions
Does PCI DSS require penetration testing?
Yes — Requirement 11.4 requires internal and external testing at least every 12 months and after any significant change to the CDE, following a defined methodology, covering network and application layers across the CDE perimeter and critical systems. Exploitable findings must be corrected and retested. It applies to merchants and service providers, scaled to validation level.
What is segmentation testing?
If you use segmentation to reduce PCI scope, Requirement 11.4.5 requires testing that the controls actually isolate the CDE — at least annually for merchants, every six months for service providers, and after any segmentation change. If segmentation fails, the out-of-scope systems fall back into PCI scope.
Who can perform a PCI penetration test?
An organisationally independent, qualified tester — internal (separate from the team managing the systems) or external. PCI doesn't mandate a QSA or a specific certification, but most use an external specialist for independence. The tester must follow a recognised methodology (NIST 800-115, OWASP, PTES) and document their qualifications.
How often is PCI testing required?
Internal and external testing at least annually and after any significant change to the CDE. Segmentation testing at least annually for merchants and every six months for service providers, plus after any segmentation change. Because significant changes reset the clock, frequent releases often mean testing changed components more than once a year.
// 07 Related reading
- PCI DSS 11.4.5 segmentation testing — the scope-critical control in depth.
- Internal vs external testing and requirements by framework.
- Pentesting for banks and the requirements finder.