PCI DSS Compliance Checklist for Merchants in 2026: SAQ Selector, Evidence Pack, and Year-Round Calendar

The complete PCI DSS compliance checklist for 2026. Pick the right SAQ, scope your CDE, and stay audit-ready all year under PCI DSS v4.0.1.

What Is a PCI DSS Compliance Checklist and Who Needs One?

A PCI DSS compliance checklist is a sequenced set of technical and operational controls, drawn from the 12 core PCI DSS requirements, that any merchant storing, processing, or transmitting cardholder data must implement and document year-round.

The most persistent misconception I encounter is this: "We use a hosted checkout, so we are covered." That belief costs real money. A third-party payment page can reduce your PCI compliance checklist scope significantly. But eligibility is precise. If your checkout page loads a single analytics tag, a retargeting pixel, or any script from your own domain, your scope changes, and so does your SAQ. Many merchants only discover this during a QSA visit.

The PCI Security Standards Council (PCI SSC) publishes the standard. Enforcement runs through Visa, Mastercard, American Express, and Discover, and your acquiring bank delivers the penalties on their behalf. Understanding how card scheme compliance enforcement flows through your acquirer is foundational before starting any PCI security compliance checklist program.

Why Does 2026 Change Everything About PCI DSS?

In 2026, PCI DSS v4.0.1 is the only active version. There is no transition window, no grace period, and no version below it that remains valid.

PCI SSC confirmed that v4.0 retired on December 31, 2024. Every requirement previously marked "future-dated best practice" became mandatory on March 31, 2025. Your PCI compliance checklist for 2026 must show 12 months of continuous operational evidence for all of them. Not a policy document. Not a roadmap. Documented proof that controls were active and running throughout the year.

According to the Verizon 2024 Data Breach Investigations Report, payment account data appears in 84% of financial services breach caseloads, and 93% of those breaches carry a financial motive. The PCI 4.0 requirements update exists because the threat environment outpaced the old standard. Universal MFA, client-side script management, and continuous monitoring are now audit checkboxes with evidence requirements attached, not aspirational guidance.

Merchants who treated the transition period as extra preparation time are the ones scrambling now. The priority sequence: scope first, fix Requirements 6.4.3 and 11.6.1 second, then work through the remaining PCI DSS checklist in order of audit impact.

Is Your E-Commerce Checkout Compliant Under PCI DSS Requirements 6.4.3 and 11.6.1?

Requirements 6.4.3 and 11.6.1 are the highest-impact changes in the PCI DSS 4.0 requirements update for online merchants. Both became mandatory on March 31, 2025. Unaddressed, they are the most common audit failure points in 2026 and the reason PCI 4.0 represented the biggest overhaul to payment page security in the standard's history.

Requirement 6.4.3 requires a complete inventory of every JavaScript running on your payment page, a formal authorization record for each script, and integrity verification. Requirement 11.6.1 requires automated detection of unauthorized changes to HTTP security headers and payment page content, with alerting on any deviation.

These requirements exist because e-skimming is not theoretical. Researchers at Malwarebytes documented active Magecart campaigns in 2026 where attackers inject malicious JavaScript into checkout pages to capture card numbers, expiry dates, and CVVs before they reach the payment processor. British Airways and Ticketmaster were both compromised through this exact vector.

I have reviewed environments where the IT team was fully confident in their security posture, only to find their tag management container was loading an unauthorized third-party script with no integrity check. That is a direct 6.4.3 failure. The requirement is not about blocking scripts. It is about knowing exactly what runs, who approved it, and being alerted the moment anything changes.

PCI requirements checklist for 6.4.3 and 11.6.1:

• Inventory every first and third-party JavaScript loading on any page that can affect payment security, including pages with embedded iframes
• Assign ownership and document formal authorization approval for each script, with business justification
• Configure Subresource Integrity (SRI) hashes or Content Security Policy (CSP) headers per script
• Set up automated alerting for any unauthorized script change
• Monitor HTTP security headers for modification and alert on unauthorized changes
• Re-authorize the full script inventory annually or after any significant environment change

According to the PCI SSC e-commerce and payment page security supplement, these requirements apply to any page that can impact a payment transaction, including pages loading payment elements through embedded iframes. Most merchants read "payment page" too narrowly. If a page influences the payment flow, it is in scope.

How Do You Pick the Right SAQ? Use This Decision Path.

The SAQ you use for your PCI compliance checklist is determined by your payment channel and how much cardholder data touches your own systems. Choosing the wrong SAQ does not just create audit risk. It creates a false compliance record, making any future breach significantly more expensive.

Work through these three questions in order:

Is your payment card-present, card-not-present, or both? SAQ A applies strictly to card-not-present merchants. It does not cover face-to-face or in-person transactions under any circumstances.

Is every function handling cardholder data fully outsourced to a compliant third-party service provider, with nothing stored, processed, or transmitted on your own systems? If yes, and your payment page elements originate entirely from that compliant provider, SAQ A may apply. If your systems touch any part of that flow, you are most likely SAQ A-EP or SAQ D.

