Many companies receive a SOC 1 audit. You may know this report by its former name, SAS 70 (a standard that was retired in 2011). These reports typically come out once a year, but may be issued every six months. While most organizations recognize the need to request these reports, the reports are often not properly reviewed and evaluated or well understood. We get it – the reports are lengthy and contain a lot of “auditor speak.” So, what do you do with the report once it has been received (other than give it to your internal and external auditors)? We’ll dive into that, but first, a little history on the evolution of these reports.
What Is “SAS 70” and Does It Still Exist?
We are often asked, “Is SAS 70 the same as a SOC 1?” and “What is SAS 70 called now?” The answer is, to some degree, yes, they are more or less the same, but not entirely. Statements on Auditing Standards (SAS) 70 is considered a legacy auditing standard that certified public accountants (CPAs) used to provide assurance over a service organization’s internal controls through the form of a report that could be provided to the service organization’s clients and business partners.
The purpose of the SAS 70 report was to address the increase in outsourcing of critical business functions to third-party service providers, such as payroll processing, data hosting, health claims processing, etc. The classic example of this from the 1990s/2000s was ADP Payroll. Those of you who worked in corporate accounting or an HR department during that time may have outsourced payroll processing to ADP. Since payroll is typically a material line item in a company’s balance sheet, ADP would have an auditor issue a SAS 70 report over its payroll processing services so that companies using its services would have assurance over the related controls that impacted their own financial reporting.
What Replaced SAS 70 in 2011?
The SOC 1 report was born during the evolution of service organization auditing in 2011, when the American Institute of Certified Public Accountants (AICPA) retired the SAS 70 and replaced it with Statement on Standards for Attestation Engagements (“SSAE 16”). The AICPA then updated and clarified SSAE 16 to reflect the evolving approach to internal controls being taken by companies in varying industries; namely, an increased focus on management/entity-level controls, risk assessment and management, and monitoring of subservice organizations (vendors). The new standard was codified as SSAE 18. The Clarified Attestation Standards include the commonly known Service Organization Control (SOC) reports: SOC 1 and SOC 2, and the lesser-known SOC 3 (more on that in a minute). This effectively retired the report previously known as “SAS 70”. A full summary of further iterations of the attestation standards can be found on the AICPA’s website, but the main takeaway from all of this is that SAS 70 is out, and has been for a long time, and SOC 1 is in. If one of your vendors/subservice organizations is still touting their “SAS 70 compliance”, this is an immediate red flag, as their approach to compliance is quite outdated.
Who is Required to Have a SOC 1?
We’ve previously written about the differences between SOC 1 and SOC 2 reports, and have a downloadable SOC 1 & SOC 2 guide available for your team. We’ve also written additional blogs that go into more detail on what comprises a SOC 1 and a SOC 2, but many people still ask, “What is the difference between a SOC 1 and a SOC 2?” As a reminder:
- A SOC 1 report is most appropriate when reporting on internal controls over financial reporting.
- A SOC 2 report is most appropriate when reporting on controls relevant to the Security, Availability, Confidentiality, Processing Integrity, and/or Privacy of a system (also known as the Trust Services Criteria).
You can find more information on the differences between a SOC 1 and SOC 2 report on the AICPA’s website, which also includes a summary of the less common SOC 3. The SOC 3 report is designed to be a summary version of the SOC 2 report, and is used when a service organization has a need for broad distribution of its report. Because there are restrictions around sharing SOC reports, some companies opt for the higher-level summary version of a SOC. It’s relatively uncommon, and you should always discuss whether a SOC 2 vs a SOC 3 report is a good option for your organization with your auditor.
I Received a SOC Report, Now What?
If you receive a SOC report, that means you’re either the service organization (the company being audited) or the user entity (client or business partner of the company being audited). Even if you were audited as the service organization and have a general sense of all the areas your auditor covered to compile the report, navigating the full SOC 1 report can still be overwhelming. The first thing to understand is that five dedicated sections comprise a standard SOC 1:
| Section Reference | SOC Report Section Title | Description |
|---|---|---|
| Section I* | Independent Service Auditor’s Opinion | This is the overall audit conclusion issued by the auditor (qualified vs. unqualified opinion). |
| Section II* | Management’s Assertion | This is the responsibility of the service organization’s management and asserts that the description of the system is fairly presented and controls were in fact designed and operating as described within the report. |
| Section III* | Description of the System and Controls | Also, the responsibility of management, this section describes in detail the system, scope of services, and the relevant processes and controls that are being audited. |
| Section IV* | Independent Service Auditor’s Description of Tests of Controls and Results | This is the meat of the report, where the auditor outlines management’s controls, the control tests performed by the auditor, and the results of testing. If any controls were not designed or operating effectively, they would be called out here as an “Exception.” |
| Section V* | Other Information Provided by Client That Is Not Covered by the Service Auditor’s Report | This section is included as an opportunity for the service organization to include other relevant information not subject to the auditor’s procedures. Because this section is unaudited, a user entity should not place reliance on the statements made in this section. A service organization will often use this section to describe its Disaster Recovery Program or respond to any exceptions noted in Section IV. |
Critical Areas & Common SOC Audit Red Flags
Now that you understand the sections that comprise a SOC 1 report, let’s talk about critical areas within those sections and common red flags to look for. Note that this is generally written from the perspective of the user entity, but it can also help a service organization deconstruct a SOC 1. We suggest focusing on the following components when reviewing audit reports:
- Accounting Firm: The name of the accounting firm is located in Section I. Check with the firm’s state licensing board to confirm they are a licensed CPA firm and to ensure they can perform a SOC audit. Sadly, a surprising number are non-CPA firms, which in most states, including Colorado, is illegal.
- Audit Opinion: Again, this is the auditor’s independent opinion on the service organization’s ability to achieve the stated criteria. You want to see an unqualified opinion – if it’s qualified, that means the auditor identified some piece of the criteria that was not achieved (i.e., significant exceptions were identified). If the report is qualified, a conversation with the service organization is warranted.
- Management’s Assertion: As we explained above, management is required to include its written assertion in the report stating the report’s accuracy. If it’s missing, a conversation with the auditor is warranted.
- Location: Service organizations often have multiple locations, which is to be expected in the global economy. Make sure the report and audit testing cover the locations in which the service organization is performing services for your company. If it is not obvious, ask the service organization to clarify. A service organization passing off narrowly scoped audit reports is more common than you might think. Companies do it to save costs, and auditors agree to obtain work, but the public suffers.
- Report Dates: More than a few service organizations try to pass off old reports as current reports. Make sure the subservice organization provides a current report.
- Processes, Controls, People, & Systems: The processes/controls, as well as the people and systems that support the processes, should be adequately described in the report. Make sure there is sufficient detail so you can understand what the service organization is doing and what they are not doing. If a key control/process (e.g., information security) is not described in the report, ask the service organization about it.
- Complementary User Entity Control Considerations (CUECs): The one is a mouthful, but these are simply controls that the service organization is calling out as a potential responsibility for the user entity. If you’re the user entity, you should consider the relevance of the stated CUECs to your environment, and if a CUEC is deemed relevant, be sure you’ve identified and implemented internal controls to address it. For example, the service organization often does not perform user administration for its clients’ users. In this case, the user entity would be responsible for identifying controls over their users’ access (access approvals, access termination, access reviews, provisioning according to the principle of least privilege, etc.).
- Complementary Subservice Organization Controls: Also known as CSOCs, these are controls that the service organization has identified as a responsibility of its service organization; that is, the subservice organization. This is often the service organization’s hosting provider, such as Amazon Web Services, Microsoft Azure, or Google Cloud Platform, and is meant to identify the processes that are under their control, such as physical and environmental security controls in the case of a hosting organization.
- Extent of Testing: Because SOC 1 reports are attestation engagements, auditors are required to perform audit procedures beyond inquiry (ie, asking questions) and observation. The auditors are required to perform a significant part of the examination through inspection, and, where necessary, re-performance procedures.
- Results of Testing: You’ll want to review Section IV to see whether any control exceptions were identified, and if so, understand the impact on your organization. Some control exceptions are minor and are explained by the service organization in Section V/Section VI. However, it’s common for a noted exception to trigger a discussion with the subservice organization in order to better understand why the audit failure occurred, the impact, and what the service organization is doing to correct it.
Putting It All Together: SAS 70, SOC 1, & What to Do Next
Now that you have a better understanding of the evolution of SOC reports and the components that comprise a SOC 1 report (formerly SAS 70) – go forth and read that report! After all, it’s only 50 or more pages – easy reading. As always, you can reach out to Linford & Company for all your audit and reporting questions.
This article was originally published on 10/27/2020 and was updated on 5/20/2026.
