The PCI DSS evidence checklist: what twelve months of evidence actually looks like

Counting the testing procedures in PCI DSS v4.0.1 that open with a verb, 358 begin with Examine, 68 with Interview and 35 with Observe. That ratio is the whole answer to what an evidence pack is. For most of the standard the question is not whether a control exists — it is whether you can produce a dated document showing it operated, and, where the requirement carries a frequency, that it did so on schedule for the whole of the preceding twelve months.

So the useful checklist is not the twelve requirement families. It is a list of artefacts, each with a cadence and a thing it has to show. The standard names the outputs of a completed assessment plainly — "a compliance validation document (for example, an AOC, SAQ, or ROC)" — and who signs each of those is a different question from who assembles the evidence underneath them.

Evidence comes in three shapes, and mixing them up is what costs you

State evidence is true on a date — the inventory of in-scope system components at 12.5.1, data-flow diagrams, configuration standards, the cryptographic inventory at 12.3.3, the payment-page script inventory at 6.4.3. It can be assembled shortly before an assessment without anything being wrong.

Cadence evidence is a series, and it cannot be assembled late. The standard is unusually explicit about the arithmetic: after your first assessment against a timed requirement, "an activity required at least every three months must have been performed at least four times during the previous year at an interval that does not exceed 90-92 days." Scan reports dated March, April, May and November are four reports and one failed requirement.

Event evidence is a pair — a change record, and the scan or test that followed it. Testing procedure 11.3.1.3.a performs exactly that reconciliation: "Examine change control documentation and internal scan reports to verify that system components were scanned after any significant changes." Your change register and your testing register have to agree. The standard names six triggers to be evaluated as significant, among them two that sit outside a typical release calendar: any change to the infrastructure supporting the CDE — directory services, time servers, logging, monitoring — and any change of third-party provider supporting it.

The twelve-month calendar

Which of these apply depends on the SAQ or assessment type you are validating against. Rows marked service providers do not apply to merchants.

Seven requirements set their own clock, and the analysis is the artefact

PCI DSS v4.x moved a set of frequencies from the standard to the entity. In each case the evidence is not only the activity record but the targeted risk analysis that justified the interval, documented to all elements of Requirement 12.3.1 — the asset, the threat, the factors bearing on likelihood and impact, and the reasoning connecting the chosen frequency to them. The seven: 5.3.2.1 malware scan frequency, 7.2.5.1 application and system account review, 8.6.3 application and system account password change interval, 9.5.1.2.1 POI device inspections, 10.4.2.1 log reviews outside the daily 10.4.1 set, 11.6.1 payment-page tamper detection if run less often than weekly, and 12.10.4.1 incident response training.

All seven were best practice until 31 March 2025 and are now in force, as are 12.3.1 itself, 12.5.2.1, 6.4.3 and 7.2.4. A frequency chosen without a documented analysis is an unsupported frequency — and 12.3.1 also requires each analysis to be reviewed at least once every twelve months to confirm the result still holds.

Five artefacts that get argued about

• Your scope confirmation is not your assessor's scoping. The applicability note on 12.5.2 is unambiguous: it is "an activity expected to be performed by the entity under assessment, and is not the same, nor is it intended to be replaced by, the scoping confirmation performed by the entity's assessor during the annual assessment." Two documents, two authors. Entities routinely hold only the second.
• The penetration testing methodology is a standing document, not a section of the report. Requirement 11.4.1 lists nine things it must contain, including application-layer testing covering at minimum the vulnerabilities at 6.2.4, and the clause most often missed — "retention of penetration testing results and remediation activities results for at least 12 months." The standard tells you how long to keep the evidence.
• Segmentation evidence has to name the controls. 11.4.5 asks for coverage of every segmentation method in use and confirmation that they isolate the CDE from all out-of-scope systems. A report covering three VLANs where the scope document lists five has not evidenced it, whatever it found.
• Scan evidence is scans plus rescans. Testing procedure 11.3.1.b examines "internal scan report results from each scan and rescan run in the last 12 months". Reports may be combined to cover a quarter, but the guidance adds that "additional documentation may be required to verify non-remediated vulnerabilities are in the process of being resolved."
• The TPSP responsibility matrix is yours to hold. 12.8.5 requires you to maintain which requirements each provider manages, which you manage and which are shared; 12.9.2 obliges providers to furnish that split, and their compliance status, on customer request. It runs the other way if you are the provider — see what Requirement 11.4.7 asks of a multi-tenant service provider.

What the standard says when you miss one

This is the difference between a late scan and a failed requirement. PCI DSS expects a documented process that notices a missed activity: prompt notification, a determination of what led to the miss, performance as soon as possible with a return to schedule or a new one set, and documentation that all of this happened. Where that process exists and was followed, an entity "is not automatically noncompliant if the activity is performed late." Where it does not — where the miss came of "oversight, mismanagement, or lack of monitoring" — the requirement is unmet until the process is documented, the schedule re-established and the activity performed against it.

The guidance on 12.4.2 puts it positively: the quarterly review "can also be used to verify that appropriate evidence is being maintained… to assist in the entity's preparation for its next PCI DSS assessment." A pack checked as it accumulates, not reconstructed at the end.

Assembling it

Most of the calendar above falls out of running the environment properly. The parts needing an independent party are narrow: the ASV scans at 11.3.2, and the testing at 11.4.2, 11.4.3, 11.4.5 and 11.4.6, where the standard requires that "organizational independence of the tester exists (not required to be a QSA or ASV)."

Those testing artefacts are also the ones most able to be technically complete and evidentially useless, so the failure modes are worth knowing before you commission the work. Where the requirement is 11.4, penetration testing scoped to the requirement and documented for the evidence pack is the deliverable to ask for.