SAQ A vs SAQ A-EP vs SAQ D: Which One Applies to You

What changed for SAQ A in 2025, and why most guides have it wrong

If you are reading an article written before 2025, it is describing a form that no longer exists. The PCI Security Standards Council revised SAQ A on 30 January 2025, effective 31 March 2025, and the change ran in two directions at once.

Read those two halves together, because the combination is what trips people up. The Council took three technical controls off the form and replaced them with an eligibility bar and a signature. You no longer evidence script integrity control by control. Instead you sign a statement that your site is not susceptible to script attacks, and if that statement is wrong, the exposure sits with you rather than with a missing checkbox.

The practical result: SAQ A got shorter, and the pool of merchants entitled to use it got smaller. If you cannot honestly make both attestations, your form is SAQ A-EP.

Basis — PCI Security Standards Council SAQ A revision announced 30 January 2025, effective 31 March 2025. Change detail per SecurityMetrics and Jscrambler assessor commentary, 2025. Requirement 11.3.2 addition to SAQ A dates from PCI DSS v4.0.

Which SAQ applies to you

Four questions, in order. Stop at the first one that sends you somewhere.

The three forms compared

The row that costs real money is penetration testing. SAQ A does not trigger Requirement 11.4. SAQ A-EP does. That single step from A to A-EP adds an annual penetration test, internal scanning, and the script integrity controls that SAQ A merchants no longer evidence. Our PCI DSS penetration testing guide covers what the test has to include, and the cost guide prices every line.

What pushes you from SAQ A to SAQ A-EP

This is where most merchants are wrong about their own status. The trigger is not receiving card data. It is being able to influence the page that collects it.

Rows three and four are where the Magecart risk actually lives. An attacker who injects a script into your page can skim card details before the provider ever sees them, which is precisely why those integrations carry the heavier form. It is also why the 2025 SAQ A revision tightened eligibility rather than loosening it: the Council narrowed SAQ A to the cases where your site genuinely cannot interfere.

Worth checking rather than assuming. Teams routinely file SAQ A on the basis that "we use Stripe" or "we use Adyen", without knowing which integration their developers chose. The provider name tells you nothing. The integration pattern tells you everything.

What pushes you all the way to SAQ D

SAQ D is the default when nothing narrower fits, and merchants land there through routes that have nothing to do with their website:

• A contact centre that takes card details by phone. The single most common cause outside e-commerce, and it drags the whole centre, its agents, its recordings and its network into scope.
• Card numbers in call recordings that nobody realised were being retained.
• PANs in application logs, support tickets or CRM free-text fields. Usually accidental, always in scope.
• Storing card data for recurring billing rather than tokenising it with the provider.
• Being a service provider. Most service providers file SAQ D regardless of how clean the architecture is.
• Mixed channels. E-commerce on SAQ A plus phone orders means the phone channel drags you to SAQ D.

That last one surprises people. Your SAQ is determined by the whole of your card acceptance, not the cleanest part of it. A merchant with an immaculate iframe checkout and one phone line taking orders files SAQ D.

How to move down a tier

The A-EP to A move is the one most teams underestimate the value of. A few days of engineering removes an annual penetration test, internal scanning, and roughly 120 requirements from your form, every year, permanently.

What happens if you file the wrong one

Filing SAQ A when you should have filed A-EP is not a paperwork error. The AoC is a signed attestation by a senior officer that the stated requirements are met. If the eligibility criteria were never satisfied, the attestation was not accurate when signed.

The consequences show up in three places. Your acquirer can reclassify you and demand revalidation. An enterprise customer doing vendor due diligence can reject your AoC once they see the integration does not match the form. And after a breach, a forensic investigator establishes which SAQ applied, and an AoC for the wrong form offers no protection.

The fix is cheap if you do it before any of those: confirm your integration pattern, file the correct form, and if the correct form is more expensive, treat that as the trigger for a descoping project rather than a reason to keep filing the wrong one. Our guide to the PCI DSS Attestation of Compliance covers what the signed document actually commits you to.

Frequently asked questions

What is the difference between SAQ A and SAQ A-EP? SAQ A is for merchants who have fully outsourced card capture, where every payment page element comes directly from the provider. SAQ A-EP is for e-commerce merchants whose own website affects the payment page but never receives card data, such as a JavaScript integration or a form posting directly to the provider. SAQ A has around 31 requirements; SAQ A-EP has around 150 and triggers penetration testing.

Do I need SAQ D if I use Stripe or Adyen? Not necessarily, and the provider name is irrelevant. What matters is the integration. A full redirect or provider-hosted iframe is SAQ A. Their JavaScript library rendering fields into your page is SAQ A-EP. Your server receiving the card number and forwarding it is SAQ D.

What changed for SAQ A in 2025? On 30 January 2025, effective 31 March 2025, the PCI SSC removed Requirements 6.4.3, 11.6.1 and 12.3.1 from the SAQ A form and added two eligibility criteria: all payment page elements must originate only and directly from a compliant provider, and the merchant must confirm its site is not susceptible to script attacks. The form became shorter but harder to qualify for.

Does SAQ A require a penetration test? No. Requirement 11.4 penetration testing does not apply to SAQ A. It does apply to SAQ A-EP and SAQ D. This is the largest cost difference between the forms and the main financial reason to move from A-EP to A.

Does SAQ A require quarterly ASV scans? Yes, under PCI DSS v4. Requirement 11.3.2 was added to SAQ A, which version 3.2.1 did not include. Quarterly external scanning by an Approved Scanning Vendor is required at least every 90 days and after significant changes to internet-facing infrastructure.

Can I file SAQ A for my website and ignore phone orders? No. Your SAQ is determined by all of your card acceptance channels, not the cleanest one. A merchant with a compliant iframe checkout who also takes card details by phone files SAQ D unless the phone channel is descoped, typically with DTMF masking.

Sources