Behind the Standards: Clarifying SAS 70’s Confusing Departure

Understanding SSAE 16 and SOC attestations

The demise of SAS 70 audits raises questions, confusion and a dose of drama. To gain clarity on the auditing standard’s replacement and its alternatives, it helps for service providers and their customers to understand what went on behind the scenes that caused in this change (see “Practical Points” side bar).

Practical Points

The replacement of the SAS 70 auditing standard with the Statement on Standards for Attestation Engagements No. 16 (SSAE 16) has caused confusion. The following points apply in most, but not all, situations; and they should be confirmed in individual cases.

1. Most service providers that used SAS 70 Type I and Type II audits specifically for reporting on internal controls over financial reporting (often for user organizations subject to Sarbanes-Oxley) will now use SSAE 16 – also known as Service Organization Control (SOC) 1 Type I and Type II audits instead.
2. Service providers that used SAS 70 audits for other purposes, such as to demonstrate internal controls around data privacy and security risks, may now use the AICPA’s new SOC 2 or SOC 3 standards; however, there are many other viable options to demonstrate these types of internal controls. Using the Cloud Security Alliances Controls Matrix (CCM) to develop a set of controls that will meet multiple security standards and frameworks may be especially helpful.
3. The most effective way a buyer can begin a discussion about an external services provider’s controls is by asking the following question: “What are you doing to protect my data?”

If SAS 70 reviews were the subject of VH-1’s melodramatic “Behind the Music” documentary series, the episode might portray the auditing standard’s humble beginnings in the early 1990s, its explosive rise to post-Sarbanes-Oxley stardom, its subsequent overexposure in the marketplace and, ultimately, the popular standard’s sad passing on June 15, 2011.

In a move that admittedly caused more confusion than actual tears (or, to be fair, much television-worthy drama), the American Institute of Certified Public Accountants (AIPCA) officially retired SAS 70 audits last year.

SAS 70 audits, as those familiar with Sarbanes-Oxley Act compliance know, served as the primary standard for assessing an external service provider’s internal controls as they relate to the integrity of their customers’ financial reporting statements under SOX Section 404. The standard eventually was used as much broader certification of assurance, which is where things start to get hazy.

In an effort to better match its standards with their actual business use, the AICPA replaced SAS 70 with a new attestation standard, Statement on Standards for Attestation Engagements (SSAE) No. 16.

This new attestation standard is commonly referred to as SSAE 16, or as Service Organization Control 1 (SOC 1). Just like SAS 70, SOC 1 comes in two varieties (Type 1 and Type II), and it is not to be confused with SOC 2 and SOC 3, two other new releases from the AICPA that apply to broader controls, including those related to data security and privacy. SSAE 16 is an attestation standard, which provide guidance on reporting related to a broader range of subjects than auditing standards (like SAS 70), which focus on audits of financial statements. Of course, the distinction between auditing and attestation standards, as a leading governance, risk management and compliance (GRC) analyst recently pointed out, is “irrelevant for the practical purposes of end-user organizations and their service providers.”

Got that?

If not, you’re hardly alone. The change has caused concerns among service providers of all kinds. This is not surprising, given the fact that SAS 70 audits can cost small to mid-sized vendors in the neighborhood of $20,000 to $50,000 per year, not to mention two weeks or more of disruption. The change also raises questions among the managers who hire these vendors and the internal auditors and risk managers who monitor these relationships from a risk and compliance perspective.

Addressing these concerns and questions begins with understanding why the AICPA replaced SAS 70 and concludes with a highly relevant question end-user organizations should ask their service providers.

Why SAS 70 Was Put to Rest

Blame the confusion on the (necessarily) technical nature of the new standard as well as what the AICPA considered the widespread misuse of SAS 70, which had become a de facto “certification” for data centers and other vendors housing company information.  SSAE 16/SOC 1 replaces SAS-70 for several reasons, including the following:

