Blog | PCI DSS Self-Assessment Questionnaires

August 25, 2021 Claranet Limited

Wayne Murphy
Principal Security Consultant at Claranet

Help around SAQs (Self-Assessment Questionnaires) is always cropping up, especially around e-commerce channels as the differences between when to use SAQ A, SAQ A-EP and SAQ D can get somewhat confusing.  In this blog post, Wayne, Principal Security Consultant, Claranet provides guidance and tips around the various PCI DSS Version 3.1.2 Self-Assessment Questionnaires (SAQs) that are available for Merchants (and Service Providers) to be completed as part of their PCI DSS reporting responsibilities. Wayne also highlights any common gotchas.  

 

What are SAQs? 

SAQs are available for Merchants (and Service Providers) and can be used, depending upon the total number of card transactions per year.  If a Merchant can self-assess, they need to provide a completed (or several completed) SAQs annually. 

The specific SAQ(s) needed will depend upon the characteristics of the payment channel you are completing the SAQ against.  SAQs are a subset of the full PCI DSS based on the risk of a particular payment channel with specific characteristics, which will be discussed later. 

There is a total of eight SAQs available to Merchants depending upon their payment channel characteristics as follows: 

SAQ Description Payment Channels
SAQ A SAQ A is used where the Merchant is not storing, processing or transmitting CHD as this is being handled by a PCI DSS Compliant Service Provider. E-commerce and Card-not-Present
SAQ A-EP SAQ A-EP, again is used where a Merchant is not storing, processing, or transmitting CHD as this is being handled by a PCI DSS Compliant Service Provider. This can only be used for e-commerce payment channels. E-commerce
SAQ B SAQ B is used where the Merchant is utilising a POI/PED (Point of Interaction/Pin Entry Device) to take the payment. Card-Present and Card-not-Present
SAQ B-IP SAQ B is used where the Merchant is utilising a POI/PED (Point of Interaction/Pin Entry Device) to take the payment. Card-Present and Card-not-Present
SAQ P2PE SAQ B is used where the Merchant is utilising a POI/PED (Point of Interaction/Pin Entry Device) to take the payment. Card-Present and Card-not-Present
SAQ C SAQ C is used where the Merchant is using a Payment Application (e.g. ePOS) that is connected to the Internet and do not store CHD. Card-Present and Card-not-Present
SAQ C-VT SAQ C-VT is used where a Virtual Terminal (VT) is being used to take the payment with. The VT will be accessed by the Merchant where a member of staff will input the card details on behalf of the cardholder into a website. Card-not-Present
SAQ D SAQ D is used when none of the other SAQs fit. All

Service Providers have a single SAQ that is available to them as detailed below:

SAQ Description Payment Channels
SAQ D for Service Providers Service Providers must complete the SAQ D for Service Providers self-assessment questionnaire. All

 

What if my Payment Channels Align to Multiple SAQs? 

Prior to PCI DSS Version 3.0, if you operated more than one payment channel, which align to multiple SAQs, you had to complete SAQ D.  Thankfully, from PCI DSS Version 3.0, this is no longer the case providing your Acquirer will accept multiple SAQ submissions.  So, what changed?  In PCI DSS Version 3.0 SAQs, the wording changed slightly which meant that you could submit multiple SAQs. 

  • Prior to PCI DSS Version 3.0 
    With the following statement, the eligibility criteria that followed locked the Merchant into the specific SAQ. 

    “Such merchants validate compliance by completing SAQ A and the associated Attestation of Compliance, confirming that:  

    - Your company handles only card-not-present (e-commerce or mail/telephone-order) transactions;” 

    etc. 

  • From PCI DSS Version 3.0 

    Within SAQ A, a modification was made to change the line above to read. 

    “SAQ A merchants confirm that, for this payment channel: 

    - Your company accepts only card-not-present (e-commerce or mail/telephone-order) transactions;" 

    etc. 

Although only a slight change, this allows Merchants to separate the SAQs out for the different payment channels. 

 

SAQ Eligibility 

