After a few months of releasing the odd supporting document here and there for the new PCI DSS v3.0, the PCI SSC suddenly released 9 new documents last week, consisting of the ones we have all been waiting for, the new SAQ’s. They released updated version of the 6 existing SAQ’s and 3 new ones to cover more payment channels, and all of them have had a significant overhaul from the SSC to be easier to understand and more relevant to today’s technologies.
The 3 new SAQ’s are; A-EP, which is to cover the now common situation of e-commerce merchants that out-source their payment processing but not the administration of the website that links to it and so need to protect this properly; B-IP, that address the scenario of a merchant that uses standalone PED’s that are connected not via a phone line but via an IP connection to the processor as is more prevalent in SME’s these days; and finally they have split the full SAQ D into two separate versions, one for merchants and one for service providers so as not to cause confusion. All of these three are, in my opinion very useful additions to the SAQ selection.
Moving on, the most noticeable changes to these new forms is that the layout has been re-arranged to be clearer and more logical, section 3 which is the Validation and Attestation details has been expanded and moved to the end after the questionnaire section, and section 1 which includes the assessment information and executive summary has been greatly expanded to give much more useful information. A point of note here is that there is a facility now to mark requirements as non-compliant due to legal exceptions and an area in section 3 to offer explanations for the legal exceptions, which should help clear up the confusion that usually surrounds such things.
The next big change is to the actual questionnaire section, and while looking at the actual number of questions may shock some people as they have increased quite significantly (up from 289 to 332 for the full SAQ D, and up by 53 questions for SAQ C, for example), this increase is mainly contributed to the way this section has been constructed. Rather than simply repeating the testing procedure from the standard itself as was the case for v2.0, with the new version they have taken the actual requirement and phrased it into a relevant question or questions that an organisation can, arguably, understand easier. Then they have added and extra column that list how the SSC expect the organisation to test or get the answer to each question. This has resulted in some requirements which, for example had only two testing procedures in the standard to have more than two questions to answer with a variety of expected testing instructions, overall I think this a much clearer and more understandable way to present the standard to organisations.
Probably the most significant change to the SAQ’s is actually one of the most subtle changes; under both the old and the new versions of each of the SAQ’s there is a section in the introduction that lists the eligibility criteria detailing what the organisation must do in order to qualify for that SAQ, if your organisation doesn’t fit those criteria exactly then you cannot use that one and must select a different SAQ.
In the old versions it stated in order to ‘validate compliance by completing the SAQ the merchant confirms that…’, and then listed the criteria. For example the first criteria on SAQ B was ‘Your company uses only imprint machines and/or uses only standalone, dial-out terminals (connected via a phone line to your processor) to take your customers payment card information’ meaning that if you had dial-out terminals and a website, for example, to take payments you did not qualify for SAQ B. This is crucial because the implications of this were that if, as an organisation you took payment via multiple channels you automatically had to use the full SAQ D with all the questions thereby making the process more complex as many requirements would need to be marked as ‘Not Applicable’ and then explained in detail. It had been known for some acquirers to allow you to fill out multiple SAQ’s if you had different accounts for each payment channel, but this was rare.
The subtle but important change to this section rewords the preceding phrase to ‘SAQ B merchants confirm that, for this payment channel:’ and then lists the criteria similarly. This change implies quite clearly that even if you only have one account and take payments via multiple channels you can fill out a separate SAQ for each channel based on the eligibility criteria for each SAQ. This is further reinforced by the addition of two new questions in the executive summary section, the first of which is ‘What types of payment channels does your business serve?’ with a list of the relevant options for the SAQ and the second one next to it is ‘Which payment channels are covered by this SAQ?’ with the same list of options, this again shows that each SAQ does not have to cover all your payment channels.
It should be noted though there is a comment after these questions stating that if you have payment channels not covered by this SAQ you should consult your acquirer about validating the other channels, so your acquirer may then request you to fill out a single SAQ D for all channels together, but I find it unlikely that they will want you to supply them with more paperwork for them to do than is absolutely necessary. Irrespective of the acquirers, this change is clearly a massive one for many organisations as now they can ignore all the non-applicable requirements and concentrate on correctly and efficiently controlling the others. But it is still vitally important to select the correct SAQ or SAQ’s for your organisation otherwise your compliance is invalidated and you are left open to breach of contract consequences, I would always advise companies and organisations that are unsure to seek outside, experienced help with SAQ selection either old or new.
Overall these changes give us the impression that the PCI SSC is trying to make the standard easier for SME’s to comply with to help and encourage them to become compliant, the new versions are written and laid out in a simpler and more use-friendly way and I think that they accomplish these aims quite well.