Security compliance Designing security programs Security compliance Designing security programs SOC 2 SOC 1 SOC 3

The difference between SOC 1, SOC 2, and SOC 3

  • copy-link-icon

    Copy URL

  • facebook-icon
  • linkedin-icon

SOC stands for System and Organization Controls and refers to a group of attestation reports from the AICPA (the governing body for CPA firms in the United States). Any organization that offers outsourced technology services is likely to be asked to provide a SOC 1 or SOC 2 report. These organizations are referred to as service organizations. The AWS Cloud, Azure, and data centers are common examples. 

SOC 1 and SOC 2 reports differ in scope, despite the fact that they are frequently confused due to their almost identical names. A SOC 1 audit and report is focused on financial control objectives for the services being provided, whereas a SOC 2 audit and report is focused on how the organization's operations and compliance processes meet the AICPA’s Trust Services Criteria (discussed below).

There is also a SOC 3 report which is a public-facing version of the SOC 2 report. Some organizations will make their SOC 3 report available to the wider public because it omits sensitive or proprietary details about the operation of its system or controls.

  • SOC 1 focuses on both business and IT objectives.
  • SOC 2 reports on internal controls across the 5 Trust Services Criteria: security, availability, confidentiality, processing integrity, and privacy.
  • SOC 3 is a public-facing version of SOC 2.

A SOC 1 audit includes the testing of a service organization’s controls that are relevant to their end customers' financial statements. It is up to the service organization to identify the key control objectives for the services they provide to their end clients. Objectives are selected to provide reasonable assurance over some element of the service being provided.  For example, a payroll service organization may address access to customer data files or the integrity of key calculations. These control objectives relate to both IT processes and business processes at the service organization. A payroll service provider is a typical example of an entity that would issue a SOC 1 report. 

Companies moving forward with the SOC 1 process, can choose to get a Type 1 or a Type 2 report. A Type 1 (also commonly referred to as Type I) demonstrates the proper design of controls as of a point in time. A Type 2 (or Type II) further demonstrates that controls are operating effectively over a period of time.  

  • Type 1 is a point in time audit focusing on the design of controls.
  • Type 2 is a period-of-time (typically 12 months) audit that focuses on the design and operation of controls.

Users of a SOC 1 include executives at an organization using the services, the financial auditors of the organization, or the compliance team at the end organization.

The focus of a SOC 2 report and audit is on a service organization's internal controls relevant to the security, availability, processing integrity, confidentiality, and/or privacy (collectively referred to as the Trust Services Criteria) of customer data. The security criteria, also known as the Common Criteria, is the baseline for a SOC 2, and organizations can choose to add on any of the other Trust Services Criteria. 

Like the SOC 1, the SOC 2 can also include either a Type 1 or a Type 2 audit. A type 1 is a point-in-time snapshot where an auditor is assessing the design of your organization's controls. A type 2 audit includes an assessment of the effectiveness of the same controls over a longer time period, anywhere from three to 12 months. A 12-month type 2 audit period is standard. 

Users of a SOC 2 include procurement department staff and end-user IT compliance staff assessing the suitability of their vendors’ IT practices.

It is important to note that the SOC 2 isn't a certification, but an attestation report. An independent CPA provides an opinion on the reasonableness of the design and operation of controls and "attests" whether the SOC 2 criteria have been met. 

Typically a SOC 2 is requested by an end customer as part of their procurement process. It is not uncommon to see SOC 2 alongside ISO 27001 or other frameworks in contractual language. While many companies reactively pursue a SOC 2 audit and report to meet procurement requirements, savvy organizations proactively pursue SOC 2 because it can be a market differentiator, opening up revenue opportunities. 

How Strike Graph speeds up SOC 2 compliance

Regardless of whether you are being reactive or proactive, Strike Graph can help speed up SOC 2 compliance efforts. Our customers start by completing a risk assessment that right-sizes their compliance efforts. The outcome of the risk assessment is a mapping of your existing controls to the SOC 2 framework and insight into what needs to be completed to be ready for an audit.  

Keep up to date with Strike Graph.

The security landscape is ever changing. Sign up for our newsletter to make sure you stay abreast of the latest regulations and requirements.