.svg)
Requirement 11.4 is where more PCI assessments stall than anywhere else, and the reason is almost always the same: someone assumed the quarterly ASV scan covered it. It does not. They are different requirements with different evidence.
What 11.4 Actually Requires
PCI DSS v4.0 requires a defined penetration testing methodology and testing performed against it. In practice that means:
- External penetration testing of the CDE perimeter, at least annually and after significant changes
- Internal penetration testing from inside the network, on the same cadence
- Application-layer and network-layer testing, covering the vulnerability classes relevant to your environment
- Segmentation testing where segmentation is used to reduce scope — every six months for service providers, at least annually for merchants
- Remediation and retesting of exploitable findings, with evidence of both
The methodology itself has to be documented. A QSA will ask to see it, not just the report.
Why a Scan Does Not Count
An ASV scan is automated, external, and required quarterly under a different sub-requirement. It identifies known vulnerabilities against a signature set and produces a pass or fail.
A penetration test is manual. A tester chains findings, attempts exploitation, and establishes what an attacker could actually reach. A scanner reports that a service is running an outdated version. A tester demonstrates whether that gets them to cardholder data.
Vulnerability assessments sit in between and also do not satisfy 11.4. If the deliverable is a prioritised list of findings with no exploitation and no attack path, it is not a penetration test.
Segmentation Testing: The Half Everyone Forgets
If you rely on segmentation to keep systems out of scope, you have to prove the segmentation works. Segmentation testing verifies that out-of-scope networks genuinely cannot reach the CDE.
This is a distinct test with distinct evidence. Teams frequently commission a CDE pentest, assume they are covered, and then discover at fieldwork that segmentation testing was never performed. For service providers the cadence is every six months, which means it does not align with your annual pentest and needs its own scheduling.
If segmentation testing fails, the consequence is not just a finding. Your scope expands to include everything that turned out to be reachable.
What Counts as a Significant Change
Testing is required after significant changes, and the standard leaves the definition to you — documented and justified. Commonly qualifying:
- New or modified payment channels or checkout flows
- Infrastructure migrations, including moves to or between cloud providers
- Network architecture or segmentation changes
- Major application releases affecting CDE systems
- Acquisitions bringing new systems into scope
Define this in your methodology before you need it. Deciding retroactively whether last quarter's migration was significant is a conversation you do not want to have with a QSA.
Scoping the Test
Scope covers the CDE and its boundaries: internet-facing systems in or adjacent to the CDE, internal CDE segments, applications that process cardholder data, and the segmentation controls themselves.
Scoping too narrowly leaves gaps a QSA will find. Scoping to your entire estate wastes budget on systems the requirement does not reach. The correct boundary is your documented CDE plus everything connected to it.
What Your QSA Wants to See
A documented methodology. A report identifying scope, date, tester, and findings with severity. Evidence of exploitation attempts, not just identification. Remediation records for exploitable findings, and retest evidence confirming closure. Segmentation testing as a separate documented result. Dates that align with your annual cycle and any significant changes.
A report that lists findings and stops — no remediation tracking, no retest — leaves 11.4 half-satisfied.
Choosing a Provider
The standard requires organisational independence and appropriate qualification, not a specific credential. That leaves room for judgment, so ask directly:
- What methodology do you follow, and can you provide it in writing?
- What certifications do the testers actually working on this hold?
- Does the scope include segmentation testing, or is that separate?
- Is retesting after remediation included?
- Have your reports been accepted by QSAs before?
- What is the lead time from contract to kickoff?
That last question is practical rather than technical. A provider with a six-week queue is a scheduling risk when 11.4 evidence is due.
Preparing for the Test
Preparation materially affects what you get for the money.
Have your network diagram and cardholder data flow diagram current before scoping. Testers scope from these, and a stale diagram produces a stale scope.
Decide on credentialed versus uncredentialed testing for internal work. Credentialed testing simulates a compromised user and typically surfaces more, which is usually what you want for evidence.
Agree rules of engagement in writing: testing windows, out-of-scope systems, escalation contacts, and what happens if the tester finds something critical mid-engagement. Also brief your monitoring team — or deliberately do not, if you want to test detection, but decide rather than default.
After the Report
The report is the start of the evidence chain, not the end of it.
Triage findings by exploitability and CDE proximity, not CVSS alone. A medium-severity issue providing a path into the CDE matters more than a high-severity finding on an isolated system.
Track remediation with dates and owners. Assessors look at how quickly you closed things, because it evidences a functioning vulnerability management process under Requirement 6 as well as 11.4.
Then retest and keep the retest report. Findings closed without documented verification are findings your assessor will treat as open.
Get 11.4 Evidence That Holds Up
Our PCI DSS v4.0 validation assessment includes a Requirement 11.4 evidence review, so you find out where you stand before your QSA asks. Free retest is included on originally scoped assets, which closes the remediation-evidence loop.
See also the PCI DSS checklist and compliance timeline.