Self Assessment Questionnaire

SAQ Validation Requirements, Quite Simple Really

There’s an old phrase that’s depressingly appropriate when it comes to the completion of Self Assessment Questionnaires (SAQ); “Not worth the paper it’s printed on.” At least that’s how it is for the majority of the ones I’ve seen, SAQ validation is universally performed badly.

The reasons for this are many. From acquirers leaving the choice of SAQ up to the merchant, to merchant indifference, to flat out incompetence, many SAQs are works of fiction. While the PCI DSS itself has undergone significant modification to ensure more appropriate validation, the SAQs have not followed suit.

For example, for a relatively simple requirement like ‘1.1.1 A formal process for approving and testing all network connections and changes to the firewall and router configurations.’, the DSS requires all of this;


The corresponding SAQs (A-EP, and D-M and D-SP) require just this;


While the DSS requires full descriptions of HOW the requirements we validated, the SAQ requires just one of 5 tick-boxes; “Yes”, “Yes, with CCW”, “No”, “N/A” and”Not Tested”.

I fully understand that the SAQ requirements are completely tied to risk, however, EVERYONE is liable for full compliance against the entire DSS. The SAQ is just a reporting mechanism, nothing more. In other words, if you don’t validate properly, you’ll still be held fully accountable in a worst case scenario.

It follows therefore, that when validating your applicable SAQ requirements, you follow the Testing Procedures of the DSS. That way, should the worst happen, you can actually demonstrate appropriate due diligence. If you can “Describe how…” you sampled, examined, and tested firewall and router configuration changes, you cannot claim to have properly “Examine[d] network configurations”.

So, to help resolve this, and to once again demonstrate how sad I am, I have performed yet another mapping. This time I have mapped the applicable requirements as defined in all 9 SAQs to the validation requirements of the full PCI DSS v3.2. I did though go one stage further, and added a “Questions” sheet to help determine requirement applicability up front.

For example, if you do not retain full cardholder data post-auth, the majority of the encryption requirements become ‘Not Applicable’. Same for absence of wireless, no in-house application development, and so on.

Start with the ‘Questions’ tab of the spreadsheet (available here in Downloads) and answer “Yes” or “No” to each question. Now when you go to the ‘v3.2’ tab you will see which requirements are applicable to which SAQ (marked with a ✓). Now just choose your column and feel free to filter.

If I’m completely honest with myself – which I usually am – I know that there is little benefit to this document, but it may be of interest in these scenarios:

  1. Any merchant changing SAQs, going up a level, or adding a service – For example, if you’re a Level 2 Merchant and you’re going to kick up to Level 1, you’ll see just how much work you have to do. Or if you are adopting P2PE, you see just how much your SAQ validation is reduced.
  2. Anyone who wants to see just how irrelevant the SAQs are in relation to real security – If all you do is complete an SAQ, you’ll be able to compare a minimum set of security controls (the full PCI DSS) to what you’re doing. Well, what you should be doing at an absolute minimum if you cared at all about your customers data.
  3. Any entity wanting to validate their SAQ properly.

In 10+ years of providing PCI guidance, I have never seen an acquirer ask for validation evidence outside of an ASV scan. I doubt I ever will, so if you want to do security properly, great, but don’t use the SAQ as your guide. In fact, don’t even use the DSS for anything more than a rough guide, you’re better off with a real consultant.

[If you liked this article, please share! Want more like it, subscribe!]

If you think I'm wrong, please tell me why!

This site uses Akismet to reduce spam. Learn how your comment data is processed.