PCI DSS 4.0.1 for small merchants: which SAQ you need and what changed

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)

What changed in PCI DSS 4.0.1

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.

The decision rule most merchants need

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.

Which SAQ you usually need

Here is the plain-English version for the SAQs most small merchants run into.

SAQ A

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.

SAQ A-EP

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.

SAQ B-IP

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.

SAQ C-VT

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.

SAQ C

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.

SAQ D

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.

The easiest way to tell A from A-EP

This is the comparison most small online merchants actually need.

PCI SSC's FAQ draws the line this way:

• SAQ A: all payment page elements come only and directly from the PCI validated third party
• SAQ A-EP: some payment page elements come from the merchant website

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.

Where small merchants usually get this wrong

Three mistakes show up over and over:

"Our processor handles payments, so we must be SAQ A."

Not necessarily. A processor relationship alone does not decide the SAQ. The browser-side delivery model matters.

"The POS network is tiny, so it does not matter what else is on it."

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.

"We can just choose the shortest SAQ."

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.

What to do this week

If you are trying to get unstuck quickly, do this in order:

1. Draw the payment flow from the customer's browser or payment terminal to the processor.
2. Identify whether your site serves any payment page elements.
3. Identify whether the payment environment is isolated from other systems.
4. Match the environment to the SAQ intent, not the marketing label on your payment tool.
5. Confirm the result with your acquirer before filling anything out.

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.

What PCI DSS 4.0.1 did not change

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.

Where Obsidian Ridge fits

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.

FAQ

Did PCI DSS 4.0.1 create new requirements for merchants?

No. PCI SSC says v4.0.1 is a limited revision with no new or deleted requirements.

What changed in the SAQ package?

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.

Can a very small ecommerce merchant still need SAQ A-EP?

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.

Can network segmentation preserve eligibility for a narrower SAQ?

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.

Who should I ask before I submit the SAQ?

Ask the entity you submit to, usually your acquirer. PCI SSC specifically recommends confirming eligibility there before starting the self-assessment.