PCI DSS 4.0.1 Compliance: What High-Risk Merchants Need to Know in 2026

PCI DSS 4.0.1 is now the only enforced standard. Version 3.2.1 retired December 31, 2024, and the future-dated 4.0.1 requirements went fully mandatory on March 31, 2025. If you are a high-risk merchant and you have not updated your Self-Assessment Questionnaire in the last 12 months, you are out of compliance.

This article is the practical 2026 checklist for what actually changed and what high-risk merchants need to do. Our processing partners are PCI-DSS Level 1 compliant, and we help placed merchants navigate their own merchant-level attestation every year.

What PCI DSS Covers for You as a Merchant

PCI DSS applies to every entity that stores, processes, or transmits cardholder data. Your compliance obligation depends on your annual transaction count (Level 1 through 4) and your acceptance channel (e-commerce, in-person, phone).

• Level 1: 6M+ annual transactions — full ROC (Report on Compliance) by a QSA
• Level 2: 1M-6M annual transactions — SAQ, sometimes ROC required
• Level 3: 20k-1M e-commerce transactions — SAQ with quarterly ASV scans
• Level 4: under 20k e-commerce / 1M total — SAQ only, acquirer discretion on scans

Most high-risk merchants are Level 3 or Level 4 and complete SAQ A, A-EP, or D depending on their integration.

Which SAQ Do You Need?

• SAQ A — fully outsourced e-commerce (iframe or full redirect to a PCI-compliant processor like Authorize.Net or NMI)
• SAQ A-EP — your site includes JavaScript that interacts with the payment page (most Shopify/Woo setups with Stripe Elements)
• SAQ B — standalone terminal, no electronic storage
• SAQ B-IP — IP-connected terminal (most modern terminals)
• SAQ C — payment application on internet-connected POS
• SAQ D — the full questionnaire, required when no other SAQ fits or when you store cardholder data

The 2026 practical rule: pick your SAQ based on what JavaScript is on your checkout page, not what you think your architecture looks like. If your page loads any script that touches a payment field, you are SAQ A-EP minimum.

The Biggest Changes in 4.0.1 for Merchants

Version 4.0.1 introduced 64 new requirements, 51 of which became mandatory March 31, 2025. The ones that matter most for high-risk merchants:

• Req 6.4.3 — Payment page scripts must be inventoried, authorized, and integrity-checked (addresses Magecart-style attacks)
• Req 8.3.6 — Passwords must be 12+ characters (was 7), combined complexity OR cryptographic strength equivalent
• Req 8.4.2 — MFA required for all access into the cardholder data environment, not just administrative access
• Req 11.6.1 — Change-and-tamper detection on payment pages (works with 6.4.3)
• Req 12.3.1 — Formal targeted risk analysis required for any 'customized approach' control
• Req 12.10.7 — Incident response procedures for cardholder data detected outside expected storage

Req 6.4.3 and 11.6.1 — The Script Integrity Rules

These two requirements are the 2025-2026 compliance headache. They target Magecart-style skimmer attacks where a third-party script is modified to exfiltrate cardholder data.

What you need to do as a merchant accepting card-not-present payments:

• Inventory every script loaded on pages that include payment fields or redirect to payment
• Justify business need for each script
• Implement integrity checking (Subresource Integrity hashes, or a monitoring vendor like Feroot, Jscrambler, or Human)
• Alert on unauthorized script changes

Merchants fully using iframe/redirect to Authorize.Net Accept Hosted, Stripe Checkout, or NMI Collect.js meet this requirement because the payment fields are hosted by the PCI-compliant processor. Merchants using in-line fields (Stripe Elements on your own page) are responsible for the script integrity controls themselves.

Req 8.4.2 — MFA Everywhere

Old rule: MFA for admin access to the cardholder data environment. New rule: MFA for all access, including user access. If your checkout portal, admin dashboard, or payment integration has any user login that touches card data, MFA is mandatory.

Practical implementation: TOTP (Google Authenticator, Authy), hardware keys (YubiKey), or biometric. SMS MFA is explicitly no longer considered strong enough for PCI purposes.

The Compliance Workflow for High-Risk Merchants

• Annual: Complete the appropriate SAQ and submit attestation to your acquirer
• Quarterly: Run an ASV (Approved Scanning Vendor) vulnerability scan if SAQ A-EP, C, or D (Trustwave, Security Metrics, Control Scan all common)
• Ongoing: Monitor script integrity on payment pages (Req 6.4.3/11.6.1)
• Incident: Document and report any card-data breach within your acquirer's notification window (typically 24-72 hours)

Scope Reduction: The Single Best Compliance Strategy

The cheapest way to comply is to have as little scope as possible. Three patterns reduce scope dramatically:

• Full redirect to hosted payment page — your site hands off to the processor entirely, and card data never touches your servers (SAQ A)
• Tokenization — use a processor-hosted iframe so card data is tokenized before it reaches your code (SAQ A or A-EP)
• Network segmentation — if you must process card data in-house, isolate the environment so the rest of your network is out of scope

Common Misconceptions

• 'My processor is PCI compliant so I am compliant' — false. Your processor's compliance only covers their systems. You are responsible for your own merchant attestation.
• 'I only accept payments over the phone so PCI does not apply' — false. SAQ C-VT or C covers phone-order scenarios. MOTO merchants are in scope.
• 'SAQ A means no work' — false. SAQ A still has 22 requirements and requires annual completion.
• 'I can skip PCI if I use Stripe' — false. Stripe hands you the PCI SAQ responsibility. Use of a compliant processor reduces scope; it does not eliminate it.

What Noncompliance Actually Costs

• Acquirer fines: $5,000-$100,000 per month until remediation
• Breach costs: $50-$150 per exposed card in forensic, legal, and notification costs
• Card network fines: Visa and Mastercard assess $5,000-$50,000 per breach event
• Account termination and MATCH listing (Code 12) for sustained noncompliance

How Cybin Enterprises Helps

Our processing partners are PCI-DSS Level 1 compliant, which means your integration into their hosted pages and tokenization APIs minimizes your own compliance scope. We provide referrals to ASVs and QSAs for merchants who need annual scans and attestation. We also help structure integrations (iframe, redirect, Collect.js) that land you in SAQ A or SAQ A-EP instead of SAQ D. applications processed, 755 industries, 4.9/5 across verified customer reviews.

Related Reading

• How to Open a High-Risk Merchant Account in 2026
• Chargeback Ratios Explained: Thresholds, Fees, and Prevention
• Rolling Reserves Explained: How to Negotiate Them Down