Most merchants who have been validating their PCI compliance for a few years now probably know which SAQ type applies to them.
In PCI 2.0, it has been fairly simple. And now we are facing PCI 3.0. My, how things have changed.
There are several new SAQ types, and a major change has occurred with one of the old standards that we all came to know. SAQ C looks nothing like its previous incarnations.
Let’s start with the most basic change in SAQ C. Which type of merchants should now use SAQ C to validate their compliance?
It used to be any merchant who processes over the Internet, did not store credit cards, and whose point of sale environment was isolated from other payment networks. The 2 most common environments to which this applied were IP based stand alone terminals, and Integrated POS systems that did not store credit cards.
With the advent of PCI 3.0, a new SAQ was developed, SAQ B-IP. Now, IP based terminals have their own standard, which is extremely similar to the 2.0 version of SAQ C. This means that integrated POS systems that do not store credit cards are alone in their usage of SAQ C, and that would be the end of the story if SAQ C had not been so radically altered.
Many merchants invested in various security products so that they would not store credit cards in their POS systems and thus eliminate several of the PCI requirements that they would otherwise face. Such technologies may include end to end encryption systems or tokenization processes that render stored data useless to cyber thieves if it is compromised.
In previous version of PCI, SAQ C merchants would not need to have a logging program (requirement 10 was omitted completely); nor would they need to implement file integrity monitoring; and lastly, a penetration test was not a requirement.
In PCI 3.0 all three of these requirements are in SAC C, and merchants who previously managed to comply with PCI will need to implement many new security measures before they will be compliant again.
While SAQ C is still less onerous than SAQ D, the gap between them has been closed significantly. If you were to poll merchants about which elements in PCI consistently give them the most grief, they would probably name logging, file integrity monitoring, and a penetration test.
Previously, SAQ C merchants were not burdened with these requirements, but those days have passed. It is our concern that merchants have not been properly educated about these changes, and it will be a rude awakening when they discover that they are required to implement them.
If you are a merchant and want to review SAQ C for yourself, you can find it on the PCI Security Standards Council’s website at: https://www.pcisecuritystandards.org/documents/SAQ_C_v3.pdf
We’ve expanded our MDR capabilities with enhanced incident response and security services to better protect against evolving cyber threats.