PCI DSS Documentation: The Complete 2026 Evidence Checklist

PCI DSS documentation is the part of a payment security programme that fails assessments most often, and it fails for a boring reason: the controls were working, but nobody could prove it. A Qualified Security Assessor does not grade your intentions. They sample evidence, they read policies, and they ask who approved what and when. If the paper trail is thin, the control is treated as absent.

This guide sets out what PCI DSS documentation a QSA actually asks for, which documents are mandatory rather than merely useful, and how the 51 future-dated requirements that became effective on 31 March 2025 changed the evidence burden.

What counts as PCI DSS documentation

PCI DSS v4.0.1 is the current version of the standard, published by the PCI Security Standards Council. It is organised into 12 requirements grouped under six control objectives, and almost every one of those 12 has a documentation component sitting underneath the technical control.

It helps to separate three things that get lumped together:

• Governing documents — the policies and procedures that say what your organisation does. These are written once, approved, and reviewed at least annually.
• Operational records — the artefacts your controls throw off as they run. Change tickets, access reviews, scan reports, training registers, log review notes.
• Validation documents — the official PCI SSC forms that record the outcome of an assessment. The Report on Compliance, the Attestation of Compliance and the Self-Assessment Questionnaire.

Only the third category is standardised. The Council publishes those templates and nothing else is recognised for validation — there is no such thing as a PCI DSS certificate, whatever a vendor may have sold you. The first two categories are yours to design, which is precisely why they are where most of the effort goes.

The core PCI DSS documentation set

Requirement 12 is where the standard is most explicit about paperwork, but documents are demanded throughout. The table below maps the documents a QSA will expect to the requirement that drives them.

Two of these deserve singling out because they are new sources of failure rather than old ones.

Targeted risk analyses: the biggest change to PCI DSS documentation

PCI DSS v4.0 introduced 64 new requirements. Of those, 51 were future-dated and became effective on 31 March 2025, which means an assessment in 2026 tests all of them with no transition relief. The single most consequential one for your document set is Requirement 12.3.1.

Where the standard lets you choose a frequency or a method — how often you review a control, how often you scan, how you define “periodically” — you now have to produce a documented targeted risk analysis justifying the choice. It has to identify the asset being protected, the threat, the factors contributing to likelihood and impact, and a review of the analysis itself at least every 12 months.

Assessors read these. A one-line statement that a risk analysis was performed is not a targeted risk analysis, and a template filled in with generic text for every control tends to get challenged as a single analysis wearing twelve hats. Write one per flexible requirement, and make the reasoning specific to your environment.

Evidence, not screenshots

The second shift is subtler. Because the future-dated requirements are now business as usual, a QSA is looking for evidence that the control operated across the assessment period, not that it operated on the Tuesday before fieldwork.

That changes what you retain. A quarterly access review needs four sets of records, each with a date, a reviewer and an outcome — including the reviews where nothing was revoked, because a review with no findings is still a review. Log review, vulnerability scanning, penetration testing, firewall rule reviews and awareness training all work the same way. Treat PCI DSS documentation as something you capture, not something you assemble: retain the artefact at the time it is produced; reconstructing a year of evidence in the fortnight before an assessment is visible, and assessors say so in the report.

If you already run an ISO 27001 management system, this discipline will feel familiar — the logic is the same one behind the mandatory documents ISO 27001 requires, and a good deal of the evidence is reusable across both.

The customised approach adds a document set of its own

Version 4 introduced a second way to meet a requirement. Alongside the defined approach — do what the standard says — you can use the customised approach, meeting the stated objective by a control of your own design. It is genuinely useful for mature environments running controls the standard did not anticipate.

It is also the heaviest documentation obligation in the standard. Each customised control needs a completed Controls Matrix describing the objective, the control, how it achieves the objective and how its effectiveness is tested, plus a targeted risk analysis for that control. The assessor then has to derive and document testing procedures specifically for it, because none exist in the standard.

Choose it deliberately. Organisations sometimes reach for the customised approach to avoid a control they find inconvenient, and end up producing more PCI DSS documentation than compliance with the defined approach would have required in the first place.

How much PCI DSS documentation you actually need

The honest answer depends on which validation route applies to you, and that is determined by your merchant or service provider level rather than by your own preference. A Level 4 merchant completing SAQ A has a genuinely small document set. A Level 1 service provider undergoing a full Report on Compliance is looking at a policy suite, dozens of procedures and a year of operational records.

Before you build anything, settle the question of who assesses you and against which form — our guide to PCI DSS validation roles walks through the four parties involved and the mistake that costs organisations the most time. Getting the validation route wrong means writing documents you never needed, or discovering three weeks out that you needed forty more.

It is also worth reading this alongside the wider PCI DSS v4.0 compliance guide, which covers the technical control changes that sit behind the paperwork described here.

A sensible build order

Organisations that get through their first assessment cleanly tend to build in roughly this sequence:

1. Scope first. Document where cardholder data is stored, processed and transmitted, and draw the flows. Everything else inherits from this, and a scope error invalidates the document set built on top of it.
2. Inventory and diagrams. System components, network topology, dataflows. These are the documents assessors open first.
3. The policy layer. Information security policy, then the subordinate policies each requirement calls for.
4. Procedures and roles. Who does the thing, how often, and what they produce when they do it.
5. Targeted risk analyses. One per flexible requirement, written after the procedures so the frequency you justify matches the frequency you actually operate.
6. Evidence capture. Decide where each operational record lands and who is responsible for filing it, before the clock starts on your evidence period.

The sequence matters more than the speed. Writing policies before scope is settled produces documents that describe an environment you do not have.

Frequently asked questions

Is there an official list of required PCI DSS documents?

No. There is no published master list of PCI DSS documentation. The Council publishes the standard and the validation forms, but there is no master checklist of policy documents. The required set is derived by reading the 12 requirements and extracting every instance where the standard says something must be documented, defined, assigned or retained.

Does PCI DSS require a separate policy for every requirement?

It does not. What it requires is that the topic is addressed, owned and kept current. A single well-structured information security policy with subordinate procedures satisfies the standard as readily as twelve separate policies, and is considerably easier to keep reviewed.

How long do we have to retain PCI DSS documentation?

The standard sets specific retention for audit logs — twelve months, with at least three months immediately available. For other records, retain enough to cover the full assessment period your QSA will sample, which in practice means a rolling twelve months at minimum.

Can PCI DSS documentation be reused for ISO 27001 or SOC 2?

Much of it can. Access control, change management, incident response and awareness training overlap heavily. The framing differs — PCI DSS is prescriptive about cardholder data where ISO 27001 is risk-driven across all information — so expect to map rather than copy.

Who has to approve the information security policy?

Executive management. Requirement 12.1 expects the policy to be established, published, maintained and disseminated, with evidence of formal approval and annual review. An unsigned, undated policy is one of the most common findings in a first assessment.

Where to start

If you are assembling a PCI DSS documentation set from nothing, the drafting is the slow part, not the deciding. The structure of a PCI DSS documentation set is largely determined by the standard, which means it can be templated — and starting from an auditor-written baseline removes the risk of discovering a missing document during fieldwork.

Our PCI DSS Toolkit provides the policy suite, procedures, registers and targeted risk analysis templates aligned to v4.0.1, editable and ready to adapt to your environment.

Primary source for this article: the PCI SSC Document Library, which hosts PCI DSS v4.0.1 and the official validation forms. Requirement numbering and effective dates verified against PCI SSC publications, August 2026.