PCI Compliance: Which SAQ is right for me?

Mike Chandler, Head of Practice, Governance and Security Strategy, UK
June, 2015
11 mins read

SAQs come in a number of formats so choosing the right one is critical. Incorrect submissions could invalidate your compliance and expose your organization to greater risk of payment card data breaches. This short article discusses the various options, so you can make an informed decision.

To assist merchants and service providers in validating compliance with the PCI DSS, a number of Self-Assessment Questionnaires (SAQs) are available - each applicable to a specific payment scenario. Depending on the volumes of card data transacted, validation can be by self-assessment and the relevant SAQ documentation, rather than formal audit.

The completed SAQ is delivered along with a signed Attestation of Compliance (AoC) by an officer of the company responsible for compliance (usually the Chief Financial Officer or equivalent). For merchants, the SAQ and AoC are delivered to their acquirer(s) - service providers submit SAQs to the appropriate card brands (Visa, Mastercard, American Express, JCB, and Discover).

There are various types of SAQ available and they were recently enhanced after the PCI DSS version 3.0/3.1 releases:

1. SAQ A

SAQ A applies to card-not-present merchants (e-commerce or mail/telephone order) who have outsourced all cardholder data processing functions and have no electronic storage, processing, or transmitting of cardholder data.

The service providers managing cardholder data on behalf of the merchant must also be validated as PCI compliant, otherwise their environment must also be assessed as part of the merchant’s compliance program.

Entirely outsourcing all cardholder data functions does not mean a merchant doesn’t have to be PCI compliant, as cardholder data is still being processed (by a third-party) using their merchant ID. However, the requirements the merchant must comply with are minimal.

Completing and maintaining SAQ A is a fairly trivial exercise for merchants and the requirements address two key areas. Firstly, any paper copies of cardholder data (such as merchant copy receipts or reconciliation reports) must be physically protected or destroyed. Secondly, a list of service providers should be maintained and their compliance status monitored.

This type of SAQ wouldn’t be applicable for face-to-face channels.


This is one of the newer additions to the SAQ types, designed to apply to e-commerce merchants who partially outsource all payment processing to PCI DSS compliant service providers. The merchant will typically have a website that redirects consumer users to a payment processor at point of payment, but the web server itself doesn’t electronically store, process, or transmit card data. However, the manner in which the consumer is redirected to the payment processor and where the payment page components are provisioned from, will dictate whether SAQ A or A-EP would be the most suitable. Many merchants who previously used SAQ A now fall under SAQ A-EP for validation.

In summary, if all elements of the payment form originate from the payment processor (e.g. a straight redirect or iFrame), SAQ A can be used. For other methods, such as direct post (browser API/silent order post), JavaScript created forms, or if the website itself collects the payment data and sends it to the payment processor, SAQ A-EP should be used.

This SAQ type is only applicable to e-commerce channels.

3. SAQ B

SAQ B applies to merchants with no electronic cardholder data storage, who process payments either by standalone terminals or imprint-only machines.

Modern payment terminals are often referred to as PEDs (pin-entry devices) or previously as PDQs (Process Data Quickly terminals). These terminals rarely rely on direct dial-up connections anymore and can have multiple connection types, such as Bluetooth, Ethernet, and GSM/LTE.

Meeting the eligibility criteria can seem difficult but the acquirers we’ve worked with were happy to accept a completed SAQ B for terminals that connect via these means, as long as they’re isolated from other network components.

Imprint machines (affectionately referred to as knuckle busters by those who use them) are still in place in some bricks-and-mortar merchant premises, though they are increasingly falling out of use. It’s extremely rare for a merchant to use imprint-only machines as the sole method of taking payments.

This SAQ type isn’t applicable to e-commerce channels.


