PCI DSS checklist: the 12 requirements in the order you will meet them, with the evidence each needs

Requirement 12 (first part): scope, roles and providers

Requirement 12, the one on security policies and programmes, carries the scoping duty, the ownership of the programme and the management of providers. Start here.

• Every channel where card data enters the business is listed: web, telephone, terminals, mail order, back office. Evidence: a channel inventory signed off by finance and operations.
• The scope is documented and confirmed, covering the CDE and every system connected to it or able to affect its security. Evidence: a dated scope confirmation with its approver.
• Your acquirer has confirmed the level that applies and whether a ROC or an SAQ is expected. Evidence: acquirer correspondence on file.
• An executive owns the programme and a named person coordinates it day to day. Evidence: an appointment record or role description.
• Every third-party service provider that touches card data or can affect its security is registered. Evidence: a provider register naming the service each delivers.
• Each provider's responsibilities are split from yours, requirement by requirement. Evidence: a responsibility matrix agreed with each provider.
• A current AOC is held for each provider and its compliance is checked at least yearly. Evidence: provider AOCs with review dates.

Requirement 3: Protect Stored Account Data

Know what you keep before you decide how to protect it. Deleting data is the cheapest control there is.

• A data discovery exercise has searched file shares, databases, logs and mailboxes for card numbers. Evidence: discovery results and actions taken on each find.
• No sensitive authentication data is stored after authorisation, including in logs, recordings and debug files. Evidence: discovery results and configuration of recording systems.
• A retention policy limits what account data is kept and for how long, and purges happen. Evidence: the policy and purge records.
• PAN is masked on screens and reports for anyone without a business need to see it in full. Evidence: screenshots by role.
• Stored PAN is unreadable through strong cryptography, truncation, hashing or tokenisation. Evidence: the method per data store.
• Cryptographic keys are managed through their lifecycle, with custodians who acknowledge their duties. Evidence: key management procedures and custodian acknowledgements.

Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks

• Every point where PAN crosses a public network is identified and encrypted with strong protocols. Evidence: an inventory of encryption in use.
• Certificates protecting those transmissions are trusted, valid and tracked. Evidence: a certificate register with expiry dates.
• Staff know card numbers are never sent by e-mail, chat or text, and a route exists for customers who try. Evidence: the written rule and training acknowledgement.

Requirement 1: Install and Maintain Network Security Controls

With the data located, draw the boundary and control what crosses it. Scope reduction belongs in this phase; see PCI DSS scoping and segmentation.

• Network and data-flow diagrams show every card data flow and match the live environment. Evidence: dated diagrams reconciled to the network.
• Traffic into and out of the CDE is limited to what the business needs, and all else is denied. Evidence: rulesets and the deny-all configuration.
• Each permitted rule carries a business justification and an owner. Evidence: the ruleset with justification per rule.
• Rulesets are reviewed on the defined cycle and stale rules removed. Evidence: review records with decisions.
• Devices that connect to both untrusted networks and the CDE, such as staff laptops, have security controls applied. Evidence: endpoint configuration.

Requirement 2: Apply Secure Configurations to All System Components

• An inventory lists every system component in scope. Evidence: a current asset inventory.
• A configuration standard exists for each platform, based on an accepted hardening source. Evidence: standards per platform.
• Vendor default accounts and passwords are changed or removed before systems go live. Evidence: build checklists for sampled systems.
• Unnecessary services, functions and software are disabled or removed. Evidence: configuration output compared with the standard.
• Wireless networks connected to the CDE, or transmitting card data, are inventoried and their defaults changed. Evidence: a wireless inventory.

Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know

• An access model defines what each role may reach, on least privilege. Evidence: the role matrix.
• Access is granted only on an approved request, and privileged accounts are justified. Evidence: approved requests for sampled users.
• User accounts and privileges are reviewed every six months and changes acted on. Evidence: review records with decisions and removals.

Requirement 8: Identify Users and Authenticate Access to System Components

• Every user has a unique ID; shared and generic accounts are removed or tightly controlled. Evidence: a user inventory.
• Multi-factor authentication protects all access into the CDE and all remote access. Evidence: MFA configuration and a test log-in.
• Password length, complexity and lockout settings meet the v4.0.1 minimums, including twelve characters where systems support it. Evidence: policy settings exported from each platform.
• Leavers' access is removed promptly and reconciled against HR records. Evidence: leaver records matched to account deletion dates.
• System and application accounts are managed, with no passwords hard-coded in scripts. Evidence: a service account register.

Requirement 5: Protect All Systems and Networks from Malicious Software

• Anti-malware is deployed, current and active on every system at risk, with exceptions justified. Evidence: a coverage report and exception list.
• Alerts are monitored and users cannot switch protection off. Evidence: alert logs and console settings.
• Phishing is addressed with technical and awareness measures for payment staff. Evidence: e-mail filtering settings and training records.

Requirement 6: Develop and Maintain Secure Systems and Software

• Vulnerabilities are identified from named sources and ranked by risk. Evidence: the vulnerability sources and ranking method.
• Patches are applied within the timeframes you have defined for each risk rank. Evidence: patch reports for sampled systems.
• Developers of in-scope software are trained in secure coding, and code is reviewed before release. Evidence: training records and review records.
• Changes to in-scope systems are requested, assessed, approved and tested. Evidence: change records for a sample.
• Scripts on payment pages are inventoried, authorised and checked for integrity. Evidence: a script inventory with authorisations.

Requirement 9: Restrict Physical Access to Cardholder Data

• Entry to facilities holding in-scope systems is controlled and logged, with visitors escorted. Evidence: badge and visitor logs.
• Media holding card data are inventoried, secured and destroyed when no longer needed. Evidence: a media inventory and destruction records.
• Payment terminals are listed and inspected for tampering, and front-line staff know what to look for. Evidence: the device list, inspection records and training.

Requirement 10: Log and Monitor All Access to System Components and Cardholder Data

• Logging is enabled on all in-scope systems and sent to a protected central store. Evidence: log source list and access controls on the store.
• Logs are reviewed daily with automated tools, and alerts are followed up. Evidence: daily review records and alert tickets.
• Log history is retained for a year and system clocks are synchronised. Evidence: retention settings and time source configuration.
• Failures of critical security controls are detected, reported and handled. Evidence: a record of failures and responses.

Requirement 11: Test Security of Systems and Networks Regularly

• Rogue wireless access points are detected on the defined cycle. Evidence: wireless scan results.
• External scans by an ASV pass every quarter, with rescans after fixes. Evidence: four quarters of passing ASV reports.
• Internal vulnerability scans run every quarter and findings are resolved. Evidence: scan results and rescans.
• Penetration tests are carried out and exploitable findings fixed and retested. Evidence: test reports with remediation evidence.
• Segmentation controls are tested and shown to isolate the CDE. Evidence: segmentation test reports.
• Intrusion detection and payment page tamper detection alert the right people. Evidence: detection configuration and alert records.

Requirement 12 (second part): policy, risk, people and incidents

• An information security policy set is approved, published and reviewed every year. Evidence: policies with review dates.
• Targeted risk analyses exist wherever the standard lets you set a frequency yourself. Evidence: each analysis with its conclusion.
• Security awareness training runs on joining and yearly, and staff acknowledge the policies. Evidence: training records and acknowledgements.
• People with access to card data are screened before starting, as local law permits. Evidence: screening records for sampled joiners.
• An incident response plan exists, names who does what and has been exercised. Evidence: the plan and an exercise record.
• The scope is reconfirmed each year and after significant change. Evidence: the latest scope confirmation.