5 October 2026 · 9 min read · By Michael van Mameren, Lead Penetration Tester (OSCP)
PCI DSS Penetration Testing: What Requirement 11.4 Demands and What Your QSA Accepts
PCI DSS is the one framework that names penetration testing outright. Requirement 11.4 sets the scope, the cadence and the retest rule. Here is how to meet it without surprises at assessment time.
Is penetration testing mandatory under PCI DSS?
Yes. Unlike ISO 27001 or SOC 2, the Payment Card Industry Data Security Standard (PCI DSS) explicitly requires penetration testing. PCI DSS v4.0.1 is the current version; v4.0 was retired on 31 December 2024 and the requirements that were future-dated during the transition became mandatory on 31 March 2025. From that date every assessment runs against the full v4.0.1 control set, including the penetration-testing requirements in 11.4.
The requirement applies to any organisation that stores, processes or transmits cardholder data, and to the service providers that can affect the security of that data. Whether you complete a Self-Assessment Questionnaire (SAQ D, for example) or a Report on Compliance with a Qualified Security Assessor (QSA), the testing evidence is the same.
Requirement 11.4, sub-requirement by sub-requirement
Requirement 11.4 states that external and internal penetration testing is regularly performed, and exploitable vulnerabilities and security weaknesses are corrected. The sub-requirements set the detail.
11.4.1 A defined penetration testing methodology
You must document and implement a methodology that covers the entire cardholder data environment (CDE) perimeter and critical systems, tests from inside and outside the network, validates segmentation controls, includes application-layer testing (at minimum the vulnerabilities in Requirement 6.2.4) and network-layer testing, reviews threats and vulnerabilities from the last 12 months, and defines how findings are retained and remediated.
11.4.2 Internal penetration testing
Performed at least once every 12 months and after any significant infrastructure or application change, by a qualified internal resource or a qualified external third party with organisational independence from the systems being tested.
11.4.3 External penetration testing
Same cadence and independence rules as internal testing, against the external perimeter of the CDE and any system that can reach it.
11.4.4 Exploitable vulnerabilities are corrected and retested
Findings are remediated according to your risk-ranking process (Requirement 6.3.1) and the penetration test is repeated to verify the corrections. A report without a retest does not close 11.4.4.
11.4.5 and 11.4.6 Segmentation testing
If you use segmentation to reduce PCI scope, the segmentation controls must be penetration-tested at least every 12 months and after changes (11.4.5). Service providers must test segmentation at least once every six months (11.4.6).
11.4.7 Multi-tenant service providers
Multi-tenant providers must support their customers' external penetration testing, for example by offering a testing window or evidence of their own testing of the shared environment.
PCI DSS penetration testing cadence at a glance
The minimum frequencies PCI DSS v4.0.1 sets. Your own risk analysis may require more.
| Test | Merchant | Service provider | Also after |
|---|---|---|---|
| Internal penetration test (11.4.2) | Every 12 months | Every 12 months | Significant infrastructure or application change |
| External penetration test (11.4.3) | Every 12 months | Every 12 months | Significant infrastructure or application change |
| Segmentation test (11.4.5 / 11.4.6) | Every 12 months | Every 6 months | Changes to segmentation controls or methods |
| Retest of exploitable findings (11.4.4) | After every remediation round | After every remediation round | Not applicable |
| Internal and external vulnerability scans (11.3) | Every 3 months | Every 3 months | Significant change; external scans by an ASV |
What a QSA checks in your penetration-test evidence
Assessors review the report and the surrounding process. Make sure each of these is visible before the assessment starts.
- The documented methodology (11.4.1) and proof that the test followed it, with an industry-accepted approach such as NIST SP 800-115, PTES or OWASP referenced
- A scope statement that matches the CDE diagram and the in-scope system inventory, including segmentation boundaries
- Tester qualifications and organisational independence; for external firms, named testers and certifications
- Dates showing the test falls inside the 12-month window (or 6 months for service-provider segmentation testing)
- Findings ranked by severity using your risk-ranking process, with exploitability evidence
- Remediation records and a dated retest section confirming exploitable findings were fixed
- Evidence that application-layer testing covered the Requirement 6.2.4 vulnerability classes (injection, broken access control, cryptographic failures and others)
Scoping the test to the cardholder data environment
PCI DSS scope is the cardholder data environment plus every system that connects to it or could affect its security. Penetration testing must cover the CDE perimeter and critical systems from both sides: external testing from the internet and internal testing from inside the network, including from out-of-scope segments to prove the segmentation holds. For organisations using tokenisation or a hosted payment page to reduce scope, the test must confirm that no cardholder data leaks into the environment you have declared out of scope.
The common failure we see at assessment time is a test that covers the public web application but not the internal network path to the database, or a segmentation test that only runs from one segment. A QSA will treat both as incomplete evidence for Requirement 11.4.
How we run PCI DSS penetration tests
We scope against your CDE diagram and in-scope inventory, agree the methodology document up front so it satisfies 11.4.1, test externally and internally with segmentation validation from every adjacent segment, cover the application layer against the Requirement 6.2.4 classes, and deliver a report mapped to each sub-requirement of 11.4. Remediation is followed by a dated retest appendix so your QSA can close 11.4.4 without a second engagement.
Our testers are OSCP-certified and named in the report, which satisfies the organisational-independence and qualification questions assessors ask first.
Frequently asked questions
PCI DSS assessment coming up?
We scope to your cardholder data environment, follow a documented 11.4.1 methodology and deliver a report mapped to every sub-requirement, retest included. Talk to an expert.