The American Institute of Certified Public Accountants (AICPA) Statement of Auditing Standard No. 70, or SAS 70 as it is more commonly known, has been with us since April 1992. On 15 June 2011, it will effectively be replaced by two new standards: (i) a reporting standard for service organisations, the ‘Statement on Standards for Attestation Engagements No. 16’ (SSAE 16); and (ii) an audit standard for customers of service organisations, ‘SAS Audit Considerations Relating to an Entity using a Service Organisation’.
Given the proximity of this date, we felt that it would be appropriate to reflect on the impact of SAS 70 on IT law and consider what, if any, impact SSAE 16 will have. We also felt that it is a timely point to draw attention to two new standards that have been introduced by the AICPA, SOC2 and SOC3, and question whether instead of referring to SAS 70 or SSAE 16, contracts with IT service providers should now refer to SOC2 and SOC3.
What is SAS 70?
Perhaps it is more relevant to start by clarifying that SAS 70 is not a security or privacy standard. As a Gartner report from June 2010 noted, many service providers have incorrectly portrayed SAS 70 compliance as a form of security or privacy compliance certification.
It is, of course, neither of these things. SAS 70 is an auditing standard designed to enable an independent auditor to evaluate and issue an opinion on the existence, but not the substance, of a service provider’s controls (which include, but are not limited to security controls). The fact that a service provider has and can provide a customer with a SAS 70 audit report says nothing about the actual security controls that a service provider may have in place.
So why then has SAS 70 featured in security discussions between customers and service providers since its introduction in 1992? The benefit of a SAS 70 report to customers is that it enables a customer’s auditors to satisfy themselves as part of a financial statement audit that the customer’s service providers have security controls, among other things, in place without needing to directly examine the service provider’s security controls. This equally benefits the service provider as it does not need to be separately audited by all of its customers as part of their financial statement audits but can provide a copy of its SAS 70 report as an auditor-to-auditor communication.
That stated, given that SAS 70 is not an audit of the substance of a service provider’s security controls, it is standard practice in services agreements for customers to insist on having separate rights to carry out a substantive security audit of a service provider.
What’s changing?
The AICPA has decided to converge this standard with those of the International Auditing and Assurance Standards Board (IAASB), in particular ISAE 3402, and make a distinction between the standard that applies to service providers (i.e. SSAE 16) and the standard that applies to the financial statements of customers who use service providers (i.e. Audit Considerations Relating to an Entity using a Service Organisation).
For the purpose of IT contracts, the key changes to note are in the application of SSAE 16 to a service provider’s security controls.
In terms of reporting, under SAS 70 a service auditor could issue a Type 1 report, which sets out a service provider’s description of controls on a specific data together with the auditor’s opinion on whether the description is fairly presented and suitably designed to achieve the service provider’s control objectives, or a Type 2 report, which includes the same content as set out in a Type 1 report together with the auditor’s opinion on whether the service provider’s controls were operating effectively over a minimum period of 6 months (based on testing carried out by the auditor).
SSAE 16 also makes a distinction between Type 1 and Type 2 reports, but adds a requirement for the auditor to obtain a written assertion from the management of the service provider about the fairness of the description of their controls, the suitability of the control’s design and, in respect of a Type 2 report, the operating effectiveness of the controls.
Further, while under SAS 70, a Type 2 report set out the auditor’s opinion regarding the operating effectiveness of a service provider’s controls at a specific point in time, a SSAE 16 Type 2 report requires the auditor to provide an opinion covering the entire period.
Should contracts therefore now just refer to SSAE 16?
The report issued by an auditor following a SSAE 16 audit (be it a Type 1 or Type 2 report) is officially known as a Service Organisation Control 1 (‘SOC1‘) Report.
While SSAE 16 makes some adjustments to the content of the auditor’s report, it effectively remains, like SAS 70, an audit of the service provider’s internal controls against the service provider’s control objectives and does not provide an objective standard by which such controls may be measured.
If a customer is looking for a service provider’s security controls to meet objective standards, then it may wish to impose a requirement that the service provider is audited to the AICPA’s Service Organisation Control 2 (‘SOC2‘) and Service Organisation Control 3 (‘SOC3‘) standards.
Unlike a SSAE 16 SOC1 audit, where the service provider identifies the objectives against which it is audited, both the SOC2 and SOC3 audits require a service provider to provide assurance about whether its internal controls relating to security, availability, processing integrity, confidentiality and the privacy of its system and information meet pre-defined AICPA Trust Services principles and criteria.
SOC2 and SOC3 reports provide the same level of assurance, however the SOC3 report does not contain a detailed description of the testing carried out by an auditor and can therefore be freely distributed or posted on a web site as a seal. SOC3 may well become the objective certification standard for storing customer data that SAS 70 has misleadingly been portrayed as.
If you are currently drafting or negotiating an IT contract, what should you do next? As a minimum you need to check with your audit function whether your contract should refer to the US AICPA standard, i.e. SSAE 16, or the international IAASB standard, i.e. ISAE 3402 instead of SAS70. You may also wish to consider whether it is appropriate to include a requirement in the contract that the service provider is audited to SOC2 standards (in addition to any security wording normally included in your contract).
Kevin Boyle is a Partner, based in Washington D.C., and Brian Meenagh is an Associate, based in London, in the Technology Transactions Group at Latham & Watkins (www.globalprivacyblog.com)
