PCI DSS 4.0 Compliance for Small Business: SAQs and Checklist

PCI DSS 4.0 compliance stopped being optional homework on March 31, 2025. That is when the 51 future-dated requirements in version 4.0 of the Payment Card Industry Data Security Standard became mandatory, and they apply to every merchant that takes cards, from a one-terminal shop to a small online store.

This guide explains what changed in v4.0 and v4.0.1, which self-assessment questionnaire (SAQ) fits your setup, when quarterly scans apply and how to shrink your scope. If you want help running the readiness work, our IT governance, risk and compliance service covers gap analysis, policies and evidence collection for PCI DSS. This is general information, not legal advice; confirm specifics with your acquirer or assessor.

Where this guidance comes from. We used the PCI Security Standards Council’s v4.0 SAQ documents, its blog announcements on v4.0.1 and the 2025 SAQ A revision, FAQ 1588 and its 2025 e-skimming guidance, plus Visa and Mastercard’s compliance pages. The practical advice reflects our team’s field experience helping small organizations prepare evidence and reduce scope.

What PCI DSS 4.0 compliance means for a small merchant

PCI DSS applies to any business that stores, processes or transmits cardholder data, or can affect the security of the systems that do. The Council writes the standard, but it does not decide what you must file and it does not fine anyone.

Those decisions sit with the card brands and your acquirer, the bank or processor that settles your card sales. The Council’s merchant resources page says each brand runs its own compliance program and decides whether a small merchant must validate. In practice, your acquirer asks for your SAQ and its merchant agreement spells out the fees if you do not provide it.

What changed from v3.2.1 to v4.0 and v4.0.1

Version 4.0 was published in March 2022, and v3.2.1 retired on March 31, 2024. The Council’s March 2025 e-commerce guidance notes that v4.0 added 64 new requirements, 51 of them future-dated until March 31, 2025.

Version 4.0.1 followed on June 11, 2024. Its announcement says it fixed errors and clarified intent, added or deleted no requirements, and did not move the 2025 deadline. As of October 2026, check the Council’s document library before each assessment for any newer revision.

The March 31, 2025 requirements small merchants notice most

Not every new requirement is in every SAQ. A merchant on SAQ B sees almost no change, while SAQ D includes all of them. This table uses requirement text from the Council’s SAQ D for Merchants and our check of which v4.0 SAQs include each one.

Requirement	What it asks for	Appears in
8.4.2	MFA for all access into the cardholder data environment (CDE).	SAQ A-EP, C, D
6.4.3	Every payment page script authorized, integrity-checked and inventoried with a written justification.	SAQ A-EP, D
11.6.1	Tamper detection on payment page content and HTTP headers, at least weekly or per a risk analysis.	SAQ A-EP, D
12.3.1	Written targeted risk analysis for any control frequency you set yourself, reviewed yearly.	SAQ A-EP, C, D
8.3.6	Passwords of at least 12 characters (8 if unsupported), letters and numbers.	Most SAQs
5.4.1	Automated mechanisms to detect and protect staff against phishing.	SAQ A-EP, C-VT, C, D

MFA for all access into the CDE

Version 3.2.1 required MFA for remote and administrative access. Requirement 8.4.2 extends it to all access into the CDE, with exemptions for POS cashier IDs that handle one card at a time and automated system accounts. Our identity and access security team rolls out MFA and cleans up accounts like these.

Payment page scripts and tamper detection

Requirements 6.4.3 and 11.6.1 target e-skimming, where attackers inject code into a checkout page to copy card numbers. The Council’s payment page security supplement, published March 10, 2025, says these attacks have increased significantly. You need a script inventory with a reason for each script, a way to confirm each is authorized and unaltered, and alerts for unauthorized changes.

Targeted risk analyses

Where you choose how often to perform a control, Requirement 12.3.1 asks for a written analysis naming the assets, threats, likelihood factors and resulting frequency, reviewed at least every 12 months. For a small merchant this can be a short document, but it has to exist.

Not sure which of these applies to you? We can map your payment channels, recommend an SAQ and build a remediation list before your acquirer’s deadline. Request PCI readiness help online, or book a consultation online to talk it through.

Merchant levels: who sets them

Merchant levels are set by each card brand, not by PCI DSS. Visa’s security compliance page says your 12-month Visa volume determines your level and that acquirers must make sure merchants validate correctly. As of October 2026, Mastercard’s Site Data Protection page lists these levels:

