Compliance Checklist
PCI DSS v4.0.1 Compliance Checklist (2026)
This checklist covers the 12 requirements of PCI DSS v4.0.1 for merchants and service providers that store, process, or transmit cardholder data. PCI DSS v4.0 became mandatory on 31 March 2024. The appropriate compliance validation method for your merchant level must be confirmed with your acquiring bank.
Want to see how your website scores on PCIDSS? Run a free PrivacyGrader scan.
Grade my siteReq. 1 — Network Security Controls
Req. 2 — Secure Configurations
Req. 3 — Protect Stored Account Data
Req. 4 — Protect Data in Transit
Req. 5 — Protect Against Malware
Req. 6 — Secure Systems & Software
Req. 7 — Restrict Access by Business Need
Req. 8 — Identify Users & Authenticate Access
Req. 9 — Restrict Physical Access
Req. 10 — Log & Monitor All Access
Req. 11 — Test Security Regularly
Req. 12 — Information Security Policy
What is PCI DSS and who must comply?
The Payment Card Industry Data Security Standard (PCI DSS) is a set of security requirements maintained by the PCI Security Standards Council (PCI SSC), founded by American Express, Discover, JCB, Mastercard, and Visa. PCI DSS applies to any organisation that stores, processes, or transmits cardholder data — including merchants of all sizes, payment processors, acquiring banks, issuing banks, and all service providers involved in payment processing. There is no revenue or transaction volume threshold: if you accept card payments, PCI DSS applies.
Merchants are categorised into four levels based on annual Visa transaction volume. Level 1 merchants (over 6 million transactions) require an annual on-site assessment by a Qualified Security Assessor (QSA). Level 2 to 4 merchants may self-assess using the appropriate Self-Assessment Questionnaire (SAQ). Using a hosted payment solution like Stripe Elements, Braintree Drop-in, or PayPal Checkout — where card data never touches your servers — significantly reduces scope and typically qualifies merchants for SAQ A, the simplest form.
PCI DSS v4.0.1 — what changed in 2025?
PCI DSS v4.0 was released in March 2022 and replaced v3.2.1, which retired on March 31, 2024. PCI DSS v4.0.1, a minor clarification update, was released in June 2024. The standard introduces 64 new requirements, many of which were "best practices" with a compliance deadline of March 31, 2025. Key new requirements include: customised implementation approach, targeted risk analyses, multi-factor authentication for all access to the cardholder data environment (Req. 8.4.2), and expanded e-commerce security requirements covering payment page scripts (Req. 6.4.3 and 11.6.1).
Non-compliance can result in fines from card brands of $5,000–$100,000 per month, increased transaction fees, mandatory forensic investigations following a breach, and ultimately card acceptance privileges being revoked.
How to use this PCI DSS compliance checklist
Begin by determining your merchant level and applicable SAQ type — your acquiring bank can confirm this. The 12 requirements in this checklist map directly to the PCI DSS v4.0.1 standard. Each item includes the official requirement reference so you can cross-check against the full standard published at pcisecuritystandards.org.
If your business also stores health data, review our HIPAA checklist. If you operate internationally and handle EU customer data, the GDPR checklist applies as well. Download the PDF to share your progress with your QSA, internal audit team, or acquiring bank.
What this checklist is for, and what it is not
This checklist covers the 12 core requirements of PCI DSS v4.0.1 for merchants and service providers. It is aimed at Level 2 through Level 4 merchants and service providers preparing for Self-Assessment Questionnaire completion, and at compliance teams conducting a gap analysis ahead of a QSA engagement.
What it does not cover: the specific SAQ type that applies to your business (your acquiring bank determines this); the Customised Implementation path available under PCI DSS v4.0 for organisations with mature security programmes; specific network penetration testing methodologies under Requirement 11; the complete evidence requirements for a formal QSA assessment; or contractual obligations between your business and your acquiring bank. The appropriate compliance validation method for your merchant level must be confirmed with your acquiring bank. Last verified May 2026 against PCI DSS v4.0.1 at pcisecuritystandards.org.
Real-world PCI DSS enforcement cases
In December 2013, attackers accessed Target Corporation's point-of-sale systems through a third-party HVAC vendor, compromising the cardholder data of approximately 40 million customers. Target reached an $18.5 million settlement with 47 state attorneys general in 2017, and a separate settlement with Visa. The attack exploited the "vendor access as attack vector" risk addressed directly in PCI DSS Requirement 12.8 (managing third-party service providers) and Requirement 1.3 (network access controls). The HVAC vendor had network access to Target's environment, and that access was not segmented from the cardholder data environment.
In October 2020, the UK Information Commissioner's Office fined British Airways £20 million for a 2018 breach that exposed the personal and payment card data of approximately 400,000 customers. (The original proposed fine of £183 million was reduced following British Airways' cooperation and the economic impact of COVID-19.) The breach involved malicious code injected into British Airways' website that harvested payment data as customers entered it. This type of payment form skimmer attack is precisely what PCI DSS v4.0 Requirements 6.4.3 and 11.6.1 (payment page script integrity monitoring) are designed to prevent.
In 2014, attackers used stolen vendor credentials to deploy malware on Home Depot's point-of-sale systems across all US and Canadian stores, exposing 56 million payment card records over five months. Home Depot agreed to pay $17.5 million to 46 states in 2020. The attack method highlights the importance of Requirement 8.2 (unique user IDs), Requirement 7.2 (access control), and Requirement 12.8 (third-party vendor management).
Common PCI DSS mistakes
Storing the card verification value after authorisation. PCI DSS Requirement 3.3.1 explicitly prohibits storing the card security code (CVV/CVC) after transaction authorisation, even in encrypted form. No exceptions exist. Organisations that log raw payment API responses, store transaction objects without sanitising them, or retain full card data in databases are frequently in violation without realising it. Run a search across your logs, databases, and application code for patterns that match full card numbers or CVV formats.
Scope creep in the cardholder data environment. PCI DSS compliance applies to the Cardholder Data Environment (CDE) and all systems that connect to or could impact its security. Many merchants believe their scope is narrow, but every system with network access to the CDE is in scope for most requirements. Systems added over time, including new SaaS integrations, analytics tools, and monitoring agents, can silently extend scope. An annual scope review (Requirement 12.5.2) and network segmentation validation (Requirement 11.4.5) are required.
Assuming a hosted payment page eliminates all PCI scope. Using a fully hosted payment page reduces scope to SAQ A in most cases. However, if your website includes any JavaScript loaded on the payment page or that could affect payment form behaviour — analytics tags, A/B testing scripts, customer support widgets — Requirement 6.4.3 (payment page script inventory and integrity verification) applies. The Magecart attacks affecting British Airways and hundreds of other sites exploited exactly this gap.
What changed in PCI DSS: 2024 to 2026
PCI DSS v3.2.1 retired on 31 March 2024. All assessments from that date must be against v4.0 (or v4.0.1, the clarification update published in June 2024). Of the 64 new requirements introduced in v4.0, many were "best practice" until 31 March 2025, after which they became mandatory. Key post-March-2025 requirements include targeted risk analysis to justify control frequencies (Requirement 12.3.2), multi-factor authentication for all CDE access (Requirement 8.4.2), and the payment page script controls (Requirements 6.4.3 and 11.6.1). If your last assessment was against v3.2.1, a full gap analysis against v4.0.1 is necessary.
Requirements 6.4.3 and 11.6.1 of PCI DSS v4.0 require merchants with e-commerce payment pages to maintain an inventory of all scripts loaded on payment pages, confirm authorisation for each script, maintain an integrity attribute for each, and implement a mechanism to detect unauthorised modification of HTTP headers and payment page contents. These requirements became mandatory on 31 March 2025. Many merchants operating hosted checkout flows are unaware these requirements apply to them. Last reviewed May 2026 by the Zeta Solutions editorial team.