SOC Reports: Who Pays?

By Milton L. Petersen  |  Posted 11-07-2011

Service Organization Control Reports Demystified

For years, provisions requiring "SAS 70" reports have frequently been included in technology and outsourcing contracts as a way to help assess risks associated with service providers' internal controls. Such reports have been produced pursuant to the Statement on Auditing Standards (SAS) No. 70, issued in 1992 by the Auditing Standards Board (ASB) of the American Institute of Certified Public Accountants (AICPA).

In fact, SAS 70 provisions and reports were commonly misused and stretched far beyond their originally intended focus on controls that affect financial reporting. They morphed into an attempt to obtain information and assurances on a service provider's operations and compliance.

With the increasing popularity of cloud computing and the ongoing shift to a network-centric world, the need for enterprise customers to obtain reliable information and assurances about the operations of their service providers has become more intense than ever. To address these concerns, the AICPA recently established a structure of three different types of Service Organization Control (SOC) reports that may be issued by auditors: SOC 1, SOC 2 and SOC 3 reports.

Understanding and appropriately addressing the new SOC reports in your technology-related contracts could provide your organization with important knowledge and insight into your service providers' operations and controls.

SOC 1 reports focus exclusively on a service provider's controls that may be relevant to an audit of a customer's financial statements. These reports are issued pursuant to the Statement on Standards for Attestation Engagements (SSAE) No. 16, Reporting on Controls at a Service Organization. The AICPA issued SSAE 16 in April 2010 as a replacement for SAS 70.

SOC 1 reports, therefore, serve to replace SAS 70 reports, as originally intended, and should be required in technology or service contracts that relate to, or could affect, financial controls.

As with SAS 70 reports, SOC reports can be either:

  1. Type 1 reports, which describe the
controls used by the applicable service
provider; or
  2. Type 2 reports, which not only provide descriptions of the service provider's controls, but also involve a test of the effectiveness of those controls and include the associated test results. Thus, Type 2 SOC reports provide a wide range of information and are generally the type of SOC reports that should be contractually required.

SOC 2 reports are intended to have a broader focus than SOC 1 reports. SOC 2 reports provide detailed information on a service provider's controls that affect the security, availability or processing integrity of the service provider's systems, or the confidentiality or privacy of the customer's information that is processed by those systems. SOC 2 reports may be required to address any or all of the five attributes--security, availability, processing integrity, confidentiality and privacy--that AICPA defines as the "trust services principles."

As with SOC 1, SOC 2 reports may be either Type 1 or Type 2, with Type 2 reports providing additional information and test results that will likely be useful to most customers. SOC 2 reports are produced and performed under the AICPA's attestation standards, specifically, AT Section 101, Attest Engagements.

SOC 2 Type 2 reports will likely be very useful to customers in outsourcing and cloud computing relationships, where assurances regarding the service provider's operations and compliance are needed. SOC 2 Type 2 reports will probably be especially important in heavily regulated industries such as health care and financial services, where information and assurances regarding the trust service principles are even more critical.

As both SOC 1 and SOC 2 reports are specific to a given customer, it will be interesting to observe how contractual trends emerge with respect to whether the service provider or the customer will bear the costs of audits to produce these reports.

SOC Reports: Who Pays?

Costs of SAS 70 audits were often borne by the service provider, except that the customer was sometimes responsible for the cost of any additional audit procedures required by, or specific to, the customer. Perhaps a similar cost-sharing methodology--in which the customer bears the cost of additional audit procedures specific to the customer, but the service provider bears the bulk of the cost--will develop as the norm for contractual provisions regarding SOC 1 and SOC 2 reports.

While SOC 1 and SOC 2 reports are generally specific to a given customer, SOC 3 reports are "general use" reports that do not focus on any particular customer.
SOC 3 reports are similar to SOC 2 reports, however, in that they may address any combination of the trust services principles.

SOC 3 reports covering all trust services principles might be very useful to a customer in its procurement or vendor selection process, providing insights into risks associated with different service providers. Similarly, service providers might use
SOC 3 reports (and the AICPA's associated SOC 3 seal) as marketing tools.

Requiring the new Service Organization Control reports--whether in your procurement process or in your technology-related contracts--could be very helpful in understanding the potential risks associated with technologies such as cloud computing.

SOC Framework: 10 Action Items

  1. Educate yourself on the new AICPA Service Organization Control (SOC) framework.
  2. Learn about the Trust Services Principles (TSP) framework.
  3. Consider purchasing a SOC 2 audit guide.
  4. Learn about AT Section 101.
  5. Understand the true technical differences between SOC 1 and SOC 2.
  6. Understand the requirements for a des-cription of the "System."
  7. Learn about the written statement of assertion.
  8. SOC 2 is criteria-based, not control-objective based.
  9. The adoption of SOC 2 is moving more slowly than expected.
  10. SOC 2 and SOC 3 are similar in a number of ways.

Source: NDP Accountants & Consultants, "SOC 2 Reporting Framework and the Top 10 Items You Need to Know About," September 2011

About the Author

Milton L. Petersen is an attorney whose practice focuses exclusively on information technology-related transactions and issues. He is a partner in the Information Technology Practice Group at the law firm of
HunterMaclean in Savannah, Ga., and may be reached at 912-238-2629 or