There is a variety of SOC reports that the AICPA has come up with, and each serves its own purposes. In this blog post, we will show you the differences between the three main SOC reports: SOC 1, SOC 2, and SOC 3.

SOC 1, 2, _ 3 Comparison

What This Means For You

SOC 1

When you think of SOC 1, you should be focusing on financial statements. SOC 1’s are intended to discuss the internal controls for financial reporting (ICFR). Think about it this way, if your service has an impact on the financial statements of your customers, then you will likely be looking at a SOC 1. But those financial related controls aren’t the only thing that might be in the report. You may find that you also need to report on some of the things you would find in a SOC 2, like security, confidentiality, etc. Those can be incorporated as well because, in SOC 1, you define the Control Objectives.

Let’s use an example. Let’s say you are a payroll processor service organization. You take your customer’s raw data for payroll, run it through your systems, and produce payroll reports, tax filings, and employee pay stubs for those customers. Payroll is a significant part of your customer’s income statement in their financial statements. So, you may have objectives around the accuracy of calculating those payroll items and how you file taxes with government entities. You also may have objectives related to protecting your customer’s data, which, for example, could be similar to logical access requirements from CC6 in SOC 2. Because there are no prescribed objectives in SOC 1, you would have to determine what all of your objectives for customers are related to your service and include them in the report.

A SOC 1 does have a system description like SOC 2, but the criteria are less than what is required under SOC 2.

SOC 2

For SOC 2, see our pillar page for detail on everything you need to know about SOC 2. The difference is the SOC 2 will not cover those financial objectives because SOC 2 is focused on the Trust Services Categories as they relate to the service commitments you make to your customers. Let’s go back to our example payroll processor again. They might also need a SOC 2 in addition to their SOC 1. In their agreements, they are making commitments to customers around the security and confidentiality of customer data, as well as being available 99.99% of every month. In this case, the security, availability, and confidentiality categories would be in scope for their SOC 2 and can be tested in conjunction with the SOC 1 testing, since both reports are going to share some similarities in objectives.

SOC 3

So what is SOC 3 then? SOC 3 is simply a redacted version of a SOC 2 report. It is still based on the same trust services categories and criteria, but the only thing shown is a redacted version of the system description. There is no Section 4 in the report, which would show details of the controls, the auditor’s testing of those controls, and the results of testing. SOC 3 reports are meant for public use, and many times companies will provide them via their website with no NDA required.

The common elements of all these SOC reports though are an assertion from company management and an auditor’s opinion. The language in those may be different between each of these reports, but the purpose of these sections remains the same.

So which SOC report is right for you?

  • SOC 1 – does your service have an impact on the financial statements of your customers?
  • SOC 2 – are you committing to anything related to the trust services categories (security, availability, confidentiality, processing integrity, privacy)?
  • SOC 3 – do you need a public version of your SOC 2 to display to customers, potential customers, investors, or other interested parties?

Based on the answers to those questions, along with your objectives, you can find your way to the right path for SOC reporting. But don’t do it alone! We here at Bytechek have been dealing with SOC for years and we even participated in the development of the AICPA’s SOC 2 guide. We can help you navigate the journey and figure out how to make compliance suck less for your company.


Did this answer your question?