PCI DSS documentation: policies, procedures and the records a QSA asks for, from small merchants to service providers

What PCI DSS expects you to write down

The short answer: for each of the twelve requirements you need written policies and operational procedures, a written allocation of who does what, and a trail of records showing the activities actually happened. PCI DSS v4.0.1 makes the first two explicit. The opening sub-requirements of Requirements 1 to 11 (1.1.1 and 1.1.2 in the first, with the same pattern in each of the others) state that the policies and procedures for that requirement are documented, kept up to date, in use and known to all affected parties, and that roles and responsibilities for its activities are documented, assigned and understood. Requirement 12 then carries the organisation-wide material: the overall information security policy, its periodic review, the risk analyses, awareness, third-party management, the annual scope confirmation and incident response.

Read those four words carefully, because a QSA does. "Documented" is the easy part. "Kept up to date" means the document reflects the current environment and has a review history. "In use" means practice matches the text, which the assessor tests by observation and by sampling records. "Known to all affected parties" means the people who perform the activity can explain it; the assessor will ask them. A policy that satisfies only the first word earns nothing.

For roles, naming a head of security is not enough: each recurring activity, from rule reviews to daily log checks, needs an owner who knows it. A one-row-per-activity matrix usually does the job. What each requirement requires technically is covered in PCI DSS requirements explained, requirement by requirement.

Documents and records: two different things

A binder of policies is half the job at best, because the assessor treats the two differently.

• Documents state intent and method: the information security policy, configuration standards for each platform, the access control procedure, the key management procedure, the incident response plan. They are approved, versioned and reviewed.
• Records are the output of doing it: a completed access review with its decisions, a daily log review entry, a passing ASV scan report, a penetration test with its retest, a signed scope confirmation, attendance at awareness training. They cannot be written in advance, and the assessor samples them to check you did what the documents say, as often as the standard sets.

Because many activities are daily, quarterly, six-monthly or annual, records drive the timeline: a control switched on the month before fieldwork has no history to sample.

The core records a QSA asks for

The same evidence appears on almost every assessment request list. The table shows what the assessor looks for, not merely whether it exists.

Add the change, hardening, key management and media destruction records your environment produces. How the assessor tests them is covered in PCI DSS assessor questions: what QSAs ask, and the evidence that answers them.

A right-sized set: small merchant versus service provider

Volume follows the validation route. A merchant that outsources card handling and validates on a short SAQ answers a fraction of the requirements; a service provider assessed by a QSA answers the full standard plus service-provider obligations. Which questionnaire applies is explained in Which SAQ applies to you: eligibility explained.

Treat the left column as a floor: every SAQ answer needs evidence behind it. See PCI DSS for small merchants and start-ups: the SAQ route done properly.

What to avoid

• Downloaded policy packs adopted unread. They describe controls you do not run, and each mismatch with practice becomes a finding.
• Diagrams drawn once. A diagram that misses the new cloud connection undermines scope, and with it everything else.
• Procedures nobody has read. "Known to all affected parties" is tested by asking. Brief the people who perform each activity and record that you did.
• One author, one owner. When one person writes every document and holds every role, the programme stops when that person is away.
• Records created in a rush before fieldwork. Twelve access reviews dated the same week tell the assessor exactly what happened.

How Effivity holds the documentation

Effivity, used in 50+ countries, holds a Sterling PCI DSS programme in one controlled place: the policy set with its approval history, the responsibility matrix, the diagrams and inventory, and a calendar of periodic tasks that prompts each owner and files the evidence against its requirement. When the assessor asks for four quarters of scans, the answer is a filtered view, not a search through e-mail. Effivity is included with the engagement, at no additional cost. See Effivity for PCI DSS: the guide and The PCI DSS annual cycle: quarterly scans, annual validation and business as usual.

PCI DSS documentation: questions buyers ask