• It’s what the AICPA does. Since the middle of the 20th Century the AICPA and, more recently, the Public Accounting Oversight Board (PCAOB) have issued more than a dozen standards related to the internal controls of service providers. SSAE 16 simply represents the next phase of the “standards evolution,” and a timely revision at a time when the importance of controls related to data security and privacy has increased.
• International convergence. SSAE also reflects a larger ongoing effort to converge U.S. auditing and attestation standards with those put forth by the International Auditing and Assurance Standards Board.
• False advertising. Before the standards change, many providers were advertising having attained a SAS 70 “certification” to help sell the integrity of their offerings to customers. SAS 70, the AICPA has asserted, was not intended to be used in this manner. This misuse irked the AICPA, which understandably may have been concerned about liability issues related to a SAS 70’s growing use as a broader certification data centers and other providers used to demonstrate that they protect client data.

Alternatives to Checking the Box

Thanks to the widespread use of cloud-related services, more companies want to assess how a broader range of service providers protect their data. Until recently, many end-user organizations asked a simple question to address this need: “Do you have a SAS-70?”

If the answer was yes, the buyer checked a box.  The guidance related to assessing controls at service organizations strongly dissuades this checklist approach. In candid moments many service providers would admit that they appreciated the checklist approach: it was straightforward and negated the need for lengthy discussions about which auditing or attestations they prefer.

Currently, there are a dozen or more alternatives to SOC 2 and SOC 3 audits available globally, including the Common Assurance Maturity Model (CAMM), International Standards Organizations (ISO) standards, and the Financial Institution Shared Assessment Program. Tools like the Cloud Security Alliance’s Controls Matrix (CCM) may help a service provider define a single set of controls that maps to the requirements of many of these different frameworks and standards.

In many, but not all, cases, the post-SAS-70 approach should be relatively straightforward. Companies that required a SAS 70 Type I or II audit for reporting on internal control over financial reporting (often for service providers whose user organizations are subject to Sarbanes-Oxley compliance) will now need their service providers to complete a SOC 1 Type I or II attestation.  Information technology service providers that previously relied on SAS 70 to demonstrate assurance to their customers may consider SOC 2 or SOC 3 audits as well as CCM, CAMM, ISO or other related standards.

Those service organizations who support user organizations facing both of these requirements may ultimately find themselves needing to provide both a SOC 1 report and some other form of assurance over data security, integrity, and availability. While that sounds troublesome, it has already been a reality for some service organizations for quite some time. Those needing to provide both SAS 70 reports and Payment Card Industry (PCI) certification come to mind as an easy example.

Regardless of which assurance approach is selected, it is important to keep in mind that any standard represents a component of a larger question, and one that too often gets lost in the post-SAS-70 confusion: “What are you doing to protect my data?”

When customers and potential clients ask me that, for example, I explain that we use the Cloud Security Alliance Controls Matrix framework, which we are audited against to ensure that we’re protecting data in practice as we say we are doing in theory. This type of response, and the constructive discussions it fosters, are neither melodramatic nor confusing, which is exactly what most managers want and expect of their service providers.

Final Takeaway

While there’s no longer one go-to standard, common sense and the right questions to your service provider will serve you best.

About the Author Dan Zitting, Vice President, Product Management & Design, is responsible for product management, design, and user experience for ACL’s industry-leading software products. Dan’s previous experience has been in the audit, risk and assurance industry. After working for several years at Ernst & Young, he co-founded the CPA firm Linford & Company LLP, which provides audit services to global clientele. While running his own practice, he developed a web-based software for auditors to meet his team’s needs. As demand for this software increased, he founded Workpapers.com which was acquired by ACL in late 2011. Dan is dedicated to the advancement of productivity enhancing technology for the audit profession and is a three-time winner of the CPA Practice Advisor Magazine’s 40 under 40 and Readers’ Choice awards. Dan is a Certified Public Accountant, Certified Information System Auditor and Certified Information Technology Professional. He holds a Bachelor of Science from Colorado State University and a Master of Science from the University of Notre Dame.