A few times now I’ve mentioned the payment channels characteristics.  Characteristics are defined within all SAQs (Self-Assessment Questionnaires) apart from SAQ D since SAQ D covers all PCI DSS (Payment Card Industry Data Security Standard) requirements and is designed for when other SAQs cannot be used.  An SAQ cannot be used if it does not meet the SAQ eligibility criteria detailed within the “Before You Begin” section on Page 3 of the SAQ that provides a list of conditions by way of bullet points that must be met before the SAQ can be used by a Merchant.  

SAQs, apart from SAQ D, will contain a subset of PCI DSS Requirements based upon the types of threats, known attack vectors based upon PFI (PCI Forensic Investigator) results and risks associated with a payment channel characteristic.  This will be based upon certain conditions, which is why these are defined within the “Before You Begin” section of the SAQ. 

If you cannot meet each bullet point, that SAQ cannot be completed. 

 

Can SAQs be Signed off by a QSA? 

Within the AOC is a section for a QSA to complete if you have engaged a QSA to help complete the SAQ.  The QSA will detail what support they have provided in case the support only consisted of specific tasks.  We are often tasked with completing SAQs on behalf of customers because their board members want assurances that the assessment is done correctly and is impartial to get the best result.  This also adds more credibility to the assessment for the Acquirers. 

 

Is it true SAQs can be used to determine the requirements in a ROC? 

Yes, this is true, and is also true for Service Provider assessments.  What is interesting is that this technique can also be used when completing SAQ D where the organisation is aligning to multiple SAQs across the various payment channels, providing they all meet the eligibility criteria of the SAQs you are aligning them to.  So, the simple approach to take would be to utilise the various SAQs to determine which PCI DSS requirements are applicable for each payment channel.  If, for example you align to SAQ B-IP and SAQ C-VT for two payment channels.  You can go through the SAQs and assess the different channels against the applicable requirements within them.  Where PCI DSS Requirements are contained within both SAQ B-IP and SAQ C-VT, you would need to assess both channels against these requirements to determine if they are in place.  There is a PCI SSC (PCI Security Standards Council) FAQ on this topic named “Can SAQ eligibility criteria be used for determining applicability of PCI DSS requirements for onsite assessments?”.

 

SAQ Breakdown 

Ok, I bet this is what you have all come to this page for.  So, lets jump into it; below will list all the SAQs and provide some additional information to help identify when a SAQ can be used and any gotchas. 

Entities storing electronic CHD MUST complete SAQ D since all other SAQs includes the following statement within the eligibility criteria: 

  • Your company does not store cardholder data in electronic format. 

Details of each SAQ are as follows: 

SAQ A 

Containing 21 PCI DSS requirements, SAQ A is designed for e-commerce or mail/telephone order merchants (card-not-present) where all cardholder data functions have been completely outsourced to PCI DSS compliant service providers only.  This is often used when service providers are providing services such as: 

  • a DTMF (dual-tone multi-frequency) SaaS platform (and the calls are made direct to the service provider’s platform),  
  • a third-party contact centre, 
  • iframe/redirect technologies to support e-commerce payments. 

SAQ A, is by far, used more for e-commerce channels that utilise iframe/redirect technologies. Within the requirements contained within SAQ A, some technical requirements in Requirement 2, 6 and 8 cover the webserver(s) handling the redirect/iframe mechanism.  Additionally, I will typically include anything that could impact upon the redirect/iframe mechanism for the technical controls within the SAQ; for example, code repositories. 

CHD flow for this type of e-commerce channel is from the cardholder’s web browser, directly to the service provider. 

SAQ A-EP 

Containing 136 PCI DSS requirements, SAQ A-EP is designed for only e-commerce channels, where all cardholder data transmission, storage and processing is handled by a PCI DSS compliant service provider.  This differs from SAQ A in that the characteristics of this payment channel can impact upon the security of the payment transaction and/or the integrity of the payment page itself.  This is due to the nature of how the payment form is built and embedded into the payment page. 