Do you host your own payment page, redirect to a hosted page, or use embedded elements? Redirect-only or fully hosted solutions reduce scope. Any custom code on a checkout page that calls external scripts, including analytics, reopens scope questions.

If you answered yes to all three, SAQ A is your starting point to discuss with your acquirer. If you answered no to any one of them, use the table below before filing anything.

SAQ and iframes: Many merchants assume that a Stripe, Adyen, or Braintree iframe automatically means SAQ A. That is true only if no merchant-controlled scripts run on that page. If Google Tag Manager fires on your checkout page, your scope has changed. Merchants running payments across multiple processors face an even more complex scoping exercise, since each acquirer relationship can extend the CDE boundary and must be mapped in your network diagrams before you file anything.

PCI DSS SAQ Comparison: Which Validation Path Applies?

How Do Tokenization and a Hosted Vault Shrink Your PCI Compliance Burden?

Tokenization swaps the real card number for a randomly generated token. The token has no exploitable value if someone steals it. Your systems only ever handle the token. Scope shrinks only when card data passes straight from the customer to the tokenization service. That path limits the cardholder data environment to the point of entry and the vault.

This transfers most of the burden to the platform. A fully outsourced or tokenized checkout can drop you from SAQ D (328 questions) to SAQ A (31 questions). SAQ means Self-Assessment Questionnaire, the PCI compliance form you complete yourself. Tokenization works best alongside your other checkout controls. These range from 3D Secure authentication to the card brand rules covered in card scheme compliance. For subscriptions, a portable, merchant-owned vault keeps card-on-file tokens valid across a processor switch. That vault avoids the re-entry churn and downstream issuer declines that migrations can trigger.

The Complete PCI DSS Compliance Checklist by Requirement

Below is the working PCI DSS checklist with action items and the evidence your auditor will ask for under each requirement group.

Requirements 1 and 2: Network Security and Secure Configurations

• Define and document every system, segment, and connection in your CDE with deny-all inbound and outbound policies
• Review all network security control configurations every six months
• Remove all vendor-supplied default passwords before any system goes live
• Maintain a hardening standard and complete component inventory for every system type in scope

Evidence needed: Network diagrams, six-month rule review records, hardening documentation, system inventory with owner assigned. NSC scope in 2026 includes cloud security groups, not just physical firewalls.

Requirements 3 and 4: Data Protection and Encryption in Transit

• Audit what cardholder data you store. If you do not need it, stop storing it
• Use file-level or database-level encryption. Disk-level encryption alone no longer satisfies this requirement
• If storing hashed PANs, confirm they use HMAC cryptographic keying, not simple hashing
• Mask PANs in all non-payment contexts (first six and last four digits only)
• Disable SSL, TLS 1.0, and TLS 1.1. Confirm TLS 1.2 minimum across all cardholder data transmission paths

Evidence needed: Data retention policy, encryption implementation records, key management documentation, scan results confirming deprecated protocols are disabled.

Requirements 5 and 6: Malware Defense and Secure Development

• Deploy tamper-proof anti-malware on all systems. Log all events and document review activity
• Resolve critical vulnerabilities within one month of vendor release
• Complete the 6.4.3 and 11.6.1 script workflow above before anything else in this requirement group
• Maintain documented secure development standards for any in-house payment applications

Evidence needed: Anti-malware configuration and event logs, patch logs cross-referenced to vendor release dates, and script inventory with authorization records.

Requirements 7, 8, and 9: Access Control and Authentication

• Implement RBAC for all CDE access and review quarterly. Revoke access immediately on role change or departure
• Deploy MFA for all CDE access, including non-administrative and internal network logins
• Confirm passwords are at least 12 characters and changed at least every 90 days
• Disable accounts inactive for more than 90 days
• Inspect POI terminals for skimming devices periodically and document each check with the terminal ID and date
• Retain surveillance footage for at least 90 days

Evidence needed: Quarterly access review records, 12 months of login logs showing MFA enforcement, and terminal inspection logs. Universal MFA is the top 2026 audit failure point. Any CDE access without it fails this requirement immediately.

Requirements 10 and 11: Logging, Monitoring, and Testing

• Log all CDE access and retain for at least one year, with three months immediately accessible
• Implement automated log review. Manual review does not meet the standard for most environments
• Run internal and external ASV vulnerability scans quarterly
• Complete annual penetration testing and repeat after any significant environment change

Evidence needed: SIEM configuration records, all four quarterly ASV scan reports with status, annual pen-test report.

Requirement 12: Policy, Training, and Governance

• Conduct and document an annual risk assessment
• Update all security policies annually or after any significant change
• Deliver phishing-aware training at hire and at least annually. Test incident response through an annual tabletop

Evidence needed: Dated risk assessment, policy version history, training completion records, and incident response test documentation.

What Evidence Pack Does Your QSA Actually Want?

