As of version 3.2.1 of PCI DSS, there are nine different self-assessment questionnaires. They’re almost always referred to as SAQs. Why so many? They’re all for different circumstances. Here’s the lowdown…

User:Mattes [Public domain], via Wikimedia Commons

SAQ D for service providers:
This is the easiest to explain and the hardest to meet. If you are a service provider this is the one you must use. You have no choice.

SAQ A:
This is for merchants who only have card-not-present transactions where absolutely everything is outsourced to a PCI DSS compliant service provider. If you take payments by card but never see or hear a card number this is probably the SAQ that you’ll be using.

SAQ A-EP:
Again, this is for merchants who only have card-not-present transactions. This time though, you have a website where there is some sort of interaction with the card details or direct interaction with the payment page (like hosting images, stylesheets or similar). If you find you have to use this SAQ the best thing to do is reconsider your architecture and try to outsource everything so that you meet the eligibility criteria for SAQ A.

SAQ B:
You’re a merchant but you only take card present payments and do that with either an imprint machine (zip-zap, knuckle duster and many other names) or a telephone line connected card machine that doesn’t connect to anything else in your environment – normally this means you have to enter all payment details including the amount directly into the card machine.

SAQ B-IP:
A bit like SAQ B except here your card machines are connected to either your own network or the outside world via IP rather than a traditional phone line.

SAQ C:
You have a payment application that is connected to the internet but not to any other systems in your environment.
I have never seen this in use – if you think you have this type of environment then you are very special indeed. Look carefully at the eligibility criteria and be honest about what your payment application looks like.

SAQ C-VT:
You are a merchant. You take payments using a web-based virtual terminal – similar to a consumer entering their card details into a website but you do it on their behalf.
This is another one that is very rarely used – the eligibility criteria mean it is uncommon for a merchant to actually be able to use this.

SAQ P2PE:
My favourite! You’re a merchant and you have a PCI SSC validated P2PE system in place to take card payments.
If you have done this, congratulations – you’re looking after your customer’s card information and minimising your compliance burden.
The biggest gotcha with this SAQ is that you must also meet all requirements in the P2PE solution implementation manual which means the SAQ is not a finite list of requirements that you must meet.

SAQ D (merchant):
Use this one if you are a merchant with an environment that doesn’t look like anything described above. Or if you have multiple payment channels.
SAQ D can sometimes be avoided if you talk to your acquirer. They will often allow multiple SAQs to be submitted, one for each payment channel. If they allow this, grab the opportunity with both hands. It gives you maximum opportunity to comply with PCI DSS with minimum fuss.

If at all possible, you should try to design your environment so that you meet the eligibility criteria for either SAQ A or SAQ P2PE. This will give you the smallest number of requirements to meet while keeping your customers card data the most secure.

Leave a comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Create your website at WordPress.com
Get started
%d bloggers like this: