PCI-DSS Compliance Checklist 2026: Requirements for Every Merchant Level

On March 31, 2025, the grace period ended. All 64 new or updated requirements introduced in PCI DSS v4.0 became mandatory — no more "future-dated" exemptions, no more treating them as optional best practices. Every PCI DSS assessment conducted from that point forward evaluates merchants against the full v4.0.1 standard.

The first full-year assessment cycles under that requirement land in 2026. And the new script security rules — Requirements 6.4.3 and 11.6.1, which mandate payment page script inventory and real-time tampering detection — are failing merchants who never thought of themselves as having an e-skimming problem. If your checkout page loads any third-party JavaScript, these requirements apply to you.

This is the complete PCI-DSS compliance checklist for 2026: all 12 requirements, what each merchant level actually has to do, which SAQ applies to you, and what's genuinely new in v4.0.1.

First: What merchant level are you?

PCI DSS compliance requirements scale with transaction volume. Your level determines whether you need a full audit by a Qualified Security Assessor or whether a Self-Assessment Questionnaire is enough.

A few important notes. American Express has a different Level 1 threshold — 2.5 million transactions rather than 6 million. If you've had a confirmed data breach involving cardholder data, Visa and Mastercard can bump you to Level 1 regardless of volume. And "all channels" means in-store, online, and phone-order transactions combined, not just your e-commerce numbers.

Which SAQ applies to your payment setup?

The SAQ type depends on how you actually process payments — not your transaction volume or merchant level. Get this wrong and you're certifying compliance against the wrong set of controls.

Most small e-commerce merchants assume they qualify for SAQ A because they use Stripe, Shopify Payments, or a similar hosted checkout. That's only correct if your checkout is fully hosted by the third party — meaning the customer never enters card data on a page you control or serve. If you have any JavaScript from your domain loading on the checkout page, you likely need SAQ A-EP instead, which brings Requirements 6.4.3 and 11.6.1 into scope.

The 12 PCI DSS requirements checklist

These are the 12 requirement areas in PCI DSS v4.0.1, with what each one actually demands in practice.

Requirement 1: Network security controls

Install and maintain a firewall (or equivalent network security control) between untrusted networks and systems in your cardholder data environment (CDE). Document all inbound and outbound traffic rules. Review firewall configurations at least every six months. Network segmentation — keeping card data systems isolated from your general business network — isn't required, but it dramatically shrinks your audit scope.

Requirement 2: Secure configurations

Change all vendor-supplied default passwords on every system, device, and application. Disable all unnecessary services, protocols, and ports. Maintain configuration standards for each system type. This one catches small merchants who set up their payment terminals or network equipment years ago and never changed the defaults.

Requirement 3: Protect stored account data

Don't store sensitive authentication data (CVV codes, magnetic stripe data, PIN data) after authorization — ever. If you must store primary account numbers (card numbers), encrypt or truncate them. Implement data retention policies and delete cardholder data when it's no longer needed. The simplest approach: don't store card data at all and use a tokenization service instead.

Requirement 4: Protect cardholder data in transit

Encrypt cardholder data when transmitting it over open, public networks. TLS 1.2 or higher is required — TLS 1.0 and 1.1 have been prohibited since PCI DSS v3.2.1. Document all encryption methods and keep certificates current. Never send PANs via email, chat, or other end-user messaging technologies unless they're encrypted end-to-end.

Requirement 5: Protect systems against malware

Deploy anti-malware solutions on all systems commonly affected by malware. Keep anti-malware software and definitions current. Perform periodic malware scans. For systems not commonly targeted by malware — certain Unix/Linux systems — document the risk assessment that justifies not deploying anti-malware. v4.0 added a requirement to evaluate and monitor anti-phishing mechanisms.

Requirement 6: Develop and maintain secure systems

This requirement got the most significant additions in v4.0. The fundamentals — patch management, secure development practices, vulnerability management for web applications — remain. But two new sub-requirements added in v4.0 are now mandatory and catching merchants off guard.

Requirement 7: Restrict access by business need

Implement access control systems that restrict access to cardholder data to only those with a documented business need. Deny all access by default and grant access explicitly. Maintain access control lists for all system components. v4.0 strengthened the documentation requirements — "business need" has to be formally defined and approved, not just assumed.

Requirement 8: Identify users and authenticate access

Assign unique IDs to all users. Multi-factor authentication (MFA) is now required for all access to the cardholder data environment — not just for remote access. Passwords for non-consumer accounts must be at least 12 characters (up from 7 in older versions). Password history must prevent reuse of the last 4 passwords. Service accounts must be audited for necessity at least every 12 months.

Requirement 9: Restrict physical access to cardholder data

Control physical access to systems that store, process, or transmit cardholder data. Maintain visitor logs. Protect point-of-interaction devices from tampering and substitution — train staff to inspect POS terminals for skimmers before each shift. Physically secure media containing cardholder data.

Requirement 10: Log and monitor all access

Implement audit logs for all access to cardholder data and system components. Retain logs for at least 12 months, with the most recent three months immediately available for analysis. Review logs daily — or use automated tools that perform equivalent analysis. v4.0 added a requirement to detect failures in audit log systems within 24 hours.

