PCI DSS Req 11.4 requirements, explained

The 11.4 sub-requirements

Requirement 11.4 in PCI DSS v4.0.1 is not a single test — it is seven sub-requirements, and a ROC that cites "we did a pentest" without mapping to each one is exactly what draws QSA follow-up questions. Knowing which sub-requirement a given piece of evidence satisfies is most of the battle.

• ✅ 11.4.1 — a defined, documented penetration-testing methodology is in place, industry-recognized (e.g. NIST SP 800-115, OWASP) and consistently followed, not chosen ad hoc per engagement.
• ✅ 11.4.2 — internal penetration testing of the cardholder data environment (CDE) and any connected systems, run from the perspective of an attacker already inside the network.
• ✅ 11.4.3 — external penetration testing of every internet-facing component of the CDE and its connected systems.
• ✅ 11.4.4 — exploitable vulnerabilities and security weaknesses found during 11.4.2/11.4.3 testing are corrected, and the fix is retested to confirm it actually closed the issue.
• ✅ 11.4.5 — segmentation controls (if used to reduce PCI DSS scope) are tested to confirm they are operational and effective, for all entities.
• ✅ 11.4.6 — service providers using segmentation must additionally test those controls on a shorter cadence than 11.4.5 requires of other entities.
• ✅ 11.4.7 — multi-tenant service providers must support their customers' ability to perform external penetration testing per Requirements 11.4.3 and 11.4.4.

Each of these produces a distinct piece of evidence in the assessment. 11.4.1 is a methodology document; 11.4.2/11.4.3 are test reports; 11.4.4 is a remediation-and-retest record tied to specific findings; 11.4.5/11.4.6 are segmentation test results; 11.4.7 is a statement of how a service provider accommodates tenant-initiated testing. A QSA reviewing the ROC is checking for all seven, not just the headline report.

Frequency & triggers

The baseline cadence for 11.4.2 and 11.4.3 is at least once every 12 months, and again after any significant change to the CDE or the systems connected to it. "Significant change" is deliberately broad — a re-architected network segment, a new third-party integration with a path into the CDE, or a major application release can all trigger a retest obligation outside the annual clock. Treating the requirement as a once-a-year calendar entry, rather than an event-driven one, is a common way programmes fall out of continuous compliance between assessments.

Segmentation testing under 11.4.5 follows the same at-least-annual cadence, applied to any entity that uses segmentation to reduce PCI DSS scope. Service providers carry a stricter clock under 11.4.6: segmentation controls must be tested at least every six months, reflecting the larger blast radius when a service provider's segmentation fails.

Internal vs external, and independence

11.4.2 and 11.4.3 are not interchangeable, and both are mandatory — an external-only test doesn't satisfy the internal requirement, and vice versa. External testing (11.4.3) covers everything the CDE exposes to the internet: payment APIs, customer-facing applications, remote-access endpoints. Internal testing (11.4.2) assumes a foothold already exists inside the network and probes segmentation boundaries, internal APIs, and any system with a lateral path to cardholder data.

PCI DSS v4.0.1 requires the tester to be organizationally independent of the systems under test — someone who did not build, configure, or maintain the environment being tested, and has no stake in its outcome. That independence can be satisfied by a qualified internal resource who sits outside the team responsible for the CDE, or by a third party; a Qualified Security Assessor is not a prerequisite for the tester role itself. What the QSA checks during the assessment is evidence of that independence — who performed the test, their qualification, and their organizational relationship to the tested systems — not a specific certification.

How breachr maps each sub-requirement

breachr structures every PCI engagement around the seven 11.4 sub-requirements from the start, rather than leaving the mapping to a manual exercise after the fact. The documented methodology satisfies 11.4.1; internal and external testing run as distinct, clearly labeled workstreams for 11.4.2 and 11.4.3; every exploitable finding carries a remediation-and-retest record that closes out 11.4.4; and segmentation testing is tracked against the correct 11.4.5/11.4.6 cadence for your entity type — see the segmentation testing guide for how that evidence is built.

Every finding is signed with a cryptographic chain of custody recording who or what performed the test — a named human tester or an identified AI agent — and against which scope, so the record a QSA needs is already in the evidence pack. The result is an evidence pack organized by sub-requirement rather than a single undifferentiated report, architected to drop directly into the ROC without you having to reconstruct which finding satisfies which line item.

Related guides