SSAE 16, SOC, and SAS 70. What’s the difference?

SAS 70

Many folks in large United States-based organizations have heard of (or directly experienced) a SAS 70 report.  The AICPA (American Institute of Certified Public Accountants) introduced the concept in the early 1990s.  A SAS 70 provides guidance to auditors when evaluating the internal controls of a service organization and issuing an independent report of those controls.  Throughout the 1990s and early 2000s, the use of a SAS 70 to test and validate internal controls became more and more popular.  It became clear over time that organizations were using SAS 70s to evaluate various components of an organization.  As a result, the AICPA worked to release a new set of standards that not only would meet international expectations of standardized reporting, but would also allow organizations to evaluate controls that were not directly related to financial reporting.

SOC Reports

As the AICPA worked on a more universally accepted set of international accounting standards, the organization created an entirely new framework that has come to be known as SOC reporting, where SOC stands for Service Organization Control.  The AICPA describes a “service organization” (SA) as “an organization or segment of an organization that provides services to user entities”.  “User entities” are users of the service (e.g. the customer who buys the service from the service provider).  These definitions are outlined in the AICPA AT 801.

The AICPA outlined three types of SOC reports.  The following table (from the AICPA) outlines the differences in the three types of SOC reports and who they are intended for:

Who The Users Are Why What
SOC 1 Management of the service organization, user entities, and user auditors Audit of Financial Statements Controls relevant to user entity financial reporting
SOC 2 Management of the service organization, user entities, regulators, others Governance, risk, and compliance programs, oversight, due diligence Concerns regarding a system’s security availability, processing integrity, confidentiality, or privacy
SOC 3 Any users with need for confidence in the security, availability, processing integrity, confidentiality, or privacy of a service organization’s system. Marketing Purposes, detail not needed Report and seal on controls

Audit vs. Attest

When creating the SOC reporting guidance, the AICPA emphasized that this new framework is an “attestation” rather than an “audit”.  So what’s the difference?  In the case of a traditional “audit” in a financial sense, numbers (facts) are evaluated to show that all monies are accounted for and the organization’s financial resources appear appropriate (accounted for, adds up correctly, necessary taxes paid, etc).  In the case of a SOC report, the intention is to evaluate the overall “system” of controls.  As such, the AICPA wanted to emphasize auditors are “attesting” to the existence (and perhaps effectiveness) of a complete set of controls (what they call “the system”).   This means that auditors are evaluating the system and attesting to it as a whole, rather than the more traditional financial audit of data within the system.  Also introduced in the SOC report is the requirement of a written assertion of the system provided by the organization’s management.

SOC 1 (SSAE 16)

SOC 1 is a report focused on the financial controls of an organization.  SOC 1 reports as based upon the Service Auditors to the Statements on Standards for Attestation Engagements No. 16 (SSAE 16) framework, which was formally issued in 2010; this is why SOC 1 reports are often called “SSAE 16 reports”. SOC 1 reports retain the original intent of a SAS 70 report by focusing on an organization’s internal controls over financial reporting, and have effectively replaced the traditional SAS 70 report since 2012.

SOC 2 and SOC 3

Since the SAS 70 framework was more broad, many organizations were using the reporting standard to evaluate non financial-based organizational controls.  To meet this need, the AICPA introduced the SOC2 and SOC3 reporting framework based upon AT 101 reporting standards.  These reports are focused around a set of criteria called the Trust Services Principles (TSP) which focus on:

  • Security – The system is protected against unauthorized access (both physical and logical).
  • Availability – The system is available for operation and use as committed or agreed.
  • Processing integrity – System processing is complete, accurate, timely, and authorized.
  • Confidentiality – Information designated as confidential is protected as committed or agreed.
  • Privacy – Personal information is collected, used, retained, disclosed, and destroyed in conformity with the commitments in the entity’s privacy notice and with criteria set forth in generally accepted privacy principles issued by the AICPA and CPA Canada.

These criteria are organized into 4 broad categories in the 2009 version of the TSP guide:

  • Policies – The entity has defined and documented its policies relevant to the particular principle.
  • Communications – The entity has communicated its defined policies to responsible parties and authorized users of the system.
  • Procedures – The entity placed in operation procedures to achieve its objectives in accordance with its defined policies.
  • Monitoring – The entity monitors the system and takes action to maintain compliance with its defined policies.

Service organizations can select which criteria are applicable to their products or services.  As such, a SOC report may include only select criteria.

A SOC 2 report is a detailed report of an organization’s controls for internal use by management and the service organization’s customers.  A SOC 3 report is a high level report that covers the same subject matter as SOC 2, but does not detail the controls and the results of testing.  A SOC 3 report is meant for public release, and is the only type of report that a firm may publicly release.

Clients are asking our organization for a SSAE 16, SAS 70, or SOC 2/3 report.  What can I do?

Oftentimes, service organizations must educate their customers.  Since many service organizations offered SAS 70 reports, customers are used to asking for that type of report.  Worse, because they were used to SAS 70 reports, they oftentimes believe they now want a SSAE 16 report from a service organization.  Instead, customers oftentimes are looking for a SOC 2 or SOC 3 style report.  SSAE 16 (SOC 1) reports are helpful to show that a service organization has strong internal financial controls, but normally do not cover any of the products/offerings a service organization provides the end user.  As such, customers must also often be educated in what type of SOC report they’re actually looking for.

If you’re a service organization (SO) and you don’t currently have a SOC report available to your current or perspective client base, you may be missing out on potential business.  More and more customers are asking for SOC reports from their SOs, and often leave those that do not have or provide them for other SOs that do.

Do you own or work at an organization that provides services?  Do you want to learn more?  Each service organization has specific needs based upon what they provide to their customers.  O’Connor and Drew’s IT Audit division can help your organization get a better idea of what is involved in preparing for a SOC report, what type of report you might need, and how to get started.

Jake McAleer, CISA, CCNA

About Jake McAleer, CISA, CCNA

Jake is the IT Audit and Security Manager at O'Connor & Drew, P.C. where he focuses on security and compliance. His previous positions include internet infrastructure services, IT audit in the financial industry, and systems work with defense contractors.



Jake McAleer, CISA, CCNA
Author: Jake McAleer, CISA, CCNA
Jake is the IT Audit and Security Manager at O'Connor & Drew, P.C. where he focuses on security and compliance. His previous positions include internet infrastructure services, IT audit in the financial industry, and systems work with defense contractors.