Requirement 11.4
Evidence Checklist
A QSA does not read your penetration test report the way you do. They run a testing procedure against it, and that procedure verifies the testing was performed “according to all elements specified in this requirement”. Reports come back for leaving an element unevidenced, not for being badly written.
PCI DSS Requirement 11.4 Evidence Checklist
Enter your work email for the printable worksheet — the renumbering map, the nine methodology elements, the coverage and segmentation gates, the report contents table, and a finding-to-requirement mapping sheet.
Check your inbox
We've emailed you a link to download PCI DSS Requirement 11.4 Evidence Checklist.
The link expires in 48 hours. If it hasn't arrived in a few minutes, check your spam folder.
We couldn't send the download link. Please try again, or contact us and we'll email you PCI DSS Requirement 11.4 Evidence Checklist.
What it gates
Six sub-requirements, and the element inside each that goes missing
“All elements” is a list, and your report is the only evidence each one happened. The worksheet is ordered the way the testing procedures run.
11.4.1
The methodology, and it is yours
Nine elements, and the standard puts the methodology on the entity — “defined, documented, and implemented by the entity”. A tester’s proposal is not your methodology, and 11.4.2 and 11.4.3 both open with “Per the entity’s defined methodology”.
11.4.2 / 11.4.3
Internal and external, and they swapped places
Under v3.2.1, 11.3.1 was the external test. Under v4.0.1 the order is reversed: 11.4.2 is internal, 11.4.3 is external. A report labelling its external section 11.4.2 out of habit has mis-mapped every finding in it.
11.4.4
The retest is part of the requirement
Corrections are made per your own risk assessment at 6.3.1, and “Penetration testing is repeated to verify the corrections.” A change ticket, a patch note and a fresh scan are none of them penetration testing results.
11.4.5 / 11.4.6
Segmentation, and the clause inside it that goes missing
Seven elements, and the fifth cross-references Requirement 2.2.3 — isolation separating systems with differing security levels. Where scope reduction rests on a hypervisor or container boundary, that boundary is inside 11.4.5’s coverage. Service providers carry 11.4.6 instead: the same list, every six months.
11.4.7
Multi-tenant providers
Best practice until 31 March 2025 and mandatory since. Either evidence of testing on the customer’s subscribed infrastructure, or prompt access for them to test it. The guidance leaves no room: “Multi-tenant service providers cannot forbid penetration testing.”
Contents
Twelve sections you write in
It is a worksheet, not a guide. Every section leaves somewhere to record an answer, and it publishes a state for the awkward one — “held, not written” is a different problem from “not evidenced”, and PCI DSS treats them differently.
Cover sheet
Scope as recorded in your 12.5.2 confirmation, and your own definition of a significant change — the two lines that decide four of the gates.
The renumbering map
Every v3.2.1 number against its v4.0.1 replacement, with the two transpositions marked.
The nine methodology elements
One line each, with a write-in for where it is documented. Three arrived as clarifications in v4.0 and are the three most often absent.
Coverage and cadence grid
Seven elements against the internal and the external test, side by side.
Segmentation worksheet
The seven elements, then a table with a row per segmentation method in use — reconciled against your scope confirmation.
Report contents gate
Seven report sections, what each evidences, and the requirement it answers.
Finding-to-requirement mapping
A worksheet with worked examples. 11.4 does not oblige you to write it; leave it implicit and your QSA writes it months later without the tester in the room.
A dated plan
Working back from the validation date, with the three gaps that cannot be closed retrospectively marked.
Where we sit
Your QSA validates. The testing is a separate engagement.
Security Brigade is not a Qualified Security Assessor and does not assess, validate or sign a compliance document. What we do is the work the assessment examines: internal and external penetration testing under 11.4.2 and 11.4.3, segmentation testing under 11.4.5 and 11.4.6, and the retest under 11.4.4 — reported against these sub-requirement numbers with the finding-to-requirement mapping written in.
The standard is explicit that this does not need to be your assessor, and says so in the requirement text rather than the guidance: a qualified internal resource or qualified external third party, with organisational independence, and “not required to be a QSA or ASV”.
Working towards a validation date?
Tell us your CDE boundary and when you validate. Three of the gaps in this worksheet cannot be closed retrospectively, and which of them apply to you is decided by two lines on the cover sheet.
Describe your CDE