So has your acquirer/merchant bank has asked you to complete a Self-Assessment Questionnaire (SAQ)? Are you confused which SAQ to complete? Don’t know where to start?
… Don’t worry. You’re not alone!
Since PCI DSS 3.0, there has been further SAQs introduced, which can add further confusion.
In the beginning…
A lot of merchants do not realise why their acquirer is asking for your SAQ. So let’s recap a little behind the scenes of what is going on, so you, as the merchant have a little more insight into the reasons why SAQs are being asked for.
As a merchant, you have agreed a contract with your merchant bank (the “acquirer”). Somewhere in that contract it is likely to state you will satisfy/maintain PCI DSS compliance.
It’s a FINE time… don’t you think?
Acquirers must report on a frequent basis the security position of all their merchants to the payment brands (VISA, MasterCard, JCB, Discovery and Amex). If they cannot report this security position to the brands, then your acquirer may receive a financial penalty (basically a big fine). So hopefully you can see that it is your acquirer’s best interest to get this information from you to avoid the fine!
Payment Brand >>> Acquirer >>> Merchant
Your acquirer may have a right to pass this fine onto you, the merchant and therefore you may have had warning letters to say you must report your status, otherwise you may get fined. Does this sound familiar?
So hopefully you can see the first problem – your acquirer does not know your security posture. To do this, you must complete your SAQ, which reports to them your security posture – in short, how PCI DSS compliant you are. The second question is which SAQ are you eligible for? We discuss them below.
HINT: The main risk is to processing, storing or transmitting of cardholder data electronically. This means cardholder data traversing electronically through your networks and therefore the more that you do electronically over your network, the harder is the SAQ. If you store cardholder data electronically, then this data is at a higher risk of being stolen – if you store cardholder data electronically, go to SAQ D (if you are eligible to fill out a SAQ).
SAQ A – “the outsourcing model”
In short, this applies to Card-Not Present (CNP) merchants (e-Commerce or mail order/telephone order) who have fully outsourced ALL cardholder data processing functions to a PCI DSS compliant service provider. This means you do not process, store or transmit any cardholder data at all on your merchant systems or merchant premises.
Examples may include:
- Football clubs who have outsourced all payment functions to a call centre or other third parties to take payment.
- An online store who has outsourced all online payment functions to a PCI DSS compliant service provider*.
* Be careful as it could be SAQ A/EP depending on how it is processed online – ask your acquirer or a Qualified Security Assessor (QSA) for help.
SAQ A/EP – “Payment taking outsourced, but we host the website bit”
Introduced under PCI DSS v3.0, this applies to e-Commerce merchants who rely on third parties for payment taking, but you have a website that could impact the security of the payment taking (someone can hack your web machine and change where payments are taken or how payments are taken). Like SAQ A, this means you do not process, store or transmit any cardholder data at any point on your merchant systems or merchant premises.
Example is you own the web machine, host the website, but maybe you do a “silent order post” (silent order post is a long discussion outside of this post)
SAQ B – “Ye Olde Plain Ol’ Telephone System (POTS)”
I love this one. Classic one whereby you process card data via:
- A standalone payment terminal that connects to your telephone line to process payments.
- Or in the rare occassion your payment terminal does not work you use an imprint machine (remember those machines whereby you physically get the card and create a carbon copy for example)?
The imprint machine “Ker-chunk”
SAQ B/IP – “The Networked Terminal”
In short, the telephone terminals are being replaced with those terminals you plug into your network (IP-based terminals). This means you do not store cardholder data electronically.
Examples include lots of retailers such as supermarkets. Because the terminals are connected to networks, these terminals tend to process data very quickly.
SAQ C – “The payment application SAQ”
Self-explanatory. you use payment applications to process cardholder data. This excludes payment applications through Internet browsers… that’s the next one, SAQ C/VT. Also note your systems do not store cardholder data electronically.
SAQ C/VT – “The Virtual Terminal”
This is where you enter cardholder data one at a time through a Internet-based browser application/website. The application/website is hosted by a PCI DSS compliant service provider. Also note your systems do not store cardholder data electronically.
P2PE-HW – “Silver bullet for de-scoping”
Well maybe it is not the silver bullet, but many merchants look to this, as they simply do not feel the overhead of maintaining a collection of PCI DSS controls is pragmatic for their business. In essence, if you use a terminal that has been P2PE validated then the bits between your terminal and your payments processor may be deemed “out of scope” and therefore the long list of associated PCI DSS controls are no longer applicable*. Also note your systems do not store cardholder data electronically.
NOTE: P2PE requirements comes with its additional requirements that may be difficult to maintain.
SAQ D – “you’re a rogue”
This is where you don’t fit in to the other SAQs. It’s most likely that you’ll be storing cardholder data).
The main discussions I hear from merchants is a misunderstanding between SAQ A to SAQ A/EP. If this sounds familiar, seek advice from your acquirer and/or a QSA. There are ways to drop you down from SAQ A/EP to SAQ A and actually you can apply specific actions relatively quickly to achieve this, but the question is whether a business is open minded to change how the website works.
I hope you understand the reporting obligations of the acquirers to the payment brands and why they keep asking you to complete a SAQ.
Phew! That’s pretty much the end of this long post. Well done if you’re still reading this. I hope you received some value out of this. If you have, share this website link with others.
#cyberattack, #cybersecurity, #dataprotection, #datasecurity, #datasecuritybreach, #gdpr, #gdprcompliance, #informationsecurity, #infosec, #pcidss, #personaldata, #security, #StayHomeSaveLives
