The short answer
A PCI compliance checklist breaks PCI DSS v4.0.1 into its 12 requirements, grouped under six goals, and lists the checks and evidence behind each. How much applies depends on how you take card payments: SAQ A covers a small subset, while SAQ D and a QSA's Report on Compliance cover all 12. Confirm your scope first.
On this page
- The 12 requirements as checklist sections
- Which parts of the checklist apply to you?
- The PCI compliance checklist, requirement by requirement
- Which future-dated requirements are now mandatory?
- Using this as a PCI audit checklist
- Can I get an editable copy of this checklist?
- Why use Sovereign Secure for PCI DSS?
- What should you do next?
This PCI compliance checklist turns PCI DSS v4.0.1 into items you can tick off and prove. It works as a full PCI DSS requirements checklist: all 12 requirements under the standard’s six goals, the sub-requirements that matter most, the evidence a Qualified Security Assessor (QSA) will ask to see and the common failure points. Use it for a Self-Assessment Questionnaire (SAQ), to prepare for a Report on Compliance (ROC) or as a first-pass gap analysis. If you are still asking what is PCI DSS, start with our plain-English guide to the standard.
The 12 requirements as checklist sections
PCI DSS groups its 12 requirements under six goals, often called the six principles of PCI DSS, and this checklist uses the requirements as its sections. Each has numbered sub-requirements and testing procedures. For what each requirement asks for in practice, see PCI DSS requirements explained.
| # | Requirement (v4.0.1 wording) | Goal |
|---|---|---|
| 1 | Install and maintain network security controls | Secure network and systems |
| 2 | Apply secure configurations to all system components | Secure network and systems |
| 3 | Protect stored account data | Protect account data |
| 4 | Protect cardholder data with strong cryptography during transmission over open, public networks | Protect account data |
| 5 | Protect all systems and networks from malicious software | Vulnerability management |
| 6 | Develop and maintain secure systems and software | Vulnerability management |
| 7 | Restrict access to system components and cardholder data by business need to know | Access control |
| 8 | Identify users and authenticate access to system components | Access control |
| 9 | Restrict physical access to cardholder data | Access control |
| 10 | Log and monitor all access to system components and cardholder data | Monitoring and testing |
| 11 | Test security of systems and networks regularly | Monitoring and testing |
| 12 | Support information security with organisational policies and programmes | Security policy |
Every requirement opens with the same two checks (x.1.1 and x.1.2): documented, current policies and procedures, and assigned, understood roles and responsibilities. Confirm both for all 12 first. Our guide to PCI documentation sets out the policies and procedures each requirement expects.
Which parts of the checklist apply to you?
Your validation route decides how much applies. In the UK, PCI DSS is a contractual obligation set by your acquirer (such as Worldpay, Barclaycard or Lloyds Cardnet; see our guide to Worldpay PCI compliance), not a law, so the acquirer tells you which SAQ or report to submit (see PCI compliance in the UK).
| Validation route | Typical set-up | How much applies |
|---|---|---|
| SAQ A | Card-not-present, with every payment page or form supplied by a PCI DSS-compliant provider (hosted page, redirect or iframe) | Smallest e-commerce subset, plus (since January 2025), if you embed the provider’s form in an iframe, confirming your site is not susceptible to script attacks that could affect your e-commerce systems |
| SAQ A-EP | Your website delivers or controls part of the payment page (direct post, JavaScript form) | Most of Requirements 1 to 12, including 6.4.3 and 11.6.1 |
| SAQ B / B-IP | Standalone terminals: dial-out (B) or IP-connected and PTS-approved (B-IP) | Terminals, physical security and policy |
| SAQ C-VT | Cards keyed one at a time into a provider’s virtual terminal on a segmented computer; see taking card payments over the phone | That computer and who uses it |
| SAQ C | Internet-connected payment application, no stored card data | A moderate subset |
| SAQ P2PE | Only terminals from a PCI-listed P2PE solution | Smallest card-present subset |
| SAQ D (merchant) | Anything else, including storing card data electronically | Every applicable requirement |
| SAQ D (service provider) or ROC | Service providers; Level 1 merchants and service providers need a QSA’s ROC | Everything, plus service-provider-only items |
If several rows fit, you may need more than one SAQ or a single SAQ D. Our guide to which SAQ you need explains the eligibility criteria.
The PCI compliance checklist, requirement by requirement
Mark each item met, partly met or not met, and note where the evidence lives. † = future-dated in v4.0, mandatory since 31 March 2025. SP = service providers only.
Build and maintain a secure network and systems (Requirements 1 to 2)
| ☐ | Check | Evidence a QSA will ask for |
|---|---|---|
| ☐ | 1.2.3 to 1.2.4 Network and data-flow diagrams show every connection to the cardholder data environment (CDE), including wireless and cloud | Current diagrams that match a walk-through |
| ☐ | 1.2.5, 1.3.1 to 1.3.2 Every allowed port and service has a business need; CDE traffic limited to what is necessary, everything else denied | Rule sets with justifications |
| ☐ | 1.2.7 Firewall and cloud security group rules reviewed every six months | The last two review records |
| ☐ | 1.5.1 Laptops that connect to both the internet and the CDE have controls users cannot disable | Endpoint policy exports |
| ☐ | 2.2.1 Hardening standards for every system type, based on an industry source such as CIS Benchmarks | Standards and sampled builds |
| ☐ | 2.2.2 Vendor default accounts disabled or their passwords changed | Sampled account listings |
| ☐ | 2.2.7 All non-console admin access encrypted | SSH or TLS settings; no Telnet |
Common failures: diagrams that no longer match the network, and cloud security groups left out of the six-monthly rule review.
Protect account data (Requirements 3 to 4)
| ☐ | Check | Evidence a QSA will ask for |
|---|---|---|
| ☐ | 3.2.1 Stored account data kept to a minimum; data past retention deleted, verified every three months | Retention policy; last quarterly check |
| ☐ | 3.3.1 No sensitive authentication data (full track, CVV2/CVC2, PIN) kept after authorisation, even encrypted | Data discovery results, including logs and call recordings |
| ☐ | 3.4.1 PAN masked on screen (BIN and last four digits at most) unless a role needs more | Screens viewed under different roles |
| ☐ | 3.5.1, 3.5.1.2† Stored PAN unreadable (tokenisation, truncation, keyed hashes or strong encryption); disk encryption alone no longer counts for non-removable media | Design document; sample queries |
| ☐ | 3.6 to 3.7 Keys stored securely, changed at the end of their cryptoperiod, with split knowledge and dual control for manual operations | Key procedures; custodian acknowledgements |
| ☐ | 4.2.1, 4.2.1.1† Strong cryptography for PAN over public networks; valid, inventoried certificates | TLS configuration; certificate inventory |
| ☐ | 4.2.2 PAN never sent unprotected by email, chat or text message | Messaging policy; data loss prevention settings |
Common failures: card numbers in unexpected places (tickets, spreadsheets, logs, call recordings with spoken security codes), and “encrypted at rest” relying on disk encryption alone. Our guide to PCI DSS encryption requirements covers Requirement 3 in full, including key management.
Maintain a vulnerability management programme (Requirements 5 to 6)
| ☐ | Check | Evidence a QSA will ask for |
|---|---|---|
| ☐ | 5.2.1, 5.3.1 Anti-malware on every system at risk, updating automatically | Coverage and update report |
| ☐ | 5.2.3, 5.2.3.1† Systems judged not at risk re-evaluated at a frequency set by targeted risk analysis | Evaluation records |
| ☐ | 5.4.1† Automated anti-phishing controls | Email security settings (for example DMARC, link scanning) |
| ☐ | 6.2.2, 6.2.4 Developers trained in secure coding every 12 months; code resists common attacks | Training records; OWASP-based coding standard |
| ☐ | 6.3.1, 6.3.3 Vulnerabilities risk-ranked; critical patches installed within one month of release | Patch reports with release and install dates |
| ☐ | 6.4.2† Automated solution that detects and prevents web-based attacks on public-facing web applications | WAF set to block, or to alert with immediate investigation |
| ☐ | 6.4.3† Every payment-page script authorised, integrity-checked and inventoried with a justification | Script inventory; CSP, SRI or monitoring output |
| ☐ | 6.5.1 to 6.5.6 Change control; separate test environments; no live PANs in pre-production | Sampled change tickets |
Common failures: patch reports without release dates, so the one-month window can’t be proven, and script inventories that miss tag-manager tags.
Implement strong access control measures (Requirements 7 to 9)
| ☐ | Check | Evidence a QSA will ask for |
|---|---|---|
| ☐ | 7.2.1 to 7.2.3 Role-based, least-privilege access, formally approved | Role matrix; sampled approvals |
| ☐ | 7.2.4†, 7.2.5† All user accounts (including third parties) reviewed every six months; system accounts on least privilege | Signed reviews; service account inventory |
| ☐ | 8.2.5, 8.2.6 Leavers removed immediately; accounts inactive for 90 days disabled | Leaver list checked against directory exports |
| ☐ | 8.3.4, 8.3.6† Lock-out after no more than 10 failed attempts, for at least 30 minutes; passwords of 12+ characters (8 if unsupported) with letters and numbers | Authentication policy settings |
| ☐ | 8.4.2†, 8.5.1† MFA for all non-console access into the CDE, replay-resistant and not bypassable without an authorised exception | MFA configuration; live demonstration |
| ☐ | 8.6.2† No passwords hard-coded in scripts, configuration files or code | Secrets vault; code review results |
| ☐ | 9.4.1 to 9.4.7 Media with card data secured, logged and securely destroyed | Media inventory; destruction certificates |
| ☐ | 9.5.1 Card terminal list (serial numbers, locations), tamper inspections, trained staff | Terminal inventory; inspection logs |
Common failures: shared administrator accounts on network devices and databases, and terminal lists that don’t match the devices on the shop floor. Our guide to PCI DSS Requirement 8 explains the password, MFA and user ID rules item by item.
Regularly monitor and test networks (Requirements 10 to 11)
| ☐ | Check | Evidence a QSA will ask for |
|---|---|---|
| ☐ | 10.2.1 to 10.2.2 Logs capture card data access, admin actions, failed logins and changes to logging | Logging configuration; sample events |
| ☐ | 10.4.1, 10.4.1.1† Security logs reviewed daily using automated tools | SIEM rules; alert-handling records |
| ☐ | 10.5.1, 10.6 Logs kept 12 months (latest three immediately available); clocks synchronised | Retention settings; NTP configuration |
| ☐ | 11.2.1 Checks for unauthorised wireless access points every three months | Four quarters of results |
| ☐ | 11.3.1, 11.3.1.2† Authenticated internal vulnerability scans every three months; high and critical findings fixed and rescanned | Four quarters of scans and rescans |
| ☐ | 11.3.2 External scans every three months by a PCI SSC Approved Scanning Vendor | Passing ASV scan reports |
| ☐ | 11.4.1 to 11.4.6 Internal and external penetration tests every 12 months and after significant change; segmentation tests (every six months for SPs) | Methodology, reports, retest evidence |
| ☐ | 11.5.2 Change detection on critical files, compared at least weekly | File integrity monitoring alerts |
| ☐ | 11.6.1† Tamper detection on payment-page content and security-relevant HTTP headers, at least every seven days (or as set by targeted risk analysis) | Tool configuration; alert history |
Common failures: ASV scans that pass but omit in-scope external IP addresses, segmentation tests that don’t reach every out-of-scope network, and log sources that stop sending without anyone noticing. For 11.2.1, our wireless security audit checklist shows how to evidence quarterly rogue access point checks. Our guide to PCI DSS Requirement 10 covers every logging sub-requirement, and our PCI DSS penetration testing covers Requirement 11.4, segmentation tests included.
Maintain an information security policy (Requirement 12)
| ☐ | Check | Evidence a QSA will ask for |
|---|---|---|
| ☐ | 12.1.1 to 12.1.4 Security policy reviewed every 12 months; a named executive accountable | Policy with version history |
| ☐ | 12.3.1† Targeted risk analysis for each requirement where you set the frequency (for example 5.2.3.1, 9.5.1.2.1, 10.4.2.1) | One analysis per requirement |
| ☐ | 12.3.3†, 12.3.4† Cipher suites, protocols, hardware and software reviewed every 12 months | Review records |
| ☐ | 12.5.1, 12.5.2 In-scope system inventory; scope confirmed every 12 months and after significant change (every six months for SPs, 12.5.2.1†) | Scoping document; inventory |
| ☐ | 12.6.1 to 12.6.3.1† Awareness training at hire and every 12 months, covering phishing and social engineering | Training records |
| ☐ | 12.8.1 to 12.8.5 Service providers listed, under written agreements, monitored annually, with responsibilities split in writing | Provider AOCs; responsibility matrix |
| ☐ | 12.10.1 to 12.10.7 (12.10.7†) Incident response plan tested every 12 months, 24/7 contacts, and a procedure for PAN found where it shouldn’t be | Plan; last test report |
Common failures: no written split of responsibilities with payment and hosting providers (12.8.5), and template risk analyses with no real analysis behind them.
Which future-dated requirements are now mandatory?
All of them. PCI DSS v4.0 added 64 new requirements, 51 of them future-dated to 31 March 2025; all now apply. v3.2.1 was retired on 31 March 2024 and v4.0.1 (June 2024) is the only active version. If your evidence pack dates from v3.2.1, check these first:
- E-commerce: payment-page scripts and tamper detection (6.4.3, 11.6.1) and an automated web application firewall (6.4.2).
- Authentication: MFA for all non-console CDE access (8.4.2), 12-character passwords (8.3.6), no hard-coded credentials (8.6.2).
- Risk analysis: a targeted risk analysis for each flexible frequency (12.3.1).
- Scanning and logs: authenticated internal scans (11.3.1.2) and automated log review (10.4.1.1).
- Phishing: technical controls (5.4.1) and awareness training (12.6.3.1).
- Service providers: six-monthly scope confirmation (12.5.2.1) and, if multi-tenant, support for customers’ external penetration tests (11.4.7).
Our guide to what changed in PCI DSS 4.0.1 covers each change in detail.
Using this as a PCI audit checklist
Before your audit, use the checklist to confirm scope, close the gaps it reveals and build evidence that controls have operated over time:
- Confirm scope. Map where card data is captured, processed, stored and transmitted, and every system that can affect its security. Segmentation only reduces scope if it is tested.
- Agree the validation route with your acquirer: SAQ, QSA-signed SAQ or ROC.
- Run a gap analysis against the tables above.
- Fix gaps in risk order. PCI SSC’s Prioritized Approach tool groups requirements into six milestones, starting with removing sensitive authentication data and limiting retention. Where a genuine technical or business constraint stops you meeting a requirement as written, see our guide to PCI DSS compensating controls.
- Build the evidence trail. Quarterly scans, six-monthly reviews and retained logs must exist before the assessor arrives. For a first assessment, a QSA can accept fewer than four quarterly external scans if the latest passed, a documented quarterly process exists and earlier findings were fixed and rescanned.
- Validate and submit. Complete the SAQ or ROC, sign the Attestation of Compliance (AOC) and send it to your acquirer.
- Keep it running. After sign-off, a compliance calendar keeps scans, reviews and tests on schedule until the next assessment; see PCI DSS business as usual, which has a free downloadable calendar.
Our PCI DSS consultancy team can run steps 1 to 3 ahead of your PCI compliance audit. For the people and planning side, see how to prepare for a PCI audit and the most common PCI DSS audit failures. To turn these steps into a dated plan with owners, use our PCI DSS compliance roadmap template, and if you self-assess, our guide on how to fill out a PCI SAQ covers step 6.
Can I get an editable copy of this checklist?
Yes. Use the enquiry form below, which is already set to PCI DSS Assessments, mention the checklist and we will email you the editable version; there is no automatic download.
Why use Sovereign Secure for PCI DSS?
Sovereign Secure Ltd is a PCI SSC-approved Qualified Security Assessor (QSA) company and also holds the Council’s Qualified PIN Assessor (QPA) and Card Production Security Assessor (CPSA) approvals, which you can check on the PCI SSC assessor listings. We are a member of the PCI SSC Global Executive Assessor Roundtable (GEAR) for 2026 to 2028.
- PCI DSS compliance services spanning scoping, gap analysis, assessment and penetration testing, with quarterly ASV scans delivered through our PCI SSC Approved Scanning Vendor partner.
- ISO 27001 certified, and an IASME-licensed Cyber Essentials certification body.
- Clients include Fiserv, Accor, Ticketmaster and Cashplus.
- Incorporated in 2012 and headquartered at 16 Whalley Road, Accrington, with offices in Los Angeles, Singapore, Dubai and Dhaka.
What should you do next?
Found more than a handful of gaps? Start with a gap analysis. Most items met and evidenced? Book your assessment. Want a quicker first pass before either? Try our free PCI compliance check. Tell us your SAQ type or merchant level through the enquiry form or call +44 161 523 5276 for a quote.
Your next step
- PCI compliance checkAnswer 22 questions for a readiness score, your likely SAQ and a fix list.Start the free check
- PCI DSS document indexThe policies, procedures and records each PCI DSS requirement needs, as a free spreadsheet.Get the document index
- Get a PCI quoteTell us how you take card payments and we will confirm your validation route and scope.Get a PCI quote
Last reviewed October 2026 by the Sovereign Secure assessment team.
