Insights into the new Payment Card Industry Data Security Standard SAQ SPoC from our QSA (Qualified Security Assessor) consultant
Stephen Hancock is an experienced information security professional who combines expertise in cyber security with a broader background in IT and value-for-money audit.
He specialises in the PCI DSS (Payment Card Industry Data Security Standard) and, as a QSA, has helped many organisations – ranging from national charities to start-up fintech organisations – understand and achieve compliance with the Standard.
We sat down to chat to him.
The PCI SSC has recently released a new SAQ. Can you tell us a bit more about that?
Sure. SAQ SPoC, which stands for ‘software-based PIN entry on COTS’, was released towards the end of last month. It’s a relatively short SAQ, with only one more question than the shortest SAQ, P2PE [point-to-point encryption], and covering just 4 of the Standard’s 12 high-level requirements, so a good way of reducing the PCI DSS compliance burden for smaller merchants in particular.
Which merchants might qualify for this new SAQ?
First, you can only take in-person, card-present payments – so e-commerce merchants don’t qualify; neither do merchants that also take payments over the phone.
Second, you can only take the payments via fully attended channels. That means that you can’t have any self-checkouts, nor any semi-attended environments, where the merchant is not directly involved at the time of transaction.
The reasoning behind this is that the risk of compromise is higher with unattended checkouts, which is why those merchants are excluded from this less stringent SAQ.
What SAQ would merchants now qualifying for SAQ SPoC likely have completed in the past?
That’s a really good question. As there was no specific SAQ for SPoC solutions, the technically correct answer is SAQ D.
However, where compliance was validated through an external audit, I think a QSA would have drawn on SAQ B-IP, which is designed for merchants using a standalone terminal and PTS POI [PIN transaction security point-of-interaction] devices to process transactions.
The QSA would also have been guided by the PCI SSC guidelines on securely accepting mobile payments. But those don’t outline what specific requirements would apply.
Therefore, in the past, the QSA would probably have created what is, in effect, a new ‘SAQ’. This likely included asking about some things that aren’t in the PCI DSS at all, such as locking down the COTS [commercial off-the-shelf] device. I personally have never come across the scenario in use, however, so this is an educated guess only.
Also bear in mind that because merchants potentially qualifying for SAQ SPoC tend to be smaller organisations, in many cases, no QSA would have been involved. Because of this, it’s likely that merchants would have struggled to identify and comply with their PCI DSS requirements.
Tell us a bit more about SPoC solutions themselves. What do organisations need to be aware of?
As with several of the shorter but more restricted SAQs, it’s important merchants only use solutions approved by the PCI SSC. The Council has a full list of validated SPoC solutions on its website.
The solution must also, of course, be correctly implemented. Concretely, this means implementing all controls as outlined in the user guide provided by your SPoC solution provider.
It’s also important the SPoC solution isn’t connected to any other systems or networks in the merchant environment. In addition, outside of that solution, the merchant isn’t permitted to electronically store or process account data.
The idea of SPoC is that when customers enter their PIN, that data is isolated from other sensitive account data, such as full magnetic-stripe data. This makes it harder for an attacker to breach all data at once. However, again, it’s also important to reduce the risk of compromise by being present at the time of taking payment if you want to qualify for this new SAQ.
What exactly is provided by the SPoC solution provider?
There are a few components:
- An SCRP [secure card reader for PIN]. That’s the device customers insert their card into and enter their PIN.
- A PIN CVM [cardholder verification method] application. This is software that runs on the COTS device, and isolates the PIN on that device. However, the CVM isn’t used for contactless payments.
- A back-end monitoring system. This is a remote service, provided by the SPoC solution provider, to detect any potentially malicious activity.
Naturally, for the solution to work, it also requires at least one merchant-owned COTS device.
Finally, why is it that this SAQ – for face-to-face merchants with fully attended payment channels only – was released now, at a time where it seems like more and more merchants are moving towards e-commerce, or at least self-checkout options?
I think there’s a class of small merchants to which taking payments through a smartphone or tablet – so a COTS device – is attractive for mobility or even for presentation reasons.
Also, it was evident that most PCI DSS requirements wouldn’t apply to such merchants, but until now, there’d been no defined subset of requirements they could meet, rather than submitting the arduous SAQ D. Introducing this new SAQ makes it much easier for them to identify what requirements they must meet and, by extension, makes it more likely that account data is kept secure.
We hope you enjoyed this week’s edition of our ‘Expert Insight’ series. Please do leave a comment below to let us know what you think, and if you have any questions you’d like our experts to answer.
We’ll be back next week, chatting to another expert within the Group.
In the meantime, if you missed it, check out last week’s blog, where our senior penetration tester, Leon Teale, gave us his top 10 secure remote working tips and expert insights into different VPN (virtual private network) technologies.
