If you process, transmit, store or can impact the security of cardholder data, you must meet – and annually validate compliance with – the PCI DSS (Payment Card Industry Data Security Standard).
This can be fulfilled via:
An external audit conducted by a QSA (Qualified Security Assessor); or
An SAQ (self-assessment questionnaire).
To determine which you must do, contact:
Your acquiring financial institutions if you’re a merchant; or
The individual payment brands if you’re a service provider.
As a rule of thumb, the more transactions you process, the more likely you’ll have to undergo an audit. If you’ve recently experienced a breach, you’re also more likely to need to bring in a QSA.
But if you can validate PCI compliance via an SAQ, under the latest version of the PCI DSS – v4.0.1 – you have ten questionnaires to choose from.
In this blog
3 questions to help identify your SAQ
MOTO (mail order/telephone order) merchants
Want to jump straight to a specific SAQ?
What is a PCI SAQ?
A PCI DSS SAQ is a method for validating compliance with the Standard. Because it’s less rigorous than the alternative – a third-party audit conducted by a qualified assessor – only lower-risk organisations qualify for this method.
Again, to find out whether you qualify for an SAQ, you need to contact your acquiring financial institution (or the individual payment brands, if you’re a service provider).
All SAQs are available for free in the PCI SSC’s (Payment Card Industry Security Standards Council) document library – just filter for ‘SAQ’.
Why are there so many SAQs?
Although the PCI DSS comprises hundreds of sub-requirements – 277, to be exact – most organisations don’t have to meet them all.
Unquestionably, the PCI DSS is a robust data security standard, setting clear control requirements. It’s specific about what you must do to meet them – which can make it challenging to achieve compliance, particularly for smaller merchants.
The PCI SSC recognises this, which is why it allows organisations to reduce their scope. This can qualify them for a simpler SAQ – which, by extension, also reduces the PCI DSS compliance burden.
This approach still significantly reduces the risk of fraud and data breaches, but with far less effort.
Which SAQ do I need?
With ten SAQs currently available, be sure you choose the correct one.
Here are three questions to help get you started:
1. Merchant or service provider?
The first step is to determine whether you’re a merchant or service provider:
Merchant: An entity that accepts payment card payments for goods and/or services. (This includes entities that outsource their payment card processing.)
Service provider: An entity directly involved in processing, storing, transmitting and/or securing account data (cardholder data and SAD – sensitive authentication data) on behalf of another entity.
If you’re a service provider that can validate compliance via an SAQ, you need to select SAQ D Service Provider:
Note that SAQ D Service Provider is the only SAQ available to service providers – the other nine questionnaires are available to merchants only.
Though SAQ D Service Provider covers all 12 requirements of the PCI DSS, not all 12 may be applicable to you, depending on the services you offer.
If you’re a hosting provider that only physically hosts a data centre or another facility, for example, you only need to demonstrate compliance with:
The physical security measures under Requirement 10; and
The associated security policies and procedures under Requirement 12.
2. Do you store electronic account data on your own systems/premises?
If you’re a merchant, this is the next question to ask.
All the simpler SAQs don’t permit you to electronically store any account data on your own systems or premises.
If you do electronically store it, you have to complete SAQ D Merchant, the most arduous questionnaire for merchants:
3. How do you take payments?
Broadly speaking, merchants take payments in three ways:
Online
Face to face
MOTO (mail order/telephone order)
That said, merchants aren’t limited to just one of these, and the more ways you take payments, the more likely you’ll have to go for SAQ D Merchant.
But if you must choose SAQ D because you take both, say, online and face-to-face payments, you can still use some of the simpler SAQs as a guide to make SAQ D easier to complete.
Let’s go through the remaining SAQs and explain how they link to each method of taking payments.
Online merchants
If you’re an online merchant, you’re limited to the following SAQs:
SAQ A
SAQ A-EP
SAQ D Merchant
We’ve already provided an overview of SAQ D.
As to SAQ A and SAQ A-EP, you may qualify for one of these if you outsource your account data processing to PCI DSS-compliant TPSPs (third-party service providers).
SAQ A
Nearly all online merchants aim for SAQ A, as it’s one of the most straightforward, least time-consuming questionnaires.
To qualify (as an online merchant – we’ll discuss SAQ A for MOTO merchants later), you must either outsource your entire website, or set up a web page redirect or an iframe to process payments.
Further reading: You can learn more about web page redirects, and other ways of reducing your PCI DSS scope, in this blog.
If you fully outsource your website, you can reduce the number of questions you need to answer to just 6. (You’d mark the remaining 25 questions in SAQ A as ‘N/A’.)
That said, you need to conduct some due diligence to:
Avoid unpleasant surprises further down the line; and
Ensure much of the compliance burden is shifted to the TPSP.
Further reading: QSA Stephen Hancock explains common PCI DSS challenges when outsourcing (to qualify for SAQ A), and how to address them, in this blog. This includes advice on what to check for to ensure the above.
SAQ A-EP
While the eligibility criteria of SAQ A-EP are similar to SAQ A, they have one important difference: SAQ A-EP merchants control how account data is redirected to a PCI DSS-compliant TPSP. (But SAQ A-EP merchants still can’t receive account data directly.)
Because SAQ A-EP merchants retain some control that can impact the security of the data, they must meet a much larger set of requirements than SAQ A merchants, including requirements for ASV (Approved Scanning Vendor) scanning and penetration testing.
That said, SAQ A-EP is still significantly less challenging to complete than SAQ D Merchant.
Face-to-face merchants
Face-to-face merchants could qualify for any of the remaining SAQs. Let’s start with the one applicable to only certain face-to-face merchants: SAQ SPoC (software-based PIN entry on COTS).
SAQ SPoC
SAQ SPoC is the newest PCI DSS SAQ, introduced as part of PCI DSS version 4. Here’s a quick overview:
In short, if you only take fully attended card-present payments, and correctly use a PCI SSC-validated SPoC solution, this SAQ can be an attractive option, as it’s comparatively straightforward.
This will most likely be of interest if you’re a small merchant taking payments via a COTS (commercial off-the-shelf) device, such as a smartphone.
Further reading: QSA Stephen Hancock gave a more detailed overview of this SAQ in this interview.
SAQ B
Both face-to-face and MOTO merchants could qualify for SAQ B; that said, face-to-face merchants are more likely to go for this questionnaire.
To qualify, the merchant must only use one or both of the following:
Imprint machines. These make an imprint of the card and transfer it onto a carbon paper receipt, which the merchant stores (on paper – not electronically).
Standalone dial-out terminals. These enable the use of chip and PIN, swipe cards and manually keyed transactions.
If you use a dial-out terminal, make sure it’s only connected to a phone line to qualify for SAQ B. Otherwise, you’re looking at SAQ B-IP:
SAQ B-IP
Like SAQ B, SAQ B-IP is also designed for merchants that use a standalone terminal to process transactions.
However, where SAQ B merchants use a dial-out terminal only connected to a phone line, SAQ B-IP merchants use IP-connected PTS POI (PIN transaction security point-of-interaction) devices.
Since these devices are network-based, account data could be at higher risk, so SAQ B-IP merchants must meet a more stringent set of PCI DSS requirements than SAQ B merchants, including ASV scans and PCI penetration tests.
MOTO merchants
SAQ P2PE
To significantly reduce the PCI DSS compliance burden, both face-to-face and MOTO merchants may want to look into a P2PE (point-to-point encryption) solution to potentially qualify for SAQ P2PE:
This removes all POS systems, networks and supporting infrastructure from your PCI DSS scope, provided that you:
Implement a PCI SSC-listed P2PE solution;
Have correctly implemented the solution; and
Only use hardware payment terminals included in, and managed via, that solution to process account data.
SAQ A (for MOTO)
Earlier, we discussed SAQ A in context of online merchants. However, MOTO merchants can use it too (only face-to-face merchants can’t submit this SAQ).
To process payments over the phone and qualify for SAQ A, you need to fully outsource payment processing to a PCI DSS-compliant service provider.
Alternatively, you could deploy a PCI DSS-compliant third-party DTMF (dual-tone multi-frequency) masking solution.
A DTMF solution allows cardholders to enter their card details via the keypad on their phone. The DTMF masking will overlay the keypad sounds with a monotone beep or another form of white noise to ensure no one can work out the card details auditorily.
SAQ C-VT
The typical alternative to DTMF (for payments by phone) is SAQ C-VT, which is more burdensome than SAQ A:
Though still significantly easier to complete than SAQ C or SAQ D Merchant, relying on this type of manual approach has major drawbacks, like:
Increased administrative burden; and
Potential for human error.
That’s because, if you record calls, you must pause recording when the customer provides their card details. Alternatively, you could manually tag calls that contain payment data, then later revisit them to mute or mask that data.
For merchants like call centres, this can still be a viable option to reduce their CDE (cardholder data environment).
If you aim for SAQ C-VT, make sure your virtual payment terminal solution provider is PCI DSS compliant.
SAQ C
SAQ C merchants are similar to SAQ C-VT merchants, but operate Internet-connected payment applications rather than a virtual payment terminal.
Since anything Internet-facing is automatically exposed to increased cyber risk, all 12 PCI DSS requirements are at least partially covered in SAQ C.
However, since SAQ C merchants don’t store any account data electronically (if you do, you need to complete SAQ D), they’re still exempt from a substantial number of sub-requirements. This is also reflected in the number of questions to answer.
Conclusion
Hopefully, you now have a good idea of which SAQ applies to you, or which SAQ you can reasonably aim for.
You should also have a good overview of the principles behind PCI DSS scope: the less risk you’re exposing account data to, the fewer requirements you need to meet.
In turn, that reduces both the cost and burden of PCI DSS compliance. Not to mention the risk of a data breach!
If you still need help to identify the right SAQ for you, or need advice on how to reduce your scope, why not speak to our friendly team of PCI DSS advisors?
We can help quickly determine your goals, and advise on a programme that meets your organisation’s needs and expectations.
We first published a version of this blog in July 2022.
The post Choosing the Right PCI DSS SAQ: A Practical Guide appeared first on IT Governance UK Blog.
