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.

What is a SOC 2 report?

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:

• Security: How well does a company use tools such as firewalls and multi-factor authentication to protect information from unauthorized access
• Availability: Are systems in place, such as disaster recovery and performance monitoring, to ensure employees and customers can rely on an organization’s application or service to perform as expected and without service interruption
• Confidentiality: Do the access control and encryption protocols in place adequately protect confidential information by limiting access, storage, and use
• Processing integrity: Can an organization consistently verify its systems operate as intended
• Privacy: Does the security infrastructure in place properly leverage encryption and access control tools to adequately protect sensitive user information from unauthorized access?

How is a SOC 2 report structured?

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.

• Section I — Management assertion
• Section II — Independent service auditor’s opinion
• Section III — Systems description
• Section IV — Description of controls and test results
• Section V (If applicable) — Management’s response to exceptions

SOC 2 report example

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.

Section I - Management assertion

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.

Section II – Independent service auditor’s opinion

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.

Section III – System description 

Unlike the section bearing their name, management actually writes the system description section for review by the auditor. It describes the following:

• • Company background
  • Overview of the system (service or product)
  • Key features of the system
  • Principle service commitments and system requirements
  • System boundaries
  • Trust Services Criteria not applicable to system
  • Subservice organizations
  • Relevant aspects of the control environment, risk assessment, information and communications and monitoring
  • Incidents and system changes
  • Complementary User Entity Controls

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.

Section IV - Description of controls and test results

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.

Section V (If applicable) – Management’s response to exceptions

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:

• • Incidents and system changes
  • The organization’s future plans for new systems
  • Key aspects of the control environment not covered in the report that the organization wishes to communicate to its customers and prospects
  • A detailed explanation of the company’s response to a qualified opinion

How do I start the journey toward a SOC 2 report?

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.