Although the CHD flow is still from the cardholder’s web browser to the service provider, the merchant is responsible for building the payment form that will be used to submit the CHD.  Known as a Direct Post or JavaScript method, there is much more risk associated with this technically since the Merchant can load a myriad of third-party libraries, or a malicious actor could include JavaScript code that can manipulate or scrap the payment page.  This is the technique used by many e-commerce card data compromises and is discussed further in one of Wayne’s previous blog posts “PCI SSC Online Skimming Blog Post” and is briefly touched on in his “Hacking E-Commerce Payment Channels” blog post. 

The key difference between SAQ A and SAQ A-EP is that with SAQ A, the payment form (either following the redirect or within the iframe) is made up of code from the service provider only.  With SAQ A-EP, the merchant builds the payment page and the payment form embedded within it. 

There is a significant point within the eligibility criteria of SAQ A-EP which is often missed: 

  • Each element of the payment page(s) delivered to the consumer’s browser originates from either the merchant’s website or a PCI DSS compliant service provider(s) 

The significance of this is that any third-party libraries that are used within the payment form(s) must be stored on the Merchant’s webserver(s). 

The “Processing e-commerce payments” Visa guidance provides a visual guide on the differences between SAQ A, SAQ A-EP and SAQ D for e-commerce payments. 

SAQ B 

Containing 34 PCI DSS requirements, SAQ B is designed for brick-and-mortar (card-present) merchants or mail/telephone order (card-not-present) payment channels that do not store electronic CHD.  For both payment channels, the payment is facilitated using a POI/PDQ/PED (Point of Interaction/Pretty Damn Quick/PIN Entry Device) device that is standalone and connected to a telephone line.  There are a few gotchas with this payment channel: 

  • The device must be connected to a standard telephone line; either via PSTN (Public Switched Telephone Network) or to the Merchant’s internal PBX providing the phone system isn’t IP connected.  If the connectivity is via a PBX that is connected to a network, this will introduce an attack vector to the CHD transmission. 
  • If telephone payments are being taken, using the PED, then the voice call must not be over VoIP (Voice over IP) as this will invalidate one of the eligibility criteria (as discussed in a bit). 
  • The PED must be standalone, otherwise this will invalidate one of the eligibility criteria (as discussed in a bit).  This means that the PED cannot connect to an ePOS (Electronic Point of Sales) via, for example, a USB or Serial cable. 

The Merchant receipts will be in scope for PCI DSS requirements in Requirement 9, unless the PEDs are configured to mask out the middle of the PAN (Primary Account Number), which is the 16+ digit card number. 

SAQ B-IP 

Containing 57 PCI DSS requirements, SAQ B-IP is also designed for brick-and-mortar (card-present) merchants or mail/telephone order (card-not-present) payment channels that do not store electronic CHD.  The key difference is that the PEDs are connected via an IP network connection instead of a telephone line connection. 

As with SAQ B, PEDs need to be standalone, meaning they cannot connect to any system via a USB or Serial Cable.  In addition, the IP connected PED must be isolated from ALL other IP connected devices within the environment (apart from other IP Connected PEDs).  These devices must also be validated to the PCI SSC PTS (PIN Transaction Security) program as listed on the PCI SSC website (excluding SCRs; Secure Card Readers). 

As with SAQ B, SAQ B-IP cannot be used where CHD is transmitted over VoIP. 

Technically, PEDs connected via a mobile network (GPRS/3G/4G) align to SAQ B-IP since IP Communication is used.  If these devices are provided by the Acquirer, they will usually accept an assessment against SAQ B, but you must ensure this is discussed with the Acquirer and permission is sought. 

SAQ P2PE 

Containing 22 PCI DSS requirements, SAQ P2PE is also designed for brick-and-mortar (card-present) merchants or mail/telephone order (card-not-present) payment channels that do not store electronic CHD.  When the P2PE SAQ was originally released, this was called SAQ P2PE-HW but in April 2015, the “HW” was removed from the title. 

The beauty about this SAQ is that it can connect to your internal network, without bringing the network or any other system components into scope.  There is no criterion about this device being connected to any other systems due to the encryption mechanism used.  With a PCI P2PE deployed solution, only the devices themselves make up the scope of the PCI DSS assessment (and merchant receipts / chargeback letters if they contain the full PAN). 

