PCI DSS applies to every merchant and service provider that stores, processes or transmits cardholder data, or could affect its security. This free PCI DSS compliance checklist runs the annual assessment cycle for either: scope and validation type, third-party responsibilities, targeted risk analyses, a year of scan and penetration test evidence, and the SAQ or ROC with its Attestation of Compliance. Answers on the first task switch on the service provider, segmentation and payment page tasks only where they apply. The result is one dated, signed record of the year that your acquirer and assessor can follow.
The PCI Security Standards Council writes PCI DSS, but the card brands’ compliance programmes and, for merchants, the acquiring bank decide who validates and how. Visa, for example, sets a merchant’s level from its total Visa transaction volume over 12 months, and the acquirer says which report to submit.
The current standard is v4.0.1, published in June 2024. Version 4.0 was retired on 31 December 2024, and its future-dated requirements became mandatory on 31 March 2025. The report is annual, but the controls are not: daily log reviews (10.4.1), weekly file comparisons (11.5.2), scans every three months (11.3.1, 11.3.2), and six-monthly reviews of network security controls and user access (1.2.7, 7.2.4). Section 7 of the standard defines “every three months” as at least once every 90 to 92 days, and expects you to show how any missed activity was noticed and caught up.
Who: merchants their acquirer allows to self-assess; eligible service providers use SAQ D.
Scope: only the requirements for the SAQ type, from SAQ A up to SAQ D.
Output: the SAQ and an AOC signed by an executive officer, plus ASV scan reports where required.
Approach: the customized approach is not available.
Who: typically the largest merchants and service providers, at thresholds the brands set.
Scope: every applicable requirement, tested by sampling, interviews and observation.
Output: the ROC and an AOC signed by the entity and the assessor.
Approach: defined or customized, the latter backed by a risk analysis (12.3.2).
The Council removed Requirements 6.4.3 and 11.6.1, and the related risk analysis under 12.3.1, from SAQ A. Instead, the merchant must confirm its site is not susceptible to attacks from scripts that could affect its e-commerce systems. FAQ 1588 applies this to pages that embed a provider’s payment form, such as an iframe, and accepts either the merchant’s own script controls or written confirmation from its PCI DSS compliant provider. The requirements themselves did not change.
Six phases take the cycle from scoping to a submitted AOC. A seventh appears only for service providers. Requirement numbers are from PCI DSS v4.0.1.
The answers on the first task drive the conditional tasks in Phases 2, 4 and 6, and whether Phase 7 appears.
Where PCI DSS lets you set a frequency, 12.3.1 requires a documented risk analysis: for example 5.2.3.1, 7.2.5.1, 8.6.3, 9.5.1.2.1, 10.4.2.1 and 11.3.1.1.
The segmentation task appears only when segmentation reduces scope; the payment page task only when the website hosts or embeds a payment page.
Controls an assessor samples across the year. Run each on its own recurring checklist and attach the completed runs here.
The first task appears for an SAQ, the second for a ROC, following the validation type recorded in Phase 1.
Shown only when the entity type is service provider.
The table lists recurring evidence for each of the 12 principal requirements in v4.0.1, and the phase that collects it. Your SAQ type decides which rows apply, so treat the table as a starting point, not legal advice.
| Principal requirement | Recurring evidence | Evidenced in |
|---|---|---|
| 1. Install and Maintain Network Security Controls | Six-monthly NSC reviews (1.2.7); data-flow diagrams (1.2.4) | Phases 1 and 5 |
| 2. Apply Secure Configurations to All System Components | In-scope component inventory (12.5.1) | Phase 1 |
| 3. Protect Stored Account Data | Search for PAN outside the CDE; response procedure (12.10.7) | Phases 1 and 3 |
| 4. Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks | Keys and certificates inventory (4.2.1.1); cipher suite review (12.3.3) | Phase 3 |
| 5. Protect All Systems and Networks from Malicious Software | Risk analysis for 5.2.3.1 | Phase 3 |
| 6. Develop and Maintain Secure Systems and Software | Payment page script inventory (6.4.3) | Phase 4 |
| 7. Restrict Access to System Components and Cardholder Data by Business Need to Know | Six-monthly user access reviews (7.2.4); risk analysis for 7.2.5.1 | Phases 3 and 5 |
| 8. Identify Users and Authenticate Access to System Components | MFA into the CDE (8.4.2); risk analysis for 8.6.3 | Phases 3 and 5 |
| 9. Restrict Physical Access to Cardholder Data | Risk analysis for POI device inspections (9.5.1.2.1) | Phase 3 |
| 10. Log and Monitor All Access to System Components and Cardholder Data | Daily log reviews (10.4.1); risk analysis for 10.4.2.1 | Phases 3 and 5 |
| 11. Test Security of Systems and Networks Regularly | Scans (11.3); penetration and segmentation tests (11.4); file comparisons (11.5.2); tamper detection (11.6.1) | Phases 4 and 5 |
| 12. Support Information Security with Organizational Policies and Programs | Policy review, risk analyses, scope, training, TPSPs and incident response (12.1–12.10) | Phases 1–3, 5 and 7 |
From 3 June to 20 July 2026 the Council ran a request for comments on v4.0.1, the first step towards the next version. At the time of review no draft or publication date had been announced, and v4.0.1 remains the version to assess against. The Council’s June 2026 guidance on compensating controls and the customized approach clarifies both but changes no requirement.
A recurring schedule starts the scan checklist every three months, the access and NSC reviews every six, and this checklist once a year, with dynamic due dates. A missed quarter shows up as an overdue checklist with a name on it.
Conditional logic reads the Phase 1 answers and shows the service provider phase, segmentation test, payment page tasks and the SAQ or ROC task only where they apply. A redirect-only merchant never sees tasks it does not need, and a service provider cannot skip the ones it does.
Scan reports, test reports, risk analyses and provider AOCs sit on the task they support. The activity trail records who completed each step and when, scope sign-off runs as an approval, and template versioning keeps each year’s record tied to the checklist it used.
CheckFlow is not an Approved Scanning Vendor, a QSA, a scanner or a GRC platform. It runs the scheduled work and sign-offs around your scanning, testing and assessment providers. Attach reports with card numbers masked, so the checklist never becomes part of your CDE. CheckFlow’s compliance checklist software shows how the same schedules, evidence and approvals work across your whole compliance calendar.
If you also need a SOC 2 report, much of this evidence carries over to the SOC 2 Readiness Checklist. For due diligence on the Phase 2 providers beyond their AOC, use the Vendor Risk Assessment Checklist. The Council mapped PCI DSS v4.0.1 to NIST CSF 2.0 in July 2026, and the NIST CSF 2.0 Checklist runs that wider assessment.
Version 4.0.1, published in June 2024, is a limited revision. It corrects formatting and typographical errors and clarifies the intent of some requirements, but adds or deletes none. Version 4.0 was retired on 31 December 2024, so assessments today are against v4.0.1, although many people still say “PCI DSS 4.0”.
The requirements v4.0 introduced as best practices until that date. They include targeted risk analyses (12.3.1), MFA for all non-console access into the CDE (8.4.2), payment page script controls (6.4.3, 11.6.1), automated log reviews (10.4.1.1), anti-phishing mechanisms (5.4.1), 12-character passwords (8.3.6) and a procedure for unexpected PAN (12.10.7).
Ask your acquirer. The card brands’ programmes and the acquirer decide, not the PCI SSC. Your level comes from your annual transaction volume with each brand, and the SAQ type from how you accept cards. A merchant with fully outsourced e-commerce payments may qualify for SAQ A, and anyone using the customized approach needs a ROC. Record the answer on the first task.
Internal and ASV scans at least every three months and after significant change (11.3.1, 11.3.2). Internal and external penetration tests at least every 12 months and after significant change (11.4.2, 11.4.3). Segmentation tests every 12 months, or six for service providers (11.4.5, 11.4.6). For a first assessment, four passing ASV scans are not required if the latest passed, policy requires quarterly scans and findings were corrected.
A documented analysis that justifies a choice PCI DSS leaves to you, usually how often a control runs. Under 12.3.1 it identifies the assets, the threats, the factors affecting likelihood and impact, and how the chosen frequency addresses the risk. Each is reviewed at least every 12 months. The customized approach needs a separate analysis under 12.3.2, approved by senior management.
The Council ran a request for comments on v4.0.1 from 3 June to 20 July 2026. At the time of review no draft or date had been announced, and the standard lists v4.0.1’s retirement date as to be determined. For comparison, v4.0 and v3.2.1 ran side by side from March 2022 until 31 March 2024.
14-day free trial, no card required. The Business plan is $10 per user per month after the trial. Full details at checkflow.io/pricing.