• Level 1: over six million transactions a year; annual Report on Compliance.
• Level 2: over one million up to six million; annual SAQ.
• Level 3: over 20,000 e-commerce transactions, up to one million total; annual SAQ.
• Level 4: all others; must comply, but validation to Mastercard is not required unless law requires it.

Most small businesses are Level 4. Your acquirer can still require an annual SAQ and scan reports, and some processors charge a monthly fee until you submit them. Ask your acquirer in writing what it needs.

How to choose the right SAQ for PCI DSS 4.0 compliance

Your SAQ depends on how card data flows, not on revenue. The Council’s overview of the v4 SAQs notes that your acquirer or the payment brands decide which SAQ you use. The table summarizes the eligibility criteria in the v4.0 SAQ documents.

SAQ	Eligibility (summarized)	Typical fit
SAQ A	Card-not-present only; all card handling outsourced; every payment page element comes from a compliant provider.	Redirect or hosted iframe checkout
SAQ A-EP	E-commerce only; your site does not receive card data but controls or serves part of the payment page.	Direct post or JavaScript payment forms
SAQ B	Imprint machines or standalone dial-out terminals not connected to the internet.	Analog phone-line terminals
SAQ B-IP	Standalone PCI-approved terminals connected by IP to the processor, isolated from other systems.	Countertop terminal on its own network
SAQ C-VT	One-at-a-time keyed entry into a hosted virtual terminal on an isolated computer.	Keying phone orders in a browser
SAQ C	Internet-connected POS or payment application, single location, no electronic card storage.	Single-store POS
SAQ P2PE	Only terminals from a validated, PCI-listed P2PE solution, following its instruction manual.	Encrypting terminals, smallest card-present scope
SAQ D	Any eligible merchant that fits no other SAQ.	Card data on your servers or stored electronically

If you take payments through several channels, each must meet its SAQ’s criteria, and your acquirer may want one SAQ per channel. If any system stores full card numbers electronically, plan on SAQ D. The Council also added SAQ SPoC in September 2023 for phones or tablets used with a secure card reader in a validated SPoC solution.

The SAQ A change e-commerce merchants miss

On January 30, 2025, the Council announced a revised SAQ A, effective March 31, 2025. It removed Requirements 6.4.3, 11.6.1 and 12.3.1, but added an eligibility criterion: you must confirm your site is not susceptible to attacks from scripts that could affect your e-commerce systems.

FAQ 1588, covered in the Council’s February 28, 2025 post, says you can meet it by applying the 6.4.3 and 11.6.1 techniques yourself or by getting confirmation from your compliant provider that its embedded payment form includes those protections. If your checkout uses an iframe, get that confirmation in writing and keep it with your SAQ.

Quarterly ASV scans and penetration testing

Requirement 11.3.2 calls for external vulnerability scans at least every three months by a PCI SSC Approved Scanning Vendor, with rescans until they pass. The v4.0 SAQ A explains that your first assessment does not need four passing scans if the latest passed and you have a documented quarterly process; after that, every quarter counts.

SAQ A-EP and D also require external penetration testing at least every 12 months and after significant changes (Requirement 11.4.3). Our article on penetration testing vs vulnerability scanning explains the difference, and our penetration testing team performs scoped testing with a prioritized remediation roadmap. We are not an ASV; we help you prepare for scans and fix what they find.

Reduce your scope before you try to comply

Every system that touches card data, or can affect the systems that do, is in scope. Moving card data off your systems shrinks both the SAQ and the work behind PCI DSS 4.0 compliance.

• Hosted payment pages. A redirect or provider-hosted iframe can move an online store toward SAQ A.
• Validated P2PE. Terminals from a solution on the Council’s validated P2PE list encrypt card data at the tap or swipe.
• Tokenization. Keeping a processor token instead of the card number for recurring billing keeps card numbers off your systems.
• Segmentation. SAQ B-IP and C depend on isolating payment devices. Our managed network infrastructure service handles that firewall and switch design with documentation.
• Stop collecting card data. Card numbers on paper forms, in email or in spreadsheets drag systems into scope.

Consider a hypothetical: a small contractor keys phone payments into a virtual terminal on a shared office PC also used for email. That PC is not isolated, so SAQ C-VT does not fit. A dedicated device or P2PE terminals could restore a much smaller scope.

Small-merchant PCI DSS 4.0 compliance checklist

