SAQ Requirements Mapping

The rule that governs this page

Each SAQ contains only the PCI DSS requirements that apply to that environment. The standard's own wording, repeated for every SAQ in the Instructions and Guidelines, is that the questionnaire "includes only those PCI DSS requirements applicable to" merchants of that type.

Only one SAQ covers the whole standard: SAQ D for Merchants, which is where you land if no other SAQ fits.

This matters more than any other fact on this page. A fully outsourced e-commerce merchant using a redirect faces 27 requirements, not the full set. Being told otherwise is the difference between a manageable piece of work and an unnecessary consulting engagement.

E-commerce: how many requirements you actually face

E-commerce method	SAQ	PCI DSS v4.x requirements
Fully outsourced. You have no access to your own payment webpage	SAQ A	14
Fully outsourced. Your webpage redirects the customer to a compliant TPSP (a URL redirect)	SAQ A	27
Fully outsourced. Your webpage embeds a compliant TPSP's payment page or form (an iframe)	SAQ A	27
Fully outsourced except the payment page. Your site creates the payment form and data goes straight from the browser to the TPSP ("Direct Post")	SAQ A-EP	139
Fully outsourced except the payment page. Your site loads or delivers a script that runs in the customer's browser	SAQ A-EP	139
Anything else	SAQ D for Merchants	All of them

For the three SAQ A rows, the applicable requirements are identified by explanatory notes inside the SAQ A document itself. The 139 for A-EP is the count in the SAQ A-EP document. Both are published by the PCI Security Standards Council and are not reproduced here, so a figure you intend to size a programme on should be confirmed against the questionnaire you are actually filling in.

The jump from 27 to 139 is the single most consequential decision in an e-commerce PCI scope: the moment your own site touches the payment form or ships a script into the payment page, you move from SAQ A to SAQ A-EP and the work multiplies by five.

Not sure which row you are? Use the SAQ wizard.

What changed for SAQ A in v4.x

SAQ A gained controls aimed at e-commerce skimming attacks, specifically to protect pages that redirect to a TPSP or embed a TPSP's payment form. The Instructions and Guidelines highlights 11.3.2 and 11.3.2.1 (external vulnerability scanning) as added for that reason, and is explicit that this is not the complete list of new requirements in SAQ A.

Worth knowing if you have read older guidance: revision r1 of the v4.0.1 Instructions and Guidelines (April 2025) removed 6.4.3 and 11.6.1 from that highlighted list. Those two payment-page script controls are widely quoted as SAQ A additions. Check the current SAQ A document rather than a secondary source before assuming either is in your scope.

Eligibility criteria by SAQ

An SAQ is only valid if you meet every criterion for it.

SAQ A: card-not-present, all account data functions fully outsourced

Applies to e-commerce or mail/telephone-order merchants. Not applicable to face-to-face channels or to service providers.

• You accept only card-not-present (e-commerce or mail/telephone-order) transactions
• All processing of account data is entirely outsourced to a PCI DSS compliant TPSP or payment processor
• You do not electronically store, process or transmit any account data on your systems or premises
• You have confirmed the TPSP is PCI DSS compliant for the services you use
• Any account data you retain is on paper, and those documents are not received electronically

For e-commerce channels, additionally:

• All elements of the payment page or form delivered to the customer's browser originate only and directly from a compliant TPSP
• You have confirmed your site is not susceptible to attacks from scripts that could affect your e-commerce systems

Where to start. This site carries written guidance for the controls a SAQ A merchant is most often asked to evidence: 3.2.1 (retention and disposal), 6.4.3 (payment page scripts), 11.6.1 (change and tamper detection), 12.6.1 (security awareness), 12.8.2 (written agreements with your providers) and 12.10.1 (incident response). That is a starting point, not the questionnaire's full control set.

SAQ A-EP: partially outsourced e-commerce using a third-party payment website

Applies only to e-commerce channels. Not applicable to service providers.

• You accept only e-commerce transactions
• All processing of account data, except the payment page, is entirely outsourced to a compliant TPSP
• Your website does not receive account data but controls how customers or their data are redirected to a compliant TPSP
• If a TPSP hosts your website, that TPSP is compliant with all applicable requirements
• Each element of the payment page originates from either your website or a compliant TPSP
• You do not electronically store, process or transmit account data on your systems or premises
• Any account data you retain is on paper, not received electronically

Note that for SAQ A-EP, requirements referring to the "cardholder data environment" apply to your website, because the site directly affects how account data is transmitted even though it never receives it.

Where to start. A-EP adds the controls that come with owning the page the customer types into. Beyond the SAQ A set above, the ones this site covers are 4.2.1 (strong cryptography in transit), 11.3.2 (external vulnerability scans by an ASV) and 6.3.3 (patching known vulnerabilities). At 139 requirements against SAQ A's 14 or 27, the gap between the two is the single largest cost decision on this page.

SAQ B: imprint machines or standalone dial-out terminals only

Card-present or mail/telephone-order. Not applicable to e-commerce or to service providers.

• You use only an imprint machine, or only standalone dial-out terminals connected by phone line to your processor
• Those terminals are not connected to any other system in your environment
• Those terminals are not connected to the internet
• You do not store account data electronically
• Any retained account data is on paper, not received electronically

SAQ B-IP: standalone PCI-listed PTS POI devices

Card-present or mail/telephone-order. Not applicable to e-commerce or to service providers. Merchants using Secure Card Readers (SCR) or SCRPs are not eligible.

• You use only standalone, PCI-listed approved PTS POI devices connected by IP to your processor
• Those devices are validated to the PTS POI program on the PCI SSC website
• Those devices are not connected to any other system in your environment, which segmentation can achieve
• The only transmission of account data is from the approved device to the processor
• The device does not rely on any other device (computer, phone, tablet) to reach the processor
• You do not store account data electronically
• Any retained account data is on paper, not received electronically

SAQ C-VT: web-based third-party virtual payment terminal

Card-present or mail/telephone-order. Not applicable to e-commerce or to service providers.

A virtual terminal is a third-party solution where staff key account data into a browser on an isolated device. It does not read a card directly. This SAQ is intended only for entering a single transaction at a time by keyboard.

SAQ C: payment application systems connected to the internet

Not applicable to e-commerce channels.

SAQ D

SAQ D for Merchants covers all PCI DSS requirements and applies to any SAQ-eligible merchant who does not qualify for one of the SAQs above. SAQ D for Service Providers applies to service providers defined as SAQ-eligible by a payment brand.

Where the definitive list lives

This page tells you which SAQ applies and roughly how much work that implies. It does not reproduce the requirement list for each SAQ, because that list is defined inside each SAQ document, and for SAQ A it is carried in explanatory notes against individual requirements rather than as a table.

Download the SAQ that applies to you from the PCI Security Standards Council document library and work from it. Your acquirer may also specify which SAQ they will accept, and that instruction takes precedence over any tool, including this one.

Source

Eligibility criteria, requirement counts and the SAQ descriptions on this page are drawn from PCI DSS Self-Assessment Questionnaire Instructions and Guidelines, v4.0.1 r1 (April 2025), ©2006-2025 PCI Security Standards Council, LLC. All rights reserved. The explanatory commentary is our own.

PCI DSS is a registered standard of the PCI Security Standards Council, LLC, which does not endorse this site. Nothing here is a substitute for advice from a Qualified Security Assessor or from your acquirer.