PCI DSS v4.0 (effective from March 2025 for most controls, March 2025 for "future-dated" controls) clarifies and tightens penetration testing requirements. This guide breaks down exactly what Requirement 11.4 mandates, what evidence QSAs expect, and how scope decisions affect cost.
PCI DSS v4.0 Requirement 11.4 mandates external and internal penetration testing of the cardholder data environment (CDE) and any systems connected to it. Testing must be performed at least annually and after any significant infrastructure or application change.
Key change from v3.2.1: 11.4 explicitly requires segmentation testing for organisations using network segmentation to reduce CDE scope. If you rely on segmentation, you must prove it works through penetration testing of the segmentation controls themselves.
| Requirement | What it covers | Frequency |
|---|---|---|
| 11.4.1 - Methodology | A defined penetration testing methodology aligned to industry-accepted standards (NIST SP 800-115, OSSTMM, OWASP) | Documented and reviewed annually |
| 11.4.2 - Internal testing | Internal pentest of CDE and CDE-connected systems | Annually + after significant change |
| 11.4.3 - External testing | External pentest of CDE and exposed CDE-connected interfaces | Annually + after significant change |
| 11.4.4 - Exploitable findings | Exploitable vulnerabilities and weaknesses must be corrected and re-tested | Each finding |
| 11.4.5 - Segmentation testing | Pentest of segmentation controls to confirm out-of-scope systems remain isolated from CDE | At least annually (service providers: every 6 months) |
| 11.4.6 - Service provider segmentation | Service providers using segmentation must test segmentation at least every six months | Six-monthly (service providers only) |
The cardholder data environment (CDE) is in scope. So is anything connected to the CDE, even if it does not itself store, process, or transmit cardholder data. This is a broader bracket than many organisations initially assume.
Connected-to means network connectivity, shared infrastructure, shared authentication, or any other path that could let an attacker pivot. A jump server, AD domain controller, or shared logging system that touches CDE is in scope.
Network segmentation is your tool to reduce scope. If you implement segmentation correctly, only the CDE itself and the segmentation controls need testing. If your segmentation is weak or untested, the QSA will expand scope to include connected systems.
Organisations underscope to reduce pentest cost and then fail the QSA assessment when the QSA expands scope to include all "connected to" systems. The correct sequence: scoping workshop first, segmentation design review, segmentation pentest, then full-scope CDE pentest. This is more expensive up front but cheaper than rework.
Documented methodology covering the eight areas in 11.4.1: organisational independence, defined scope, methodology, type, vulnerability identification, exploitation attempts, post-exploitation, and reporting.
Penetration test report including: scope, methodology, findings with severity, exploitation evidence, and remediation recommendations.
Evidence of remediation of all exploitable findings before re-test sign-off (11.4.4).
Segmentation test results demonstrating effective isolation between CDE and out-of-scope environments (11.4.5 / 11.4.6).
Tester qualification evidence (certifications, experience). QSAs increasingly expect CREST or equivalent credentials.
Records of any change-driven mid-cycle pentests (after significant application or infrastructure changes).
PCI DSS v4.0 expects re-testing after significant change. The standard does not exhaustively define "significant" but typical triggers are: new infrastructure components added to CDE, upgrades or replacement of CDE components, changes to network topology or segmentation, changes to authentication systems, new application releases handling cardholder data, and changes to payment integrations.
Routine patching is usually not "significant". Major upgrades, architectural changes, or new integrations almost always are. Document your change classification and the resulting test decision so the QSA can validate.
We deliver QSA-aligned penetration testing for PCI DSS v4.0 Requirement 11.4: methodology documentation, internal and external testing, segmentation validation, remediation re-testing, and QSA-ready reporting.
Reports are formatted to satisfy the eight 11.4.1 methodology areas with explicit cross-references to v4.0 requirement IDs. This makes QSA review faster and reduces back-and-forth during assessment.
For service providers under 11.4.6, we run segmentation testing on a six-monthly cadence with continuity of the same lead tester.
PCI DSS v3.2.1 was retired on 31 March 2024. From that date, v4.0 is the only valid version. Certain "future-dated" controls (including some 11.4 elements) became mandatory from 31 March 2025.
No. ASV scans are vulnerability scanning under Requirement 11.3. They are a separate requirement from penetration testing under 11.4. You need both.
Internal testing is allowed if the testers are organisationally independent from the system under test. In practice, this is hard to demonstrate to a QSA at smaller organisations. External pentest providers are the cleaner answer for QSA assessment.
11.4.4 requires correction and re-testing of exploitable findings before sign-off. The penetration test is not "complete" for compliance purposes until findings are remediated and confirmed by a follow-up test.
A 30-minute scoping call covers your specific context and lets us recommend the right approach. We will tell you honestly if our service is not the right fit.
Book a scoping callRelated: PCI DSS Compliance & Certification →