Compliance
A plain-English PCI DSS 4.0.1 guide for small merchants covering how to choose the right SAQ, what changed in the v4.0.1 SAQ set, and where merchants usually scope themselves wrong.
If you are a small merchant, the fastest answer is this: choose your SAQ based on payment flow, not on business size. PCI DSS 4.0.1 did not create new PCI DSS requirements, but the updated SAQ package clarified who belongs in SAQ A, A-EP, and C-VT and where merchants were stretching eligibility too far.
Sources: PCI SSC v4.0.1 blog, PCI SSC SAQ v4.0.1 bulletin, PCI SSC FAQ on SAQ eligibility intent, PCI SSC FAQ on SAQ A vs A-EP, PCI SSC SAQ A update (Jan 2025)
The headline is simpler than many merchants expect.
PCI SSC says PCI DSS 4.0.1 is a limited revision. It does not add or delete PCI DSS requirements, and it did not change the March 31, 2025 effective date for the future-dated PCI DSS v4 requirements. The point of v4.0.1 was clarification, cleanup, and alignment.
The SAQ package changed more than the standard itself from a merchant point of view. PCI SSC's October 2024 bulletin aligned the v4.0.1 SAQs to the standard, clarified eligibility criteria in SAQs A, A-EP, and C-VT, and updated completion guidance in SAQs A and A-EP.
The SAQ A story is the one to watch. The October 2024 update briefly added two payment-page-security requirements (6.4.3 and 11.6.1) to SAQ A. PCI SSC then reversed course in January 2025: it removed 6.4.3, 11.6.1, and 12.3.1 from SAQ A and replaced them with a new eligibility criterion — the merchant must confirm its payment page is not susceptible to script-based attacks. That January 2025 SAQ A is the version that took effect on March 31, 2025, so it is the one in force today.
So if you are asking "what changed for me," the answer is usually about SAQ selection and evidence, not a brand-new control family.
Do not start with "we are a small business."
Start with "how does the card data move?"
PCI SSC's FAQ on SAQ eligibility is explicit: each SAQ exists for a specific environment type, and merchants must meet all eligibility criteria for that SAQ. If the environment contains other system types beyond what the SAQ allows, the merchant is probably in the wrong bucket.
That is the part many merchants miss. SAQs are not convenience tiers. They are scoped validation tools.
Here is the plain-English version for the SAQs most small merchants run into.
Usually the right fit when all payment page elements delivered to the customer's browser come only and directly from a PCI DSS validated third-party service provider.
PCI SSC's A versus A-EP FAQ uses redirect and iframe-style outsourced payment flows as the clear contrast case. If your site does not serve the payment page elements itself, SAQ A may fit.
Usually the right fit when your website still affects the payment page delivered to the browser. PCI SSC says A-EP applies when each element of the payment page originates from either the merchant website or a PCI compliant service provider.
This is where many ecommerce merchants scope themselves wrong. If your site hosts part of the payment experience, you are not in the simplest bucket anymore.
PCI SSC says SAQ B-IP is intended for environments using only PTS-approved point-of-interaction devices, excluding SCRs, in a tightly limited environment. This is the common "standalone terminal only" lane for some small merchants.
This is for merchants using only a web-based virtual terminal on a personal computer. The v4.0.1 SAQ update specifically clarified eligibility here because merchants have a habit of adding adjacent functions and drifting out of scope without realizing it.
PCI SSC says SAQ C is intended for merchants using only payment application systems, such as point-of-sale systems, connected to the internet, in the specific limited environment the SAQ describes.
If your environment does not cleanly meet the criteria for one of the narrower SAQs, this is usually the answer. It is the catch-all when the environment is more complex, more connected, or more custom than the easy SAQs allow.
This is the comparison most small online merchants actually need.
PCI SSC's FAQ draws the line this way:
That is not a small distinction. It changes scope because the merchant site itself becomes part of the trust boundary for the payment experience.
If your checkout page is styled, scripted, or assembled in ways that mean your own site is serving part of what the customer uses to enter payment data, assume A-EP until proven otherwise.
Three mistakes show up over and over:
Not necessarily. A processor relationship alone does not decide the SAQ. The browser-side delivery model matters.
PCI SSC's FAQ on eligibility intent says the permitted system type must not be connected to other system types unless segmentation properly isolates it. Small and flat is still flat.
No. PCI SSC says merchants should confirm SAQ eligibility with the receiving entity before they start. Usually that means your acquirer or payment brand compliance program.
If you are trying to get unstuck quickly, do this in order:
This is the same discipline we push in cyber insurance questionnaire 2026: 22 controls: do not answer the easy version of the question if your environment is more complicated than that.
It did not make sloppy environments acceptable.
PCI SSC was clear that v4.0.1 is a limited revision. The risk for a small merchant is still the same old one: weak scoping, mixed-use systems, poor segmentation, and vague ownership of the payment environment.
That is also why even small merchants increasingly need real endpoint and identity discipline around the business systems connected to payment operations. The same practical baseline discussed in what controls cyber insurers require in 2026 matters here too, especially around MFA, logging, and hardened endpoints.
For merchants, the useful work is usually scoping the payment environment, hardening the systems around it, and making the evidence less embarrassing. If the payment lane sits on a workstation or network nobody is truly watching, the compliance story gets thin fast.
That is where managed detection and response, managed ITDR, and pricing become relevant operationally. They do not choose your SAQ for you. They help keep the surrounding environment from undermining the answer.
No. PCI SSC says v4.0.1 is a limited revision with no new or deleted requirements.
The October 2024 SAQ release clarified eligibility for SAQs A, A-EP, and C-VT and updated completion guidance in SAQs A and A-EP. Then PCI SSC revised SAQ A in January 2025 — removing requirements 6.4.3, 11.6.1, and 12.3.1 and adding an eligibility criterion that the merchant confirm its payment page is not susceptible to script-based attacks. That January 2025 SAQ A is the version effective March 31, 2025.
Yes. Size does not control the answer. If the merchant website serves payment page elements, PCI SSC's own FAQ points toward A-EP rather than A.
Sometimes, yes. PCI SSC says segmentation can isolate the permitted system type from other systems, but the environment still has to meet all eligibility criteria for that SAQ.
Ask the entity you submit to, usually your acquirer. PCI SSC specifically recommends confirming eligibility there before starting the self-assessment.
Last updated
June 16, 2026. We refresh this content as the threat landscape and tools evolve.
FAQ
Your SAQ depends on how cardholder data flows through your environment. The key questions are whether your website serves payment page elements, whether you only use standalone terminals, whether you key cards into a web-based virtual terminal, and whether any other systems touch payment data.
No. PCI SSC says v4.0.1 is a limited revision with no new or deleted requirements. It clarifies formatting, intent, and guidance, and it did not change the effective date for the new PCI DSS v4 requirements.
The October 2024 SAQ update aligned content to PCI DSS v4.0.1, clarified eligibility in SAQs A, A-EP, and C-VT, and updated completion guidance in A and A-EP. The change that matters most since: PCI SSC revised SAQ A in January 2025, removing requirements 6.4.3, 11.6.1, and 12.3.1 and adding an eligibility criterion that the merchant confirm its payment page is not susceptible to script-based attacks. That January 2025 SAQ A is the version effective March 31, 2025.
PCI SSC says merchants should confirm SAQ eligibility with the entity they submit to, usually the acquirer or payment brand program, before starting the assessment.
Then you should assume you are not in the easy bucket. Mixed environments, custom payment flows, and systems connected to other business systems often push merchants into a broader SAQ or a more involved assessment.
Related reading
A plain-English CMMC guide for small defense contractors covering what Level 2 means in 2026, what actually drives cost, how the rollout works, and the steps to get ready.
Read articleA plain-English guide for defense contractors on how the NIST SP 800-171 self-assessment score works, what SPRS actually stores, and how to close the gaps that keep the score low.
Read articleA plain-English guide to North Carolina's data breach notification law for small businesses, including who must notify, what the notice must say, when to contact the Attorney General, and when consumer reporting agencies must be told.
Read article