The SOC 1 vs. SOC 2 discussion is well under way, thanks in large part to the American Institute of Certified Public Accountants' ( AICPA) launch of their new service organization reporting platform, known as the SOC framework. Officially, SOC standards for "Service Organization Control", which allows qualified practitioners (i.e., licensed and registered Certified Public Accountants) to issue SOC 1, SOC 2, and/or SOC 3 reports. With the SSAE 16 standard (which is used for issuing SOC 1 reports) effectively replacing the longstanding SAS 70 auditing standard for reporting periods ending on or after June 15, 2011, there's been much debate regarding SOC 1 vs. SOC 2, specifically, when are they applicable, what is the respective scope for each, and what similarities or differences do they each share.
Service Organization Control (SOC) 1 reports are to be conducted in accordance with Statement on Standards for Attestation Engagements (SSAE) No. 16, the AICPA "attest" standard that, not only replaced SAS 70, but was intended to reinforce SAS 70's true intent, which was an audit conducted over "internal controls over financial reporting", more commonly known as the ICFR concept. Because SAS 70 strayed heavily from its intended use, the newly formed SOC framework placed great emphasis on the ICFR component for service organization reporting, thus advocating service organizations to opt for a SOC 1 (for which you can obtain an SSAE 16 Type 1 or Type 2 report) only if your organization has a true relationship and/or nexus with ICFR.
To meet the growing needs of the ever-expanding technology companies who are classified as service organization for SOC reporting, the AICPA put forth the SOC 2 framework, a reporting option specifically designed for entities such as data centers, I.T. managed services, software as a service (SaaS) vendors, and many other technology and cloud-computing based businesses. And within the SOC 2 framework is a comprehensive set of criteria known as the Trust Services Principles TSP) that are composed of the following five (5) sections:
• The security of a service organization' system.
• The availability of a service organization's system.
• The processing integrity of a service organization's system.
• The confidentiality of the information that the service organization's system processes or maintains for user entities.
• The privacy of personal information that the service organization collects, uses, retains, discloses, and disposes of for user entities.
Thus, the vast majority of service organizations that underwent SAS 70 compliance in recent years would "technically" fall under scope for a SOC 2 report, leaving the SOC 1 framework to organizations with a true ICFR relationship, such as those in financial services and other financially driven industries.
With that said, listed below is a brief description of SOC 1 and SOC 2 and the important components of each respective reporting platform:
Professional Standard used to Perform the engagement:
• SOC 1: SSAE 16, Reporting on Controls at a Service Organization.
• SOC 2: AT Section 101
AICPA Publications relating to each applicable SOC Framework:
• SOC 1: Statement on Standards for Attestation Engagements, "Reporting on Controls at a Service Organization" as published by the AICPA in 2010. "Service Organizations: Applying SSAE No. 16, Reporting on Controls at a Service Organization Guide (SOC 1)", as published by the AICPA in 2011.
• SOC 2: Attestation Standards, Section 101 of the AICPA Codification Standards (AT Section 101). "Reporting on Controls at a Service Organization Relevant to Security, Availability, Processing Integrity, Confidentiality, or Privacy (SOC 2)", as published by the AICPA in 2011.
Intended Subject Matter and Applicable Scope:
• SOC 1: Internal Controls over Financial Reporting (ICFR).
• SOC 2: Controls at a service organization that are relevant to security, availability, processing integrity confidentiality, or privacy.
Intended Users of each Report:
• SOC 1: External financial statements auditor’s of the user organization's financial statements, management of the user organizations, and management of the service organization.
• SOC 2: Relevant parties that are knowledgeable about the services provided by the actual service organization and that they have a true and credible need for utilizing a SOC 2 report.
But one's intent often gives in to the political winds at play, which is currently the case with SOC 1 vs. SOC 2 as most service organizations are simply migrating from the SAS 70 auditing standard to the SOC 1 SSAE 16 reporting framework, with little or no regard to the applicability and merits of the SOC 2 framework. Many technology and cloud-based vendors are opting for SOC 1 SSAE 16 compliance and resisting the notion of SOC 2 reporting, as witnessed by Google's recent announcement of SSAE 16 compliance for their app engine, known as Google Apps. If a well-known entity such as Google opts for the technically incorrect SOC framework, yet finds little or no resistance in the marketplace, the notion of SOC 2 gaining any genuine credibility as a viable reporting may not mature anytime soon. This may change, however, as service organizations and user entities alike are beginning to understand the differences between SOC 1 and SOC 2 and their intended uses.
Even if SOC 2 reporting never fully evolves as the AICPA had hoped for, the SOC 1 SSAE 16 framework is still an excellent reporting platform for any type of service organization, regardless of their relationship with the ICFR concept.
If you would like to learn more about SOC 1 and SOC 2 reports and are interested in receiving a competitive, fixed fee proposal, please contact Christopher G. Nickell, CPA at 1-800-277-5415, ext. 706 or email him at .
Author: Charles Denyer