PCI DSS Readiness Checklist: Preparing for a PCI DSS 4.0.1 Assessment

Most failed or delayed PCI DSS assessments are not caused by missing firewalls but by unclear scope, missing evidence and requirements that became mandatory on 31 March 2025 without anyone owning them. This checklist helps a merchant or service provider confirm it is ready for a PCI DSS v4.0.1 assessment, whether that is a Report on Compliance (ROC) with a Qualified Security Assessor or a Self-Assessment Questionnaire (SAQ). It is written for compliance leads, security engineers and the executive who signs the Attestation of Compliance (AOC). It does not restate the standard: it lists the checks to run, and the evidence to have ready, in the order an assessor will look for them. For what the standard says and why, see the PCI DSS 4.0 Guide.

How to use this template

• Replace text in square brackets, such as [Organisation], [Compliance lead] and [QSA firm], with your own details.
• Work through sections 1 to 8 in order. Scope (section 1) decides how much of the rest applies, so do not start collecting evidence before scope is agreed.
• For each check, record an owner, a status (Ready, Gap, Not applicable, Customised) and a link to the evidence. "Not applicable" needs a written reason the assessor can verify, for example no wireless in the CDE.
• Requirement numbers refer to PCI DSS v4.0.1, which the PCI Security Standards Council (PCI SSC) document library listed as the current version when this page was written. v4.0 was retired on 31 December 2024. Confirm the current version and SAQ revision in the PCI SSC document library before you start.
• Run the checklist at least [three] months before the assessment window, then again two weeks before fieldwork.

1. Scope and validation route

• [Organisation] has a current cardholder data flow diagram showing every system, person and third party that stores, processes or transmits account data, and every system that can affect its security.
• Scope has been confirmed and documented at least once every 12 months and after significant change (Requirement 12.5.2). Service providers confirm scope every six months (12.5.2.1).
• A data discovery exercise has looked for primary account numbers (PAN) outside the defined cardholder data environment (CDE), including logs, file shares, ticketing systems and backups. A process exists to treat PAN found in an unexpected place as an incident (12.10.7).
• Segmentation controls that reduce scope are documented and were tested by penetration testing within the required period (annually for merchants, every six months for service providers). See the Network Segmentation Guide.
• The validation route is agreed in writing with the acquirer or payment brand: ROC, or which SAQ.
• For e-commerce merchants on SAQ A, [Organisation] can show its site is not susceptible to attacks from scripts that could affect its e-commerce systems, the eligibility criterion added in the January 2025 SAQ A revision. Evidence can come from the merchant, a third party, or the payment page provider if its instructions are followed.
• All third-party service providers (TPSPs) in scope are listed with the requirements each one manages, the requirements [Organisation] manages, and those that are shared (12.8.5), plus each provider's current AOC.

2. Governance, risk and documentation

• Each of Requirements 1 to 12 has a documented policy and procedure, kept current and known to the people who use them (the x.1.1 requirements), and roles and responsibilities are assigned (the x.1.2 requirements).
• Every requirement that lets the entity set its own frequency has a targeted risk analysis (TRA) under 12.3.1, for example the frequency of payment page checks under 11.6.1, of periodic malware scans and of system account password changes (8.6.3).
• Where the customised approach is used, a TRA exists for each affected requirement (12.3.2) and a controls matrix is complete. The PCI SSC describes the customised approach as intended for risk-mature organisations and advises designing, implementing and documenting those controls well before the assessment starts.
• Service providers have executive responsibility for PCI DSS compliance formally assigned (12.4.1) and quarterly reviews of personnel following procedures (12.4.2).
• Cryptographic cipher suites and protocols in use are inventoried and reviewed at least once every 12 months (12.3.3), and hardware and software technologies are reviewed for continued vendor support (12.3.4).
• Security awareness training covers phishing and social engineering (12.6.3.1) and acceptable use of end-user technologies (12.6.3.2).
• The incident response plan is tested at least annually and covers skimming, PAN exposure and alerts from change-detection mechanisms (12.10).

3. Network and system configuration

• Network security control (NSC) rule sets are reviewed at least once every six months, and every rule has a documented business justification (1.2.7). See the Firewall Rule Review Checklist.
• Inbound traffic to the CDE is restricted to what is necessary, and NSCs sit between trusted networks and wireless or other untrusted networks.
• Configuration standards exist for every system component type in scope, based on industry hardening guidance, and vendor default accounts are removed or disabled (2.2).
• An inventory of system components in scope is current (12.5.1).
• An inventory of bespoke and custom software and third-party components is maintained to support vulnerability and patch management (6.3.2).

4. Protecting account data

• Sensitive authentication data is not retained after authorisation, and data retention and disposal rules are applied and tested at least every three months (3.2.1).
• PAN is rendered unreadable wherever stored (3.5.1), and disk or partition-level encryption is not relied on as the only method on non-removable media (3.5.1.2).
• Keyed cryptographic hashes are used where hashes of PAN are stored (3.5.1.1).
• Remote users with access to full PAN are technically prevented from copying or relocating it unless explicitly authorised (3.4.2).
• Cryptographic keys are stored separately from the data they protect, in as few locations as possible, with access restricted to the fewest custodians (3.6, 3.7). The AI Agent Retail Card Theft Campaign 2026 shows the failure: once the attackers reached a reachable application encryption key, stored card numbers could be decrypted.
• Strong cryptography protects PAN in transit over open, public networks, and certificates used for that purpose are confirmed valid and inventoried (4.2.1, 4.2.1.1).

5. Identity, access and authentication

