Deconstructing SOC 1 (f. SAS 70) Reports

Many companies receive a SOC 1 audit (Note: while SOC 1 has been the common terminology for many years now, you may still think of this report as SAS 70, which SOC 1 has replaced). These reports typically come out once a year, but may be issued every six months. While most organizations do a good job of recognizing the need to request these reports, often they are not properly reviewed and evaluated or well understood when received. 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 the internal and external auditors)? We’ll dive into that, but first, a little history on the evolution of these reports.

 

What is a SAS 70 & What is It Called Now?

History of SAS 70 / SOC 1

Enough acronyms for you? Auditors love acronyms, so it’s no surprise that there are so many to describe the work we do. In reality, these acronyms represent the evolution of service organization auditing, which started with the Statement on Auditing Standards 70 (“SAS 70”).  Eventually, the American Institute of Certified Public Accountants (AICPA – another acronym for you!) retired SAS 70 and replaced it with Statement on Standards for Attestation Engagements (“SSAE 16”).

This was essentially the birth of the (Service Organization Control) SOC report. In 2017, the AICPA updated and clarified SSAE 16 to reflect the evolving approach to internal control 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). Furthermore, in September 2020, the AICPA’s Auditing Standards Board released SSAE 21, which updated AT-C Section 205 pertaining to SOC 1 examinations.

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 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 report. 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 their 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 went through the audit as the service organization and have a sense of all the areas your auditor covered to compile the report, it’s still overwhelming to most people trying to navigate the report. The first thing to understand is there are five or six standard sections that 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, it would be called out here as an “Exception.”
Section V	Other Information Provided by Trustly 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 it’s 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 their Disaster Recovery Program or respond to any exceptions noted in Section IV.

 

Critical Areas and Common 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 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, 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 their 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 covers 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 name 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 CUEC to your environment, and if it’s relevant, be sure you’ve identified and implemented internal control 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 (CSOCs): Another long name, another acronym.  But, CSOCs are important. These are controls that the service organization has identified as a responsibility of their 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.
• 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.

Summary

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.