PCI DSS 4.0.1 Penetration Testing: Requirement 11.4, Segmentation Testing, and the 2025 Changes
PCI DSS 4.0.1 Penetration Testing: Requirement 11.4, Segmentation Testing, and the 2025 Changes
On 31 March 2025, PCI DSS v4's "future-dated" requirements became mandatory. From that date, every entity managing a cardholder data environment (CDE) must fully meet v4's strengthened testing requirements — coasting on v3.2.1 habits is no longer possible.
This guide explains v4.0.1's penetration testing requirements (the 11.4 family) through the questions QSAs actually ask in audits: methodology criteria, frequency rules, segmentation validation, and the most common failures.
11.4.1: The Methodology Requirement — Now the Entity's Own Document
The most frequently missed point: 11.4.1 requires that the penetration testing methodology be defined, documented, and implemented by the entity. Relying on the testing firm's template methodology is not enough — the methodology must be your controlled document, and it must include:
- Industry-accepted approaches (OWASP, PTES and similar)
- Coverage of the entire CDE perimeter and critical systems
- Testing from both inside and outside the network
- Testing to validate segmentation and scope-reduction controls
- Application-layer penetration testing — at minimum covering vulnerabilities listed in Requirement 6.2.4
- Network-layer testing — all components supporting network functions and operating systems
- A review of threats and vulnerabilities experienced in the last 12 months — reflected in test objectives
- A documented approach to assessing and addressing exploitable vulnerabilities
- Retention of test results and remediation records for at least 12 months
The 12-month threat review is the item missing from most methodology templates and now expected by QSAs: the test plan should show "here is how last year's incidents and high-risk vulnerabilities shaped this test's scope."
Frequency Rules: 11.4.2 and 11.4.3
Internal penetration testing (11.4.2):
- At least annually
- After any significant infrastructure or application upgrade or change
- By a qualified internal resource or qualified external third party
- With organizational independence of the tester (QSA or ASV status not required)
External penetration testing (11.4.3):
- Same frequency and independence rules
- Not to be confused with ASV scans: the ASV scan is a quarterly automated external scan, not a penetration test
Vulnerability scanning is a separate requirement (11.3.1): internal scans at least quarterly, with rescans confirming high-risk and critical vulnerabilities are resolved.
11.4.4: Correcting Exploitable Vulnerabilities
Findings are corrected per the entity's risk-based prioritization. v4's difference: it requires a documented approach to classifying what counts as "exploitable." For every critical finding in the report: remediation date, responsible party, and closure evidence. Retest evidence should be retained for high-impact findings.
Segmentation Testing: 11.4.5 and the Service Provider Difference
Segmentation is PCI DSS's primary scope-reduction tool — and v4 hardened its validation:
11.4.5 (general): where segmentation is used, penetration tests on segmentation controls:
- At least annually and after any changes to segmentation controls/methods
- Covering all segmentation controls/methods in use
- Confirming that segmentation actually isolates the CDE from out-of-scope systems
11.4.6 (multi-tenant service providers): the same testing every six months. For providers claiming to isolate customer environments, that's a semi-annual evidence cadence.
Practical note: segmentation tests must explicitly include test cases that attempt to traverse from out-of-scope networks into the CDE — with evidence of the source network, target assets, and the controls encountered.
After 31 March 2025: The Requirements That Bit
Among v4's future-dated requirements, several connect indirectly to penetration testing:
- Per-system uniqueness of authentication parameters and expanded MFA
- Automated scope-verification support (6.3.2, 12.5.2): CDE inventory currency — the source of your pentest scope
- Payment page script management (6.4.3, 11.6.1): script integrity for e-commerce
These became mandatory on 31 March 2025; v4.0.1 (June 2024) changed none of their dates — it only clarified wording and applicability notes.
The 5 Most Common Audit Failures
| Mistake | Why it fails | Fix |
|---|---|---|
| Using the testing firm's template without an entity-owned methodology | 11.4.1 requires entity-defined documentation | Versioned, approved, entity-owned methodology document |
| Missing segmentation test evidence | 11.4.5 demands explicit test cases | Recorded evidence of out-of-scope→CDE traversal attempts |
| Treating ASV scans as pen tests | 11.4.3 expects exploit-focused multi-layer testing | Run both on separate cadences |
| No "last 12 months threat review" section | 11.4.1 explicitly requires it | Mandatory section in the test plan template |
| Closing findings without retest evidence | 11.4.4 requires remediation + proof | Archive retest records |
Checklist
- Do you have an entity-owned, versioned, approved testing methodology?
- Is the 12-month threat review documented in the test plan?
- Are internal and external tests on an annual cadence with change triggers defined?
- Is segmentation testing evidenced (6-month cadence for service providers)?
- Are remediation and retest records retained for 12 months?
- Are ASV scans and penetration testing separated?
- Is the CDE inventory current and matching test scope?
Frequently Asked Questions
How often is penetration testing required under PCI DSS 4.0.1?
Internal and external penetration tests at least annually and after significant infrastructure or application changes (11.4.2, 11.4.3). Where segmentation is used, segmentation testing is annual (11.4.5); multi-tenant service providers test semi-annually (11.4.6). Vulnerability scanning is separate: internal scans quarterly (11.3.1).
Can an ASV scan replace penetration testing?
No. An ASV scan is a quarterly automated external scan by an approved scanning vendor. 11.4.1-11.4.3 expect exploit-focused, application- and network-layer testing with internal and external coverage. They are separate requirements.
Why must the entity define the methodology under 11.4.1?
The requirement states the methodology must be "defined, documented, and implemented by the entity." Relying on the testing firm's methodology fails in audit; the entity must own a methodology document and prove third-party conformance to it.
What's the segmentation testing difference for service providers?
Multi-tenant service providers must test segmentation controls semi-annually rather than annually (11.4.6) — isolation of customer environments must be continuously evidenced.
Closing
PCI DSS v4 moved penetration testing from "an annual external report" to an entity-owned, threat-aware, evidence-chained programme. Past the 31 March 2025 deadline, the question is no longer "did we do a pentest" — but "do our methodology, segmentation evidence, and remediation records hold together in audit."
Eresus Security conducts PCI DSS 11.4-aligned internal/external penetration testing and segmentation validation. To evaluate your CDE's test scope, request a scoping call.
Security Validation
Have you tested this risk in your own system?
Eresus Security delivers real exploit evidence through penetration testing, AI agent security, and red team operations.
Request a pilot testRelated Services