Requirement 11: Test security systems regularly

Conduct quarterly internal vulnerability scans and quarterly external scans by an Approved Scanning Vendor (ASV). Perform penetration testing at least annually and after significant infrastructure changes. Penetration testing must follow a documented methodology and test the full cardholder data environment — internal and external. Requirement 11.6.1 (tamper detection for payment pages) falls under this requirement.

Requirement 12: Support information security with organizational policies

Maintain a comprehensive information security policy reviewed at least annually. Document and implement a risk assessment process. Conduct security awareness training for all personnel at hire and annually. Establish an incident response plan and test it. Manage PCI DSS compliance for service providers — get written acknowledgment from each service provider that they're responsible for the PCI DSS requirements they affect.

The complete PCI DSS checklist by merchant level

Level 4 merchants (most small businesses)

• ✓ Determine which SAQ applies to your payment processing method
• ✓ Complete the appropriate SAQ annually
• ✓ Conduct quarterly external vulnerability scans via an ASV
• ✓ Change all vendor-supplied default passwords (Req. 2)
• ✓ Verify TLS 1.2+ is enforced on all payment pages (Req. 4)
• ✓ Enable MFA for all access to payment systems (Req. 8)
• ! Inventory all scripts on payment pages and implement integrity checks (Req. 6.4.3) — if SAQ A-EP or D applies
• ! Implement tamper-detection monitoring for payment page scripts (Req. 11.6.1) — if SAQ A-EP or D applies
• ✓ Maintain an information security policy reviewed annually (Req. 12)
• ✓ Train all employees on security awareness annually (Req. 12)

Level 2 and 3 merchants

Everything in the Level 4 list, plus:

• ✓ Conduct annual internal vulnerability scans (Req. 11)
• ✓ Conduct annual penetration testing (Req. 11)
• ✓ Implement and document access control lists for all CDE systems (Req. 7)
• ✓ Maintain audit logs for at least 12 months with 3 months immediately accessible (Req. 10)
• ! Review firewall rules at least every 6 months (Req. 1)
• ✓ Review and test incident response plan annually (Req. 12)
• ✓ Obtain written acknowledgment from service providers of their PCI DSS responsibilities (Req. 12)

Level 1 merchants

All of the above, validated by a QSA:

• ✓ Annual Report on Compliance (ROC) completed by a Qualified Security Assessor
• ✓ Quarterly ASV scans (external) and quarterly internal scans
• ✓ Annual penetration test using a defined methodology
• ✓ Attestation of Compliance signed by QSA and company officer
• ! Formal change management process for all CDE modifications (Req. 6)
• ! Anti-phishing mechanism evaluation and implementation (Req. 5)
• ✓ Service account audit at least every 12 months (Req. 8)
• ✓ Audit log failure detection within 24 hours (Req. 10)

What the new script requirements mean for your checkout page

Requirements 6.4.3 and 11.6.1 exist because e-skimming attacks work. Attackers compromise a third-party JavaScript library, an ad network SDK, or a CMS plugin — anything that loads on your checkout page — and inject code that silently copies card numbers as customers type them. The attack is invisible to the merchant and undetectable without active monitoring.

Meeting these requirements means three things:

• Inventory every script. Document every JavaScript file that loads on your payment pages, including third-party scripts from CDNs, analytics, chat tools, and ad networks. Each one needs a documented business justification.
• Verify integrity. Use Subresource Integrity (SRI) hashes for scripts you load from CDNs — the browser will refuse to execute a script if its hash doesn't match. For scripts that update frequently (where SRI is impractical), implement behavior monitoring that detects script changes.
• Monitor for tampering. Requirement 11.6.1 requires active monitoring — not just a one-time inventory. You need alerts when payment page HTTP headers or scripts change unexpectedly.

Subresource Integrity looks like this in practice:

If anyone modifies payment-lib.js — even a single character — the browser blocks the script entirely. For scripts that can't use SRI (dynamic content, frequently-updated libraries), you'll need a Content Security Policy (CSP) and a monitoring tool that alerts on changes.

The cost of non-compliance

Non-compliance fines work differently than most people expect. Card brands don't fine merchants directly — they fine acquiring banks, which pass the costs down. Monthly fines for persistent non-compliance start at $5,000–$10,000, escalate to $25,000–$50,000 by months four through six, and can reach $50,000–$100,000 per month if the situation isn't resolved.

After a breach, the math gets worse. Card brands assess $50–$90 per compromised card record, plus card reissuance costs of $3–$10 per card. Forensic investigations run $20,000–$500,000 depending on scope. And if the breach is large enough, you can lose your ability to accept credit cards entirely — which is a business-ending event for most merchants.

The historical numbers are clear: Target paid $18.5 million in a multistate settlement after its 2013 breach. TJX's total breach costs hit an estimated $256 million. Those were under older PCI DSS versions. The v4.0.1 requirements exist precisely because the attack surface has gotten larger, not smaller.

Frequently asked questions