The Statement on Auditing Standards No. 70 (SAS 70) has become the ubiquitous auditing report by which all cloud computing service providers are judged. So how did this financial auditing report become the standard by which we
Evolution of the SAS 70 report
The SAS 70 report got its start in 1993 as a way to review the impact of third-party service organizations on the annual financial statements of a company. This became necessary as companies started to outsource key processes such as payroll, order fulfillment, manufacturing and other business processes to service organizations. A lack of controls in any of these third-party services organizations could have a material effect on the annual financial statements. However, a comprehensive financial audit of every service provider for the company would be time consuming and cost prohibitive.
The SAS 70 report was created by the American Institute of Certified Public Accountants (AICPA) to simplify these financial auditing requirements by limiting the number of controls involved in the audit of these third-party organizations. Service organizations could prepare this standard report for all of their customers at once, which would drastically reduce the costs compared with preparing separate reports for each individual customer. The standard allowed financial auditors to more quickly review and test the controls of different service organizations.
The Sarbanes-Oxley Act of 2002, passed shortly after Enron and other accounting scandals shook public confidence in corporate accounting and auditing methods, brought the SAS 70 to the forefront. The law provided oversight of financial auditors and introduced many other changes to corporate accounting practices. The need to validate the impact of third-party organizations on corporate financial statements became much more important; SOX required the pre-existing SAS 70 report to validate the controls in place at a service organization. This simplified report quickly became the default audit for all service organizations, even though it was fundamentally flawed.
The rise of cloud computing pushed companies to search for a method to validate these new types of services. Publicly traded companies that had to be compliant with SOX were already familiar with the SAS 70. It was a natural evolution to adapt the report to auditing cloud computing service providers even though it was not originally intended for this purpose.
SAS 70 report flaws
One of the SAS 70 weaknesses is that it is not as robust as other security frameworks, such as ISO 27000 or the NIST 800 series. These frameworks take a broader approach to information security by reviewing the entire program from a risk management perspective. In contrast, the SAS 70 is focused primarily on security controls and procedures surrounding the data center and financial implications. These controls and procedures are only one part of a successful, risk-based information security program.
The SAS 70 report can be misleading to the casual observer as it only focuses on controls and procedures that are agreed upon before the audit by the auditor and the company being audited. This limits the SAS 70 to only a subset of controls and procedures that would ordinarily be included in a comprehensive security audit. There is no guarantee that just because a control is absent from the audit that it doesn’t exist. However, since it wasn’t included in the SAS 70 report, there is no way to verify that it exists. This creates a level of uncertainty that undermines the validity of the SAS 70 report.
SAS 70 Type I and Type II
It can be easy to get caught up in the difference between SAS 70 Type I and SAS 70 Type II audit reports. The Type I report only requires the auditor to make an opinion on the effectiveness of the controls in place at the time of the audit. The Type II report takes this a step further by requiring the auditor to test the controls as well as document his opinion on their effectiveness. The description of the Type II audit sounds attractive and is exactly what’s needed to verify the security controls of a service provider. However, it depends on whether the controls specified by the service provider to be included in the audit are comprehensive. As mentioned earlier, this is not usually the case.
Another issue with relying on the SAS 70 report alone to validate potential cloud service providers is much more controversial. The SAS 70 report is focused on accurate financial reporting so the auditors involved are typically from CPA firms. A CPA firm possesses the education, training and experience to audit financial controls and may even have insight into other types of controls. However, the question becomes should a CPA be validating information security controls? If the auditor does not possess expertise in information security, it will be very difficult to provide much insight into the effectiveness of the controls. There will be technical areas that will get overlooked just as a CISSP would not recognize inaccuracies in a financial audit. This seriously limits the credibility of the SAS 70.
Using the SAS 70 report for cloud evaluations
So what good is the SAS 70? Should an organization interested in purchasing cloud related services even bother requesting this report from a prospective provider? The SAS 70 can still be useful if the provider has tested more than the minimum number of controls; however, a vendor that provides a SAS 70 will most likely only be focused on areas of strength. A vendor that does not provide a SAS 70 may or may not be serious about information security and protecting your data.
Therefore it is critical to develop your own type of audit questions and due diligence procedure that focus on the controls that are important to your organization. Information security frameworks like ISO 27000 or the NIST 800 series can be extremely helpful in creating a custom due diligence procedure. The SAS 70 report is only the starting point of a solid due diligence procedure with the prospective cloud service provider. The SAS 70 may be useful but it should never be solely relied upon for validation and reassurance of proper security mechanisms and controls.
About the author:
Joseph Granneman, CISSP, has over 20 years in information technology and security with experience in both health care and financial services. He has been involved in the Health Information Security and Privacy Working Group for Illinois, the Certification Commission for Health Information Technology (CCHIT) Security Working Group, and is an active InfraGard member.
This was first published in March 2011