SAS 70 (Statement on Auditing Standards No. 70: Service Organizations) was an authoritative auditing standard that was developed by the American Institute of Certified Public Accountants (AICPA). In 2011, the Statement on Standards for Attestation Engagements (SSAE) No. 16 took the place of SAS 70 as the authoritative standard for auditing service organizations. That same year, the AICPA introduced the Service Organization Controls (SOC) reporting framework, which allows practitioners to provide different types of reports according to the requirements of service organizations and their stakeholders.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
History of SAS 70
SAS 70 defined the standards that an independent auditor, or service auditor, must employ in order to assess the contracted internal controls of a service organization, which include controls over IT and associated processes. The service auditor then outlined this description of controls through a service auditor's report. SAS 70 was developed as a simplification of a set of criteria for auditing standards originally defined by SAS 55.
SAS 70 audits were important to service organizations such as hosted data centers, insurance claims processors and credit processing companies because these organizations provide outsourcing services that affect the operation of their clients, and thus must prove that they have the necessary controls in place when they handle customer data. SAS 70 reports were commissioned at the request of either a service organization (the outsourcer company) or the user organization (its customer).
SAS 70 was introduced in 1992, when outsourcing was still relatively new and organizations still kept most of their IT processes in-house. But even though only a few key tasks were being outsourced at the time, concerns began to crop up about exactly how third-party service providers were handling these processes – mainly how these services affected companies' annual financial statements. SAS 70 was developed to help external auditors plan assessments of their clients' financial statements when those clients used third-party service providers for the processing of financial transactions and for reporting services. The standard simplified auditing requirements and allowed these auditors to more quickly review and test the controls of these third-party organizations.
However, as outsourcing became more widespread, with more organizations relying on third-party service providers for key business processes such as payroll, manufacturing and order fulfillment, and as new technologies like software as a service and cloud gained popularity, SAS 70 began to be adapted to uses outside of its intended scope, and its shortcomings became evident. As a result, more robust governance standards and frameworks, such as the ISO 27000 and the NIST 800 series, have since been developed to address organizations' evolving assurance and security needs.
While currently it's still possible to furnish an existing SAS 70 report as proof of a successful audit, as of June 2015, when the standard officially phases out, SAS 70 attestations will cease to be issued. That date is not significant, however, because most auditors have already moved on to new standards, according to SearchSecurity experts.
SAS 70 and SOX
The Sarbanes-Oxley Act (SOX) of 2002, passed by U.S. Congress in response to high-profile bankruptcies such as Enron's, placed chief executives and auditors under the microscope and brought SAS 70 to the forefront. The law gave the Securities and Exchange Commission (SEC) oversight over the financial auditors who assessed service organizations' internal controls.
One of SOX's requirements, Section 404, mandates management to determine the effectiveness of the service organization's internal controls that are vital to its financial reporting processes. To do so, management was required to do one of the following: document and assess all the controls that it considers vital to the organization's financial reporting process or obtain a SAS 70 Type II service auditor report.
Because publicly registered companies that had to comply with SOX were already accustomed to SAS 70, it was a natural progression for these companies to adapt SAS 70 when validating newer services like cloud computing, even though SAS 70 reports were not intended to address those services, according to SearchSecurity's resident information security management expert, Joseph Granneman.
Type I and Type II service auditor reports
Under SAS 70, auditor reports were classified as either Type I or Type II. In a Type I report, the auditor evaluated the efforts of a service organization at the time of audit to prevent accounting inconsistencies, errors and misrepresentation. The auditor also evaluated the likelihood that those efforts would produce the desired future results. A SAS 70 Type II report included the same information as that contained in a Type I report; in addition, the auditor attempted to determine the effectiveness of agreed-upon controls by testing them over a minimum of six months.
Head to the Continue Reading section below to see an example of a SAS 70 Type II report.
Benefits and flaws of SAS 70
A SAS 70 audit from an independent auditing agency offered service organizations significant benefits, according to SAS70.com, a website dedicated to the standard. One advantage was that a SAS 70 report could distinguish a service organization from its peers because it validated the effectiveness of its control objectives and activities. Having a SAS 70 audit performed also helped these third-party organizations build their customers' trust.
Furthermore, using a SAS 70 service auditor's report made sure that the service organizations' customers and their auditors had access to the same information regarding their controls, which was also beneficial to the user organization because the report often fulfilled its own auditor's requirements. Thus, it became less likely that service organizations would have to fulfill multiple audit requests from the user organizations and their own auditors. Additionally, because SAS 70 assessments were generally conducted by independent parties that consisted of audit and risk professionals with experience in accounting and information security, these audits illuminated operational areas that provided opportunities for improvement.
Despite these advantages, SAS 70 was not without its flaws. As mentioned above, there are more robust security frameworks that have a broader scope of information security, reviewing entire risk management and security programs. These frameworks include the ISO27000 and the NIST 800 series. On the other hand, SAS 70 had a more limited scope, focusing mainly on security controls that surround the data center and financial processes, which are only a small part of a successful information security program, according to Granneman.
Granneman goes on to say that the practice of using SAS 70 alone to audit cloud service providers was questionable because, since SAS 70 was mainly focused on financial reporting, the auditors involved were usually from certified public accountant (CPA) firms, which meant that not all of them necessarily had information security expertise, which somewhat limited the credibility of the SAS 70.
Granneman grants that the SAS 70 was useful as a starting point for vetting prospective service providers, but because of its limited scope, user organizations would have been better off developing their own due diligence procedure, basing their own audit questions on stronger information security frameworks like the ones mentioned above.