SAQ Requirements Mapping

The rule that governs this page

Each SAQ contains only the PCI DSS requirements that apply to that environment. The Instructions and Guidelines word it the same way for every SAQ except SAQ D: the questionnaire "includes only those PCI DSS requirements applicable to" merchants of that type.

Only one merchant 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 webpage, which the TPSP hosts and manages entirely	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

The table and its counts follow the table of e-commerce methods in the Council's SAQ Instructions and Guidelines (v4.0.1 r1, April 2025). 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 any element of the payment page comes from your own site, such as a form it creates or a script it loads, SAQ A stops applying and SAQ A-EP may apply instead, with far more requirements to meet.

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, but the SAQ A update of 30 January 2025 removed both from SAQ A and added the script eligibility criterion set out below. Check the current SAQ A document rather than a secondary source.

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

The second of these applies only if your page embeds the provider's payment page or form, for example in an iframe. The Council's FAQ 1588 says it does not apply to a redirect or to fully outsourced payment. You can confirm it by protecting your page with techniques such as those in 6.4.3 and 11.6.1, or by getting your provider's confirmation that its solution, implemented as instructed, protects your page from script attacks. Redirect and iframe merchants alike carry the quarterly ASV scans in 11.3.2 (FAQ 1604), and the external scans after any significant change in 11.3.2.1, which need not be run by an ASV.

Where to start. This site carries written guidance for the controls the SAQ wizard lists as evidence for SAQ A: 3.2.1 (retention and disposal), 11.3.2 (external scans), 12.8.2 (written agreements with your providers), 12.8.4 (checking their compliance status at least once every 12 months) and 12.10.1 (incident response). That is a starting point, not the questionnaire's full control set. For an iframe merchant confirming the script criterion itself, 6.4.3 (payment page scripts) and 11.6.1 (change and tamper detection) describe the techniques FAQ 1588 points to.

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
• You have confirmed the TPSP is PCI DSS compliant for the services you use
• Any account data you retain is on paper, not received electronically

None of these is about scripts. 6.4.3 and 11.6.1 are requirements inside SAQ A-EP: a merchant who has not yet put them in place is an A-EP merchant with work to do, not a merchant who needs SAQ D.

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 6.4.3 and 11.6.1 (payment page scripts and change detection, here as requirements rather than a route to a criterion), 4.2.1 (strong cryptography in transit) 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 and/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.

• The only payment processing is through a virtual payment terminal accessed by an internet-connected web browser
• The virtual payment terminal solution is provided and hosted by a PCI DSS compliant TPSP
• You reach it only from a computing device isolated in a single location and not connected to other locations or systems, which a firewall or network segmentation can achieve
• That device has no software installed that causes account data to be stored, such as batch processing or store-and-forward
• That device has no attached hardware used to capture or store account data, such as a card reader
• You do not otherwise receive, transmit or store account data electronically through any channel
• Any retained account data is on paper, not received electronically

SAQ C: payment application systems connected to the internet

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

• You have a payment application system and an internet connection on the same device and/or the same local area network (LAN)
• The payment application system is not connected to any other system in your environment, which network segmentation can achieve
• The physical location of the POS environment is not connected to other premises or locations, and any LAN is for a single store only
• You do not store account data electronically
• Any retained account data is on paper, not received electronically

SAQ P2PE: payment terminals in a PCI-listed P2PE solution only

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

• All payment processing is through a validated, PCI-listed P2PE solution
• The only systems in your environment that store, process or transmit account data are the payment terminals from that solution
• You do not otherwise receive, transmit or store account data electronically
• Any retained account data is on paper, not received electronically
• You have put in place every control in the P2PE Instruction Manual (PIM) from the P2PE solution provider

SAQ SPoC: a PCI-listed SCRP with a phone or tablet in a validated SPoC solution

Attended card-present only. Not applicable to unattended card-present (such as kiosks or self-checkout), mail/telephone-order or e-commerce channels, or to service providers.

• All payment processing is through a card-present channel only
• All cardholder data entry is through an SCRP that is part of a validated SPoC solution listed by PCI SSC
• The only systems in your SPoC environment that store, process or transmit account data are those in that validated solution
• You do not otherwise receive, transmit or store account data electronically
• This payment channel is not connected to any other systems or networks in your environment
• Any retained account data is on paper, not received electronically
• You have put in place every control in the SPoC user guide from the SPoC solution provider

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.