Since 1992, many organizations have relied on SAS70 audit reports to determine whether their service providers’ controls are appropriately designed and effectively implemented.
In the information security field, the SAS70 has become the unofficial standard for how service providers provide assurance to their customers that their systems are safe and secure. This is not what the SAS70 was originally designed to do – SAS70 reports are supposed to focus on financial matters, but the people have spoken.
Since my employer is a service provider, we conduct an annual SAS70 Type 2 audit with an external audit partner. We then provide the resulting report to our customers’ information security and risk teams to help convince them that they can trust us with their sensitive information. This is pretty typical for the industry.
It is important to remember that the SAS70 standard simply describes the format for the report produced by the external auditor. There is no such thing as being “SAS70 Certified.” It is even more important to realize that the scope of the SAS70 report (in the form of the list of controls to be tested) is pretty much up to the organization being audited. If the organization does not want to test certain controls, they can simply leave them out of the report. For this reason, when evaluating a SAS70 report from a vendor, you need to read carefully – what is not said in the report is probably even more important than what is included. (very zen, don’t you think?)
The new SSAE 16/ISAE 3402 standards which took effect in June of this year are meant to replace the SAS70. SSAE 16 is the US version of the standard, while ISAE 3402 is the international version. These new frameworks do provide some improvements over SAS70 for those evaluating outsourcers. I am pleased with two of the changes in particular:
- While the SAS70 was centered around the description of controls, SSAE 16/ISAE 3402 adds a requirement to include a description of the system being audited. This description must include transaction flows as well as significant non transaction events. While this is going to mean more reading for the recipient of a report, it also provides the recipient with much better context to evaluate whether the controls described later on are sufficient.
- The new standard also requires organization to do a risk assessment and make sure that the controls that are reviewed address the risks to the system described. The service provider does not have to include the risk review in the report, but the auditor will be looking for risk/control linkages during the review process. I think that this is a good thing, especially for smaller service providers who may not have a mature enterprise risk management function, as it will force management to take stock of risks in a systematic way.
While these are welcome changes, they do not really address what I think is main problem with SAS70 as an information security assurance tool – the lack of common objective criteria to be assessed. The approach that I have taken in the SAS70 that I am responsible for is to map out all of the controls described in the report against the ISO 27002 standard, which provides provides “established guidelines and general principles for initiating, implementing, maintaining, and improving information security management within an organization.” While my shop has not gone through the formal certification process for 27002, I feel that using the standard as a framework provides the readers of our SAS70 with some additional assurance that we are including all of the relevant infosec controls.
So, as we bid a (somewhat) fond farewell to SAS70, I look forward (somewhat) to our new, improved minty fresh SSAE 16 reports. My company will be doing our first SSAE 16 early in 2011 – I’ll report back on how the process differs from what we have done to date.
RSS - Posts