The evidence pack is what determines whether you pass. Most PCI security compliance checklists skip this entirely.

Collect and maintain continuously:

• CDE inventory: Every in-scope system, application, and network component with function and owner
• Data flow diagram: Visual map of how cardholder data enters, moves, and exits, including all third-party connections
• TPSP tracker: Every third-party provider that touches cardholder data, with service scope and current AOC on file
• Script inventory: Every JavaScript on your payment page with authorization record, integrity method, and change log
• Patch log: All critical vulnerabilities with remediation dates cross-referenced to vendor release dates
• Access review log: Quarterly records showing reviewer, accounts evaluated, and changes made
• ASV scan reports: All four quarterly reports with status notes
• Training records: Completion dates and content confirmation for all relevant personnel

If your acquirer or QSA requests any of these and you cannot produce them, your self-assessment is inaccurate regardless of what you filed.

What Is the Annual PCI Compliance Calendar?

PCI compliance runs on four rhythms. Monthly: review NSC rule sets, confirm anti-malware is active, monitor payment page scripts and headers under Requirement 11.6.1, and review new CDE access grants. Quarterly: run internal and external ASV scans, review user access lists, inspect POI terminals, and pull log reviews from the prior period. Every six months: formal NSC rule set review and updated TPSP AOC collection.

Annually: complete your SAQ or ROC, run penetration testing, conduct your risk assessment, update policies, run an incident response tabletop, deliver staff training, and re-authorize your full script inventory. After any significant change: repeat pen-testing for affected components, re-validate CDE scope, and re-authorize any new scripts or third-party services before they go live.

Expert Quote

"PCI DSS v4.0 represents the most significant structural change to the standard in over a decade, moving the compliance model from periodic validation to continuous security assurance." Troy Leach, former CTO, PCI Security Standards Council (Source)

What Should You Do Next?

Start with scoping. Map your CDE before completing any PCI DSS checklist item. Know where card data enters, moves, and what systems can reach it. Accurate scoping eliminates days of unnecessary remediation.

Confirm your SAQ route with your acquirer. Do not file SAQ A without verifying eligibility. The wrong SAQ does not protect you. It creates a false compliance record, making any future incident far more costly.

Then prioritize Requirements 6.4.3 and 11.6.1. Script inventory, alerting, and authorization workflow. For e-commerce merchants, these are the two requirements most likely to fail in a 2026 audit, and the ones that expose you to the most financially damaging payment fraud if left unaddressed.

The compliance teams that pass audits without scrambling run it as an operational rhythm, not a periodic project. The calendar above gives you that structure.

Based on what I have seen reviewing merchant environments, the gap between merchants who sail through audits and those who fail them almost always comes down to evidence discipline, not intent. If you want to understand where your payment environment stands before your next assessment window opens, Gateway compliance monitoring helps merchants map compliance gaps and payment performance problems at the same time, because in most cases, they are the same problem.

FAQ

What is PCI DSS 4.0.1?

PCI DSS 4.0.1 is the only active version of the Payment Card Industry Data Security Standard as of January 2025. PCI DSS 4.0.1 replaced v4.0 and introduced 64 updated requirements covering universal MFA, client-side script management, and continuous monitoring for all in-scope merchants.

What is the difference between SAQ A and SAQ A-EP?

SAQ A applies to card-not-present merchants whose entire payment page is hosted by a compliant third party with no cardholder data on merchant systems. SAQ A-EP applies when the merchant's payment page exists on merchant-controlled infrastructure with partial outsourcing, including cases where scripts or redirects run on merchant-owned domains.

Who enforces PCI DSS compliance?

PCI SSC publishes the standard but does not fine merchants directly. Enforcement runs through Visa, Mastercard, American Express, and Discover via their compliance programs. Merchants receive penalties through their acquiring banks.

What happens if a merchant fails PCI compliance?

Non-compliant merchants face monthly fines from $5,000 to $100,000, elevated per-transaction fees from acquirers, mandatory forensic investigation costs following any breach, and in serious cases, termination of card acceptance privileges.

Does Stripe or Shopify Payments make a merchant PCI compliant?

Using a hosted solution reduces scope and may qualify a merchant for SAQ A. It does not eliminate all obligations. Merchants retain responsibility under Requirement 12 and must confirm SAQ eligibility directly with their acquiring bank.

Does tokenization reduce PCI DSS scope?

Yes, but only if card data goes straight from the customer to the tokenization service. That path allows no intermediate stops. When you meet that condition, your cardholder data environment shrinks to the point of entry and the vault. Miss it, and implementation errors can leave you out of compliance.

Should subscription businesses use a merchant-owned payment vault?

For recurring billing, yes. PSP means payment service provider. With PSP-owned tokens, switching processors forces every card-on-file customer to re-enter payment details. That re-entry drives churn during migrations. A merchant-owned or portable vault keeps tokens valid across processors. It turns a processor switch into a configuration change rather than a customer re-entry project.