PCI DSS 4.0 expects documented policies and procedures for each of its twelve requirements, plus supporting records: a scope document, data flow diagrams, inventories, targeted risk analyses, a security awareness program and an incident response plan. Write what you actually do, assign an owner to each document, and date every review.
Why the paperwork is spread across the standard
In version 4.0 the Council moved the policies and procedures requirements from the end of each principal requirement to the beginning. That is why you will find a "documented, kept up to date, in use and known to affected parties" style item at the top of each section. Practically, it means the document set is organised by requirement, and an assessor can ask for one per area.
The twelve requirement titles, as printed in the PCI SSC questionnaires, are: network security controls, secure configurations, protecting stored account data, strong cryptography in transmission, protection from malicious software, secure systems and software, restricting access by business need, identifying users and authenticating access, restricting physical access, logging and monitoring, regular security testing, and organizational policies and programs.
The core document set
Think in four groups.
Governing documents. An information security policy, plus topic procedures that map to the requirement areas. Version 4.0 added roles and responsibilities items to most areas (for example 8.1.2 and 10.1.2), so each procedure should name who performs the activity.
Scope and data records. A PCI DSS scope statement that you confirm at least every 12 months and after significant change (12.5.2). A data flow diagram and network diagram of the cardholder data environment. A data retention and disposal policy covering stored account data.
Inventories and reviews. The summary of changes lists several items an assessor can ask to see: an inventory of bespoke and custom software (6.3.2), an inventory of trusted keys and certificates (4.2.1.1), a documented review of cryptographic cipher suites and protocols at least every 12 months (12.3.3), and a review of hardware and software technologies in use at least every 12 months (12.3.4). Add user account and privilege reviews (7.2.4, 7.2.5.1).
Analyses and plans. Targeted risk analyses for any requirement with a flexible frequency (12.3.1). An incident response plan, including a procedure for what to do when stored PAN turns up where you do not expect it (12.10.7). An annual review of the security awareness program (12.6.2) with content on current threats and acceptable use of end-user technology (12.6.3.1 and 12.6.3.2).
Third parties get their own paper
If a processor, hosting provider or other third party touches account data or can affect its security, you need a written agreement and a list of which requirements each party covers. Version 4.0 renamed "service provider" to "third-party service provider" across Requirement 12.8, and service providers must support customer requests for that information (12.9.2). Keep a responsibility matrix: requirement by requirement, who does what.
Documents that prove operation, not intent
Policies alone fail assessments. Keep operating records beside each policy: change tickets, access review sign-offs, scan reports, log review outputs, training completion lists, incident tabletop notes. The assessor tests that what you wrote is what you do.
What to do
- Create a register with one row per requirement area: policy name, owner, last review date, next review date.
- Write procedures from real practice. If nobody reviews logs daily, do not write that they do.
- Produce the scope statement and diagrams first. Every other document refers to them.
- Build the inventories (software, certificates, technologies) and put a 12 month review on the calendar.
- Draft targeted risk analyses for each flexible frequency using the Council's sample template.
- Write the third-party responsibility matrix and file the agreements.
- Collect operating evidence monthly, not in the week before the assessment.
Quick check
Do I need twelve separate policies?
No set number is mandated in the material we reviewed. You need documented policies and procedures covering each requirement area. Many teams group them into a smaller set of documents.
How often must documents be reviewed?
Some items carry explicit intervals, such as scope confirmation and cipher suite review every 12 months. For others, use your targeted risk analysis to justify the frequency.
How Safeguard helps automate this
Document registers drift unless something checks them. Safeguard's compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires, so evidence is collected from connected systems and code instead of by screenshot, and monitoring runs between assessments. That frees your team from chasing screenshots for the inventories and scan records above. Technical evidence comes from your real code and dependencies: scans, SBOMs and reachability, which feed the software inventory directly. Autonomous remediation can open tested fix pull requests; it is off by default, every category starts on Manual, and you choose which categories run automatically and at what approval level. The assessment itself is done by an independent third party, and Safeguard helps you prepare and keep evidence ready.
Open the framework mapping demo or book a call.
Sources
- PCI SSC: Summary of Changes from PCI DSS v3.2.1 to v4.0
- PCI DSS v4.0 SAQ A-EP, for requirement titles
- PCI SSC: Targeted Risk Analysis guidance
- The full standard is behind a download gate we could not fetch. Confirm requirement numbers against v4.0.1.
Last reviewed: 18 October 2026.