1. Ask your acquirer, in writing, for your merchant level, expected SAQ and due date.
2. Diagram every way you accept cards: website, terminals, phone, mail and recurring billing.
3. Find and remove card data you do not need.
4. Collect a current Attestation of Compliance from each provider that touches card data.
5. Check your SAQ against the current eligibility criteria.
6. Turn on MFA for access into the CDE and set 12-character minimum passwords.
7. For e-commerce, inventory payment page scripts or get your iframe provider’s written confirmation.
8. Schedule quarterly ASV scans if your SAQ requires them and keep passing reports.
9. Write targeted risk analyses for self-set frequencies and calendar the yearly review.
10. Train staff on phishing and terminal tampering, and write a short incident response plan.
11. Complete, sign and submit the SAQ and Attestation of Compliance as your acquirer specifies.

If you suspect a tampered terminal or card fraud traced to your business, see our guide to data breach response for small business. To gauge your basic controls first, take our free cyber risk check.

PCI penalties come from acquirers and brands

The Council does not issue fines for gaps in PCI DSS 4.0 compliance. Visa’s compliance page says that if a merchant does not comply or fix a security issue, Visa may assess a non-compliance assessment to the issuer or acquirer. The acquirer then applies your merchant agreement, which may include monthly fees, required remediation or termination of card acceptance. Amounts are set in private rules and contracts, so read your agreement’s PCI section.

How Honeybadger Solutions helps with PCI DSS 4.0 compliance

We are a veteran-owned firm based in Casa Grande, Arizona, delivering compliance, cyber and IT services nationwide. For PCI work, our governance team runs a gap analysis against your SAQ, writes policies and risk analyses in plain language, builds an evidence repository and works with your assessor or acquirer on evidence requests. We prepare you for validation; we are not your assessor.

Our penetration testing, network and identity teams handle the technical fixes. Financial organizations can pair this with our banking and financial security services for branch and operations-center protection.

Submit a service request online with how you accept cards and which SAQ your acquirer requested, or book a consultation if you would rather talk first.

Why the online intake is faster than a phone call: it takes about two minutes, and your answers are routed straight to the specialist team that handles your kind of matter, whether that is cyber and forensics, investigations or field security. That team sees the full picture before it replies, so you skip phone tag and get a real answer and next steps sooner. If it cannot wait for business hours, use the urgent intake form, which is read seven days a week.

Frequently asked questions

Is PCI DSS 4.0 compliance mandatory for a small business?

If you accept card payments, the card brands expect you to comply, and your merchant agreement usually makes it a contract term. What varies by size is validation. Mastercard says Level 4 merchants must comply but need not validate to Mastercard unless law requires it, yet your acquirer can still require an SAQ.

What changed on March 31, 2025?

The 51 future-dated requirements in PCI DSS v4.0 stopped being best practices and became mandatory. For small merchants the most visible are MFA for all access into the cardholder data environment, payment page script and tamper controls, targeted risk analyses and 12-character passwords, where your SAQ includes them.

Which SAQ should a small online store use?

If every element of your payment page comes from a PCI DSS compliant provider through a redirect or iframe, SAQ A is usually the target, plus the script-attack confirmation added in January 2025. If your own site serves or controls the payment page, expect SAQ A-EP. If card data touches your server, expect SAQ D.

Do I need quarterly ASV scans?

Requirement 11.3.2 requires external scans at least every three months by a PCI SSC Approved Scanning Vendor, with rescans until they pass. In the v4.0 questionnaires it appears in SAQ A, A-EP, B-IP, C and D, but not in B, C-VT or P2PE.

Who issues PCI penalties?

Not the PCI Security Standards Council. Card brands enforce their programs through acquirers. Visa says it may assess a non-compliance assessment to the issuer or acquirer, and acquirers pass consequences to merchants under the merchant agreement.

Does using a payment processor make me compliant automatically?

No. A compliant processor can shrink your scope, but you still file the SAQ your acquirer requires, review the provider’s Attestation of Compliance, and manage your own accounts, paper records, scans and script controls.

Related reading

• ▸ Cyber Insurance Requirements: Controls Underwriters Check
• ▸ Phishing-Resistant MFA: A Business Guide to Stopping MFA Bypass
• ▸ Penetration Testing Cost: What Drives Price and Scope
• ▸ Microsoft 365 Security Checklist for Small Businesses (2026)