Knowledge base

PCI DSS Documentation: What You Actually Need

A simple guide to the key documents and evidence required during a PCI DSS assessment.

Neha Dvivedi · August 16, 2026

A reference on the documentation a PCI DSS assessment expects.

Scope documentation

You should maintain:

• Cardholder data flow diagrams showing where card data is stored, processed, and transmitted.

• Network diagrams showing the Cardholder Data Environment (CDE) and its connections.

• An inventory of all systems and components included in the PCI DSS scope.

• Segmentation details and testing evidence, if network segmentation is being used to reduce the scope.

• Card data discovery scan results showing where cardholder data has been found.

• A list of third-party service providers and details of the services they provide.

The cardholder data flow diagram is one of the most important documents for an assessor. It must be up to date and accurately reflect the actual environment.

Policies and procedures

Your organisation should have documented:

• Information security policy, reviewed at the required frequency.

• Acceptable use policy for systems and technology.

• Configuration standards for different types of systems.

• Data retention and disposal policy, including retention periods and reasons for them.

• Key management procedures.

• Access control policy covering access approval, review, and removal.

• Password and authentication policy.

• Patch management procedure with risk-based deadlines.

• Secure development procedures, where applicable.

• Change management procedure.

• Incident response plan.

• Third-party management procedure, including clear responsibilities.

• Security awareness and training programme.

Records and evidence

During an assessment, you may need to provide evidence such as:

• Firewall and router rule reviews.

• System configuration and build records.

• Records showing that data was reviewed and securely deleted.

• Access review records showing what was checked and what changes were made.

• Authentication configuration records.

• Patch management records showing that patches were applied within the required timeframe.

• Change records showing testing and approval.

• Log review records.

• Internal and external vulnerability scan reports with passing results.

• Penetration testing reports and evidence that identified issues were resolved.

• Segmentation testing results.

• Incident response testing records.

• Security awareness training records.

• Physical access records and device inspection records, where applicable.

• Third-party service provider attestations and responsibility matrices.

The responsibility matrix

Keep your evidence throughout the year, not just before the assessment.

Assessors usually review samples from a period of time. For example, completing an access review just one week before an assessment does not prove that a quarterly access review was performed throughout the year.

Other good practices include:

• Date all records so it is clear when an activity was performed.

• Keep records even when there are no issues. A log review showing no problems is still evidence that the review was completed.

• Make sure vulnerability scan reports show passing results. Unresolved high-severity findings can prevent a scan from being considered successful.

• Document the business reason for firewall rules at the individual rule level.

• Document why data retention periods have been selected instead of simply following past practices.

Common PCI DSS Findings

Some common issues identified during assessments include:

1. Outdated data flow diagrams that do not match where cardholder data is actually stored or processed.

2. Sensitive authentication data being stored after authorisation when it should not be retained.

3. Logs being collected but not reviewed, with no evidence that reviews were performed.

4. Access reviews not being completed at the required frequency.

5. Patch deadlines being defined but not met, as shown by the organisation's own records.

6. Network segmentation being relied upon without performing the required testing.

7. Missing or inaccurate third-party responsibility matrices that do not match the service provider's attestation.

8. Shared administrator accounts instead of individual accounts with appropriate accountability.

Key Takeaway

PCI DSS compliance is not only about having policies in place. You need accurate documentation, regular reviews, and clear evidence that the required activities are actually being performed.

The best approach is to maintain your documentation and evidence continuously throughout the year rather than preparing everything just before the assessment.

What this covers

PCI DSS

See how this looks as a working system

Reading about a requirement and seeing the documentation that satisfies it are different things. In a short demo we open the actual manual, procedures and records set for PCI DSS, show you how each clause is answered and where your existing way of working already fits. You will know what implementation involves before you commit to it.