Updated: Sep 20
SOC 1, SOC 2, Type 1, Type 2 - It's easy to get confused between these terms. What do they mean? What's the difference?
We often speak to people that use these terms interchangeably and mix them up. Some even making up their own terms like "SOC Level 1" and "SOC Level 2".
The "SOC" standards
The way it works: there's underlying reporting standards that set the groundwork for how to report on a service organisations controls (SOC). You may have seen these referenced in customer due diligence questionnaires: eg. SSAE 18, ISAE 3402, ASAE 3402. They are broadly the same standards. ISAE is the international version, SSAE and ASAE are the US and Australian equivalents.
SOC Type 1 vs. Type 2
Within the standards, there's the concept of a Type 1 Report and a Type 2 Report. For a Type 1, the service auditor reviews the design of controls only, to report on the controls in place at a point in time. That is more like ISO 27001. For a Type 2 the service auditor adds in tests of operating effectiveness, to report on the controls in place over a period of time.
SOC 1, 2, 2+ & 3, are terms rather than standards. They are used to differentiate the focus and purpose of the SOC report. The numbering follows the evolution of how SOC reports have been used in practice.
The initial focus of the SOC standards was on the financial reporting objectives of a third party provider. The purpose was to allow external auditors to rely on the controls of that service organisation without having to audit the controls themselves (for large technology providers that would require multiple auditors doing the same work).
SOC became increasingly relevant to technology providers, and being used by a broader audience than just the external auditors. This was followed by the AICPA establishing a more specific framework focused on technology principles and the "Trust Services Criteria". That became known as SOC 2. The initial focus of financial reporting is still relevant and widely used. It became SOC 1.
The framework used for SOC 2 provides a fit-for-purpose, one-size-fits-all approach for technology providers. However, in some cases the end users of the reports want assurance over additional control principles outside of the technology principles. This may be financial reporting focused objectives, or anything else that is relevant to their specific reliance on the service organisation. That brought about SOC 2+, which is simply the SOC 2 with additional "control objectives" added in the same way that a SOC 1 reports on control objectives.
All SOC 1-2+ reports include a system description. It explains to the end users what the scope of the report is, the services that are being reported on, and what the relevant processes and controls are within the service organisation. That description can include proprietary information that service organisations don't want to share with all of their customers. Large technology providers may have hundreds, if not thousands of business customers. That led to SOC 3, which is a SOC 2 report without the system description. It allows it to be published for broad use, without any sensitive content.
How is this relevant to you?
If you're a technology service provider (SaaS, PaaS, IaaS); you're probably going to be focused on SOC 2. While the likes of Amazon and Microsoft report under SOC 1, 2 & 3, most organisations prefer to focus on a single reporting approach. If you're going to pick one; SOC 2 is the best fit in most cases.
Your clients are usually interested in the Type 2 report that demonstrates the operating effectiveness of your controls. A common approach is to first issue a Type 1 report at the point your controls become complaint with the Trust Services Criteria. That allows an earlier report to be provided before the period of time (3-12 months) has passed. After that period has passed, a Type 2 report can be issued.
If you're looking to see what best meets your requirements or have any other questions, get in touch with us!
To read more about SOC 2, see our other related posts: