PCI DSS Compliance Documents: What to Keep and Why

Ask a team that has been through a PCI DSS assessment what slowed them down and the answer is often paperwork, not technology. The controls existed, but nobody could show evidence. This post lists the documents that assessments under v4.0.1 commonly rely on and what each one shows. Your acquirer and assessor decide exactly what you need to provide, so treat this as a starting inventory.

Scope and data flow

Cardholder data flow diagram: shows how card data enters, moves through and leaves your environment.
Network diagram: shows connections, segmentation and boundaries.
System and software inventory: shows what is in scope, who owns it and why it exists.

If these are wrong, what is built on them is wrong too. Review them whenever a system, vendor or payment channel changes.

Policies and procedures

Information security policy: states management intent and is reviewed on a schedule.
Operational procedures: the how-to behind each requirement area, such as account management, patching, logging and change control.
Roles and responsibilities: who is accountable for each requirement area.

A policy with no procedure behind it tends to struggle in an interview, because staff describe something different from what is written.

Risk and decisions

Risk assessment: version 4 asks for documented risk analysis in several places, for example where you choose how often to perform a periodic activity.
Exception records: if a control is not applied as written, record why, who approved it and what compensates for it.

Third parties

Service provider list: providers that can touch card data or affect its security.
Responsibility matrix: which requirements you own and which the provider owns.
Provider evidence: their own attestation or report, and how you check it on a schedule.

Technical evidence

Vulnerability scan reports: internal scans and external scans from an Approved Scanning Vendor, with proof that findings were fixed and rescanned.
Penetration test reports: where applicable, with remediation notes.
Configuration standards and baselines: how systems are hardened.
Access review records: who has access to the cardholder data environment and who approved it.
Log review evidence: that someone reads the logs or that alerts exist and are acted on.

People and response

Security awareness training records: who was trained and when.
Incident response plan: roles, contacts, steps and escalation.
Test records: notes from tabletop exercises or other tests of the plan.

Validation paperwork

Depending on your situation you will complete a self-assessment questionnaire or have an assessor produce a report, and sign an Attestation of Compliance. Those documents summarize your position at a point in time. They are only as good as the evidence behind them.

Gaps that commonly slow an assessment

Diagrams that no longer match the network after a change.
Policies written once and never reviewed, or reviewed with no record.
A provider list that misses a vendor with remote access.
Scan reports showing findings with no proof they were fixed.
Training records that cover staff in general but not the people who handle card data.
Evidence scattered across personal drives, so nobody can find it when an assessor asks.

Keep them alive

Give each document an owner, a last-reviewed date and a next-review date.
Store evidence in one controlled place, not in individual inboxes.
Calendar the recurring items: scans, reviews, training and plan tests.
Update diagrams as part of change control, not at audit time.

The goal is simple: for a given requirement, you can point to the document, the owner and the proof it ran. Version 4.0.1 is the active version now that v4.0 was retired on 31 December 2024, so build your set against it.

Message us to talk through your PCI documentation plan.