• Access to system components and data is assigned on least privilege and need to know, and user accounts and their privileges are reviewed at least once every six months (7.2.4).
• Application and system accounts are assigned and managed on least privilege, with access reviewed per a TRA (7.2.5, 7.2.5.1).
• Multi-factor authentication is enforced for all non-console access into the CDE, not just for administrators (8.4.2), and for all remote network access from outside the entity's network (8.4.3). Under v4.0.1, MFA for non-administrative CDE access is not required for accounts that use only phishing-resistant authentication.
• MFA cannot be bypassed, is not susceptible to replay, and needs at least two different factor types (8.5.1).
• Passwords, where used as the only factor, are at least 12 characters and contain numbers and letters (8.3.6).
• Interactive login to system and application accounts is controlled and attributable (8.6.1), passwords for those accounts are not hard-coded in scripts, configuration files or source code (8.6.2), and are changed at the frequency set by a TRA (8.6.3). See the Identity Security Regulatory Map for how these map to other frameworks.

6. Software, web and payment page security

• Critical vulnerabilities are patched within one month of release (6.3.3). v4.0.1 restored the 30-day window to critical vulnerabilities only.
• Public-facing web applications are protected by an automated technical solution that detects and prevents web-based attacks, such as a web application firewall (6.4.2). See the Web Application Firewall Guide.
• Every script loaded and executed in the consumer's browser on payment pages is in an inventory with a written justification, is authorised, and has its integrity assured (6.4.3).
• A change- and tamper-detection mechanism alerts personnel to unauthorised changes to HTTP headers and script contents of payment pages as received by the browser, at least weekly or at a TRA-defined frequency (11.6.1). See the Client-Side Security Guide.
• Write access to the web servers, storage buckets and content delivery networks that serve payment pages is restricted and monitored. In the card theft campaign above, an access key with write permission to the bucket behind a store's CDN let the operator serve skimmers from the victim's own infrastructure.
• Anti-phishing mechanisms are in place to detect and protect personnel against phishing attacks (5.4.1).

7. Logging, monitoring and testing

• Audit logs are reviewed by automated mechanisms (10.4.1.1), retained for at least 12 months with the most recent three months immediately available (10.5.1). See the Log Management and Retention Guide.
• Failures of critical security control systems, such as NSCs, logging, anti-malware and change detection, are detected, alerted and responded to promptly (10.7.2).
• Internal vulnerability scans run at least every three months and use authenticated scanning (11.3.1, 11.3.1.2). Vulnerabilities not ranked high-risk or critical are managed per a TRA (11.3.1.1).
• External scans by a PCI SSC Approved Scanning Vendor (ASV) are passing for each quarter of the review period (11.3.2).
• Internal and external penetration tests are completed at least annually and after significant change, against a documented methodology (11.4.1 to 11.4.3). See the Penetration Test Scoping Checklist.

8. Evidence pack and assessment logistics

• Evidence covers the full period under review, not just the week before fieldwork: four quarters of ASV scans, six-monthly rule reviews, access reviews and training records.
• Each requirement has a named subject matter expert available for interviews during fieldwork.
• Sampling populations are ready: lists of in-scope servers, network devices, users, administrators and changes, so the assessor can choose samples.
• Compensating controls, if any, have a completed compensating control worksheet showing the constraint, the objective and the extra risk mitigated.
• The executive who will sign the AOC has been briefed on scope, open gaps and the validation route at least [four] weeks before submission.

Implementation guidance

1. Weeks 1 to 2, scope: rebuild the data flow diagram, run PAN discovery, confirm the SAQ or ROC route with the acquirer. Scope reduction (tokenisation, hosted payment pages, P2PE) is cheaper before the assessment than during it.
2. Weeks 3 to 4, gap assessment: mark every check Ready, Gap, Not applicable or Customised. Prioritise the requirements that became mandatory on 31 March 2025 (for example 5.4.1, 6.4.3, 8.4.2, 10.4.1.1, 11.6.1, 12.3.1), because they are the ones most likely to lack a full period of evidence.
3. Weeks 5 to 10, remediation: fix gaps in order of assessor impact. Test changes in a pilot first, for example run payment page monitoring in alert-only mode on one checkout before enforcing a script allow-list, and keep a documented rollback for each change to a production payment flow.
4. Weeks 11 to 12, evidence dry run: an internal reviewer or [QSA firm] in an advisory role samples evidence the way an assessor would.
5. Ongoing: move from annual effort to business-as-usual, with quarterly evidence collection. See the Compliance Automation Guide and the Compliance Calendar Template.

Smaller merchants usually gain most by reducing scope: a hosted payment page or P2PE terminal can move them from SAQ D to a much shorter SAQ. Larger merchants and service providers should consider the customised approach only where a mature risk function can maintain the controls matrix and TRAs; otherwise the defined approach is faster to assess.

Readiness measures worth tracking monthly:

Mapping to other frameworks: the scoping and inventory checks support NIST CSF 2.0 ID.AM and NIST SP 800-53 CM-8, the MFA checks map to IA-2, payment page integrity to SI-7, and automated log review to AU-6. See the PCI DSS 4.0 to ISO 27001 Mapping Guide.

Sources: PCI SSC: Document Library · PCI SSC: Just Published, PCI DSS v4.0.1 · PCI SSC: Important Updates Announced for Merchants Validating to SAQ A · PCI SSC: Guidance for PCI DSS E-commerce Requirements Effective After 31 March 2025 · PCI SSC: Is the Customized Approach Right for Your Organization? · PCI SSC: SAQ Types

This checklist is provided for guidance, must be adapted to your organisation and is not legal advice. Related NHI Mgmt Group resources: PCI DSS 4.0 Guide · Client-Side Security Guide · Network Segmentation Guide · Regulatory Change Management Guide