It is worth noting that some Acquirers will allow Level 1 Merchants who align to SAQ P2PE to forego a PCI QSA On-site Assessment in favour of a self-assessment against SAQ P2PE.  This will often be dependent on using a P2PE solution by the Acquirer. 

SAQ C 

Containing 102 PCI DSS requirements, SAQ C is designed for brick-and-mortar (card-present) merchants or mail/telephone order (card-not-present) payment channels that do not store electronic CHD.  This SAQ has been developed specifically for Merchants whose payment application systems (for example, point-of-sales) are connected to the Internet. 

Originally, SAQ C was intended for the franchise industry where a franchisee would utilise the franchise ePOS system of choice to facilitate payments via a broadband type connection to the Internet. 

Before exploring this SAQ, it is worth exploring what is meant by “Payment Application”.  Usually, this would be something like an ePOS (Electronic Point-of-Sales) system, however, this can expand into other applications supporting card payments.  Typically, payment applications are applications involved in storing, processing, or transmitting cardholder data to support authorisation and/or settlement functions.  Although, this sounds like there is a myriad of different types of “Payment Applications” that this can cover, the eligibility criteria of the SAQ will limit this. 

The point of SAQ C is for small retail organisations with single sites or multiple sites that are not inter-connected.  The payment application(s) MUST be isolated from everything else. 

SAQ C-VT 

Containing 58 PCI DSS requirements, SAQ C-VT is designed for brick-and-mortar (card-present) merchants or mail/telephone order (card-not-present) payment channels that do not store electronic CHD.  The VT stands for Virtual Terminal which is a web-browser based access to a payment terminal provided by an acquirer, processor, or service provider to authorise payment transactions for card-not-present payments.  This SAQ can only be used for entities that process CHD via an isolated computer(s) that connects only to the VT where single transactions are manually entered into the VT. 

My personal opinion is to treat this payment channel as card-not-present, even if the cardholder is present since the card has no physical interactions with any devices, unlike where a PED/POI is being used.  Transaction charges from the acquirer will differ when using a VT since this type of payment is typically carried out as card-not-present. 

As more and more entities are embracing unified communications, especially as entities start to move to platforms such as Microsoft Teams, entities are finding themselves moving more to an alignment to SAQ D due to some of the eligibility criteria discussed in this blog.  Wayne has discussed the implications of VoIP in a couple of his other blogs over the past few years so feel free to look at these if your organisation is using VoIP or unified communications to facilitate telephone payments.  Take a look at; VoIP and Small Merchants and New Released PCI DSS Telephone Guidance

Another common mistake with this SAQ is where Merchants will deploy remote desktop technologies to limit the scope to an isolated remote desktop environment where the virtual terminal is accessed from. Unfortunately, this is simply not viable since the agent’s desktop used to access the remote desktop environment is also in-scope, since the agent is using the desktop to input the CHD. The agent's desktop and everything else that it has connectivity to is included in scope, which is typically the entire environment. 

SAQ D (for Merchants and Service Providers) 

Containing 225 PCI DSS requirements (Merchant version, the Service Provider version will also contain some Service Provider specific requirements), SAQ D is designed for use when Merchants don’t meet any of the other SAQs eligibility criteria, when multiple payment channels are being assessed in a single assessment, where electronic CHD is being stored (which may only be temporary) or for ALL Service Provider self-service assessments. 

SAQ D covers all PCI DSS requirements so is often difficult for organisation to attain and maintain PCI DSS compliance.   

Where SAQ D is being aligned, segmentation techniques can often be utilised to reduce the scope that PCI DSS requirement apply to, thereby reducing the entities PCI DSS burden and efforts.  This is often carried out incorrectly and often segmented systems and networks are often incorrectly deemed out of scope.  The PCI DSS discusses segmentation as meaning isolation which is documented within the following paragraph on page 11 of the PCI DSS. 