Another new addition to the SAQ types, used for merchants who process payments via standalone PTS-approved point-of-interaction (POI) devices with an IP connection to the payment processor. This type of transaction can apply to brick-and-mortar (card present) or mail/telephone order (card-not-present) merchants, but there’s no electronic storage of card data. The POI devices should be isolated from any other systems and the only retention of card data is on paper merchant receipts.

This SAQ type is not applicable to e-commerce channels.


SAQ C-VT was developed for a specific environment and contains some subtle differences to SAQ C. The VT stands for virtual terminals and applies to externally hosted web payment solutions for merchants with no electronic cardholder data storage.

This service is offered by a number of payment processers and acquirers, and is most commonly used by call center agents entering details manually. A key part of this SAQ is that it applies to environments where operators enter a single transaction at a time.

SAQ C-VT is also often applied mistakenly. While it has a very clear purpose, merchants often find it difficult to meet the validation criteria. This is because the terminals used to enter payments must be isolated in a single location and not connected to other systems in your environment. The most common implementation is via thin-client terminals or individual systems with dedicated Internet access and host-based firewall restrictions.

This SAQ type isn’t applicable to e-commerce channels.

6. SAQ C

SAQ C applies to merchants with a payment application connected to the Internet and no electronic storage of cardholder data. It normally applies to small merchants who have deployed out-of-the box software to a standalone machine for taking individual payments.

Although this SAQ was written with small bricks-and-mortar merchants in mind, it’s often found to be the most appropriate SAQ for merchants with no cardholder data storage who process payments via in-house call centers and web-hosted payment entry.

This type of environment is what SAQ C-VT has been written to address, though the eligibility criteria exclude environments that don’t have isolated standalone workstations. As such, SAQ C covers the key controls that should apply to a call center environment though not expressly meeting the validation criteria.

This SAQ type isn’t applicable to e-commerce channels.


This new SAQ type has been introduced for merchants who process card data only via payment terminals included in a validated and PCI SSC-listed Point-to-Point Encryption (P2PE) solution. It can apply to both brick-and-mortar (card present) and mail/telephone order (card-not-present) merchants. Card data is only ever keyed directly into a P2PE validated hardware device and there’s no electronic storage of card data.

This SAQ type isn’t applicable to e-commerce channels.

8. SAQ D

SAQ D is the final SAQ and applies to any merchants who don’t meet the criteria for other SAQs, as well as all service providers. SAQ D encompasses the full set of over 200 requirements and covers the entirety of the PCI DSS. If you’re a service provider, this is the only SAQ you are eligible to complete. The only change from previous SAQ reporting is there are now separate SAQ Ds and AOCs for merchants and service providers.

Because SAQ D is the default catch-all SAQ, there may still be parts of it that aren’t applicable to your environment. One example is the requirement that track data from the magnetic stripe isn’t stored - this isn’t relevant for card-not-present transactions. It’s acceptable to mark these as ‘Not Applicable’ or ‘N/A’ with appropriate justification.

This SAQ will take considerable time for a merchant or service provider to complete. Many organizations find their resources are better spent on either reducing the scope of their environment to a point where they meet the criteria for another SAQ or engaging a QSA to assess the environment directly.

If card data is stored electronically as part of payment processing, this SAQ type will always be applicable.


When self-assessing, it’s important the right SAQ is chosen. Often organizations will find they don’t meet all the eligibility criteria for the SAQ they’d like to complete and are burdened with the full set of PCI DSS requirements. Engaging a QSA can provide invaluable assistance in determining which SAQ is most applicable and reducing the scope of your cardholder data environment. An SAQ counter-signed by a QSA also has significantly more credibility.

PCI Online Document Library


Accreditations & Certificates

F-Secure Consulting (F-Secure Cyber Security (Pty) Ltd) is a level 4 contributor to B-BBEE with a procurement recognition level of 100%. Learn more and download our B-BBEE certificate. Click here to read the press release.

Follow us
@fsecure_consult F-Secure-Consulting f-secure-foundry fsecurelabs