Sometimes the best way to understand something is to see an example. Read on to learn what a SOC 2 report is and how to interpret one.
SOC 2 compliance is a vital tool for building trust with potential business partners, and it is increasingly required for software-as-a-service (SaaS) providers, companies that provide business intelligence or analytics, and financial services institutions. The SOC 2 report, or attestation, is the pot of gold at the end of the SOC 2 audit journey. These reports — issued by independent CPAs — affirm that a company’s data management practices meet criteria.
When complete, the SOC 2 report demonstrates how well a service organization has implemented SOC 2 security controls across the five Trust Services Criteria (TSC) laid out by the AICPA:
SOC 2 reports all share a similar structure, but they can vary based on industry, audit criteria, and even the individual SOC 2 auditor. There will always be at least four sections (sometimes five) in addition to a cover page that calls out which criteria are in scope. There also could be exceptions, omissions, or disclaimers that would be cause for concern.
So what does an actual SOC 2 report look like? The AICPA offers an illustrative SOC report layout that’s a great reference tool for those trying to make sense of SOC 2 auditing and reporting. We’ll go through this AICPA example section by section.
The management assertion section is a letter from company leaders that includes a summary of the product and services as well as the structure of IT systems, teams, and controls. It provides the reader with a list of facts and assertions, or statements, made by the service organization’s management related to the systems. Management assertions are drafted by the service auditor who will provide the document to an executive at the organization to sign. Needless to say, the person signing the assertion should read the document carefully to ensure that all statements in it are true.
Also known as the report from the auditor, this section usually follows the structure of the AICPA example report. Though a SOC 2 audit is not technically a pass/fail process, a clean or unqualified opinion is generally considered a successful outcome.
In addition to the desired outcome of an unqualified opinion from the auditor, there are three other possible outcomes. The four types of auditor opinions are:
Unqualified — This means that the controls tested as part of the report are designed and operating effectively. An unqualified opinion can still have issues and exceptions. When these appear in an unqualified opinion, then the organization and its auditors were able to mitigate or remediate the risks presented by the exceptions, meaning the control in place was deemed effective. Page seven of the AICPA example report is an example of an unqualified opinion.
Qualified — A qualified opinion states that a control or controls are not designed and/or operating effectively and that the issues identified are enough to label one or more controls ineffective. Qualified opinions come about frequently and, while not as problematic as an adverse or disclaimer opinion, they do indicate that one or more controls in place will require improvement.
Exceptions are the result of the following circumstances:
Misstatements referring to an error or omission in the description of systems or services
Deficiency in the design of a control that occurs when a control necessary to achieve the control objective or criteria is missing or an existing control is not properly designed
Deficiency in the operating effectiveness of a control that means a properly designed control does not operate as designed or the person performing the control does not possess the necessary authority or competence to perform the control effectively
When these exceptions occur, the auditor will provide a high-level statement to explain why they qualified their opinion. This language might look like one of the following sentences:
“The description does not fairly present the system that was designed and implemented throughout the audit period.”
“The controls related to the control objectives stated in the description were not suitably designed to provide reasonable assurance that the control objectives would be achieved if the controls operated effectively throughout the audit period.”
“The controls tested, which were those necessary to provide reasonable assurance that the control objectives stated in the description were achieved, did not operate effectively throughout the span of the audit.” (SOURCE: Reporting on an Examination of Controls at a Service Organization Relevant to User Entities’ Internal Control Over Financial Reporting Guide)
Adverse — This is a suboptimal outcome, because the auditor reports the company’s systems and controls can’t be trusted. An adverse opinion will cite multiple exceptions or instances of controls not working as intended. The auditor will lay out the points of failure in detail, using language similar to that of a qualified opinion.
Unlike the section bearing their name, management actually writes the system description section for review by the auditor. It describes the following:
This section can be challenging for many companies, because director-level personnel and those in the C suite often don’t have a lot of experience writing IT compliance reports. Strike Graph’s system description tool takes the stress out of this step with its audit-ready table of contents, clear guidance, and real-world example content.
This section is prepared by the auditor and provides support for their opinion. Every control identified by management in the preceding section is tested. This section is where the controls are described, and the results of the testing revealed. The description will include applicable trust service categories, test criteria, any related controls, and tests of controls. These are followed by the results of those tests.
The auditor always includes information about how tests were performed along with a table of results.
This optional section can appear at the front or back of the service auditor’s report. It’s designed to provide additional relevant information not covered in the report itself, and therefore references elements not tested by the auditor.
Management can include this section to provide the following types of information:
This is where things get easier. Strike Graph’s compliance platform is designed to simplify and speed the complex SOC 2 process.
Our initial risk assessment right-sizes the process for your company’s unique circumstances so you don’t waste time and resources fulfilling requirements that don’t actually apply to you. We ease the control and evidence process with our library of SOC 2-ready controls and smart automation that collect evidence for you. And, when you reach the report stage, our systems description tool walks you through step by step so you have the documentation you need to close the deals that will grow your business.