“Without adequate network segmentation (sometimes called a "flat network") the entire network is in scope of the PCI DSS assessment. Network segmentation can be achieved through a number of physical or logical means, such as properly configured internal network firewalls, routers with strong access control lists, or other technologies that restrict access to a particular segment of a network. To be considered out of scope for PCI DSS, a system component must be properly isolated (segmented) from the CDE, such that even if the out-of-scope system component was compromised it could not impact the security of the CDE.” 

Wayne discusses his segmentation methodology within his blog post “My Scoping and Segmentation Methodology”. 

 

Completing the SAQs 

Most entities complete SAQs incorrectly.  Either they align an incorrect SAQ by misinterpreting the eligibility criteria, or the assessment carried out is completed incorrectly.  The main misconception with completing SAQs is that this is a simple tick-box exercise.  This is far from the truth, which often means that entities believe they are PCI DSS compliant, when they are not. 

Entities MUST still validate each applicable requirement by following the tasks within the “Testing Procedures” column within the SAQ.  Even if an entity believes the requirement to be in place, this still needs to be verified.  At Claranet Cyber Security we undertake assisted SAQ consultancy where we will complete the SAQ(s) on behalf of our clients, to provide the client with additional assurance that the SAQ has been completed correctly.  The QSA will verify each applicable requirement and complete the SAQ Acknowledgement section to describe what activities the QSA has carried out and provide a signature.  

 

Merchant’s Service Provider Responsibility 

Service Providers have a PCI DSS responsibility if they are storing, processing, or transmitting CHD on behalf of their clients, or if they can impact upon the security of their client’s CDE.  Where a Service Provider has a PCI DSS responsibility, the service being consumed should be operating in a PCI DSS compliant manner.  Service Providers do not have a direct reporting obligation to the card brands; therefore, it is up to the Merchants consuming the service to request evidence that the service is PCI DSS compliant.  This can either be done by requesting an Attestation of Compliance from the Service Provider, or by including the Service Provider within the Merchant’s PCI DSS assessment.  The latter would require the Service Provider to supply evidence to the Merchant that all PCI DSS requirements that are applicable for the Service Provider are being met. 

Where Service Providers are handling, or can impact upon, over 300,000 transactions per annum, the Service Provider must undertake an onsite QSA led assessment.  Where transactions are below 300,000, the Service Provider can conduct a self-assessment against SAQ D for Service Providers. 

Merchants have a requirement within PCI DSS under Requirement 12.8, to ensure Service Provider due diligence is carried out, which includes monitoring the Service Provider’s PCI DSS compliance status.  Merchants should ensure clauses are within all Service Provider contracts to ensure the Service Provider maintains PCI DSS against a current version of the standard. 

Wayne discusses service providers further in his blog posts “Third-Party Service Providers” and “Service providers and PCI DSS Compliance”. 

 

SAQ Eligibility Breakdown 

Although this blog post doesn’t breakdown key eligibility criteria statements from each of the SAQs, Wayne’s blog post entitled “SAQs Demystified (PCI DSS Version 3.2.1)” expands this blog post into more details, including a breakdown of some of the important eligibility criteria statements for each of the SAQs. 

 

Final Comments 

Although this blog article provides a lot of useful information regarding the use of SAQs, ultimately the Acquirer will determine an entity’s SAQ obligations for reporting PCI DSS compliance.  Since the Acquirer will not understand your operating environment and the way payment flows are working, it is often best to engage a QSA to help understand the environment and payment channels and provide feedback for an Acquirer in helping with the SAQ determination.  This is especially true where the Acquirer utilises a ‘PCI Compliance Portal’ to help identify SAQ eligibility as my experience usually highlights that the portal can often identify the wrong SAQ due to incorrect responses to the questions posted by the portal. 

Mapping out the cardholder data environment (CDE) and wrestling with the SAQ alignments can be daunting so if you would like QSA assistance then please feel free to reach out to Claranet Cyber Security at info.cybersecurity@uk.clara.net.  

 

Previous Article
Blog | The application testing speed challenge
Blog | The application testing speed challenge

Over the past few years, applications have become an essential part of how organisations do business.

Next Video
Webinar | Cloud: Stealing the Silver Lining
Webinar | Cloud: Stealing the Silver Lining