PCI DSS v4.0 Evidence and documentation requirements checklist

TL;DR

• PCI DSS is complex and challenging
• Review the 12 top level controls
• Arm yourself with this checklist to help you navigate it

Introduction

PCI DSS v4.0 is challenging for a number of reasons: increased complexity, future-dated requirements, high costs and resource demands, vendor management issues, and the need for continuous adaptation to evolving security threats and technologies.

The PCI DSS requirements are large. With 12 top level controls ranging from securing the CDE, to keeping eyes on your third parties, there’s a lot to think about. When it comes to compliance, the list of documentation and evidence pieces is broad.

To help we’ve created a checklist of the key documents broken down per control to help you navigate PCI and ensure you’ve covered all bases.

This checklist is a great place to start thinking about your organisation’s stance in not only protecting card data, but protecting the organisation, your staff and most importantly, your customers.

How to use this checklist

• Maintain organisation: Categorise documents by control group for easy access during assessments.
• Update regularly: Review and update documents periodically to align with changing compliance requirements.
• Conduct reviews: Perform internal reviews to ensure all required documentation is accurate and complete.
• Prepare for audits: Ensure documents are accessible and organised for QSAs.

1. Install and maintain network security controls

☐ Network configuration standards: Documentation for secure configurations of firewalls, routers, and other network devices.
☐ Network diagrams: Detailed and up-to-date diagrams showing all connections to the cardholder data environment (CDE).
☐ Firewall Rule Sets: Approved and reviewed firewall configurations and rules.
☐ Segmentation testing results: Proof of effective segmentation to isolate the CDE from non-CDE systems.
☐ Data flow diagrams: Maps of cardholder data flows across systems and networks.
☐ Change management logs: Records of network and system configuration changes, including approvals and testing results.

2. Apply secure configurations to all system components

☐ Patch management records: Logs showing the timely application of security patches and updates.
☐ Risk assessments: Evaluations of risks related to unpatched systems or vulnerabilities.
☐ Vulnerability management policies: Documentation for managing and addressing vulnerabilities.
☐ Anti-malware policy: Rules for deploying and managing anti-malware solutions.
☐ Anti-malware logs: Reports from anti-malware solutions showing detection and resolution activities.
☐ Vulnerability scan reports: Results from internal and external vulnerability scans.

3. Protect stored account data

☐ Encryption policy: Documentation of encryption methods, key management processes, and algorithms used (e.g., AES-256).
☐ Key management policy: Policies and procedures for key generation, rotation, distribution, storage, and destruction.
☐ Cryptographic architecture documentation: Details of encryption mechanisms, key storage, and cryptographic architecture.
☐ Encryption logs: Records verifying the use of strong encryption for stored and transmitted cardholder data.
☐ Data retention policy: Rules for retaining cardholder data, including timelines and secure deletion processes.
☐ Data masking guidelines: Documents detailing how PAN (Primary Account Number) is masked for non-authorised users.

4. Protect cardholder data with strong cryptography during transmission over open, public networks

☐ Encryption policy: Evidence of strong encryption methods used to secure transmission.
☐ TLS configuration guidelines: Proof of secure TLS configurations and deprecation of weak ciphers and protocols.
☐ Testing results: Reports demonstrating secure transmission of cardholder data.

5. Protect all systems and networks from malicious software

☐ Anti-malware policy: Rules for deploying and managing anti-malware solutions.
☐ Anti-malware logs: Reports from anti-malware solutions showing detection and resolution activities.
☐ Risk assessments: Evaluations of risks posed by malware threats.
☐ User awareness training records: Proof of employee training to recognise and avoid malware risks.

6. Develop and maintain secure systems and software

☐ Software Development Lifecycle (SDLC) documentation: Policies and procedures governing secure development practices.
☐ Code review records: Evidence of peer reviews or automated scans of application code.
☐ Vulnerability scanning reports: Results from scanning applications for security weaknesses.
☐ Change control logs: Documentation of changes made to software and associated risk analysis.

7. Restrict access to system components and cardholder data by business need to know

☐ Access control policy: Rules governing access to systems and cardholder data based on the principle of least privilege.
☐ Role-Based Access Control (RBAC): Documentation of roles and responsibilities tied to system access.
☐ User access review records: Periodic reviews of user access rights and changes.
☐ MFA implementation evidence: Proof of multi-factor authentication (MFA) for administrative and remote access.
☐ Access logs: Records of user access to systems and cardholder data, including successful and failed attempts.

8. Identify users and authenticate access to system components

☐ Password policy: Guidelines for password complexity, expiration, and reuse prevention.
☐ Authentication logs: Records of authentication attempts, including failures.
☐ Authentication architecture documentation: Details of authentication mechanisms used across systems.
☐ MFA implementation records: Evidence supporting the deployment of MFA where applicable.

9. Restrict physical access to cardholder data

☐ Physical security policy: Guidelines for securing access to physical locations storing cardholder data.
☐ Access control logs: Records of who accessed secure areas and when.
☐ CCTV footage: Video recordings of sensitive physical locations.
☐ Visitor logs: Records of visitors entering restricted zones.
☐ Physical security testing reports: Evidence of tests conducted to verify physical security measures.

10. Log and monitor all access to system components and cardholder data

☐ Audit Llgs: Records of events, access attempts, and changes in the CDE.
☐ Log retention policy: Rules for retaining audit logs for at least 12 months.
☐ Monitoring reports: Documentation of ongoing monitoring activities, including anomaly detection.
☐ Threat detection logs: Records of potential threats detected by monitoring systems.
☐ Incident investigation records: Evidence of how security events were investigated and resolved.

11. Test the security of systems and networks regularly

☐ Penetration testing reports: Results of internal and external penetration tests.
☐ Segmentation testing results: Validation of network segmentation controls to isolate the CDE.
☐ Vulnerability scan reports: Proof of compliance with scanning requirements.
☐ Risk assessment reports: Documentation evaluating security risks and controls.

12. Support information security with organisational policies and programs

☐ Information security policy: Comprehensive security policy covering all aspects of PCI DSS compliance.
☐ Risk management framework: Procedures for identifying, evaluating, and mitigating risks.
☐ Training records: Proof of security awareness training for all employees.
☐ Incident response plan: Detailed plan for responding to security incidents, including predefined playbooks.
☐ Incident response evidence: Incident reports, playbooks, and post-incident analysis records.
☐ Policy review logs: Records of annual reviews and updates to security policies.
☐ Third-party contracts: Agreements detailing the service provider’s PCI DSS responsibilities.
☐ Service provider AOCs: Attestation of Compliance (AOC) documents from service providers.
☐ Vendor risk assessments: Evaluations of third-party security measures.
☐ Incident notification guidelines: Procedures for service providers to report incidents affecting cardholder data.
☐ Incident notification logs: Evidence of incidents reported by third-party service providers.

Conclusion

PCI DSS compliance isn’t easy, and nor should it be. Using this checklist will make your life easier though. This checklist highlights documentation requirements across all 12 requirements of PCI DSS, not all entities are subject to every requirement though. Entities will need to understand their requirements and alignment to SAQ’s depending on their payment channels and implementation.