SOC 2 report examples

SOC 2 Report Examples for 2024: Insights into Top-Tier Compliance

Wesley Van Zyl

Senior Compliance Success Manager

Summary: A SOC 2 report demonstrates how effectively your business has implemented SOC 2 security controls across the five TSC.

In the world of security compliance, things can get complicated. Even when searching the internet for answers, understanding the technical jargon in the information security industry can be challenging. That’s why we’re here to clarify some aspects of SOC 2 compliance, particularly SOC 2 reports, and their significance for your security posture. Let’s explore what a SOC 2 report is and how to interpret one.

What is a SOC 2 Report?

Getting SOC 2 compliant can be a lengthy and resource-intensive process. However, as you reach the end of the road, you receive the SOC 2 Type II report (or attestation). Your SOC 2 Type II report will prove that your company’s data management practices meet the relevant SOC 2 criteria and requirements over a specific historical period. Independent CPAs issue it after your audit journey and affirm that you are SOC 2 compliant – finally! 

To simplify, a SOC 2 Type II report demonstrates how effectively your business has implemented SOC 2 security controls across the five Trust Services Categories (TSC) laid out by the AICPA.

Need a quick refresher on the five Trust Service Principles? No worries, we’ve got you covered. 

The Five Trust Service Categories

The “trust services criteria” (aka the full list of requirements) are principles established by the American Institute of Certified Public Accountants (AICPA) specifically for service organizations. These “trust services criteria”  provide the basic guidelines to assure that a service organization has implemented the required internal controls over its operations.  They are organized into the following five categories: 

  • Security
  • Availability
  • Processing Integrity
  • Confidentiality
  • Privacy

Each principle includes specific objectives that must be met for an organization to achieve compliance with the standard. An external auditor will examine your organization’s control over one or more of the Trust Service Categories (TSCs) (depending on which one you’ve chosen). The report will then include a detailed description and opinion of the design and effectiveness of your internal controls. To summarize, your SOC 2 Type II report will testify to the strength of your security posture and infosec practices. 

With that said, it’s super important that your report is as robust, accurate, and positive as possible. For that to happen, you need to know what to look for and what the different elements of a SOC 2 report mean. 

How is a SOC 2 Type II Report Structured?

SOC 2 Type II reports may sound complex in theory, but sometimes, all you need to do is look at the practical side. That’s why it’s essential to look at the structure of a general SOC 2 report. Here’s what you need to know. 

Most SOC 2 Type II reports follow a similar structure. The following sections should be included in a SOC 2 Type II report, including a cover page describing the criteria of the scope, any exceptions, omissions, disclaimers, or cause for concern. 

The main sections include the following: 

  • 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 (optional) — Management’s response to exceptions – this section is optional, written from the client’s voice, and not a section audited by the auditor.

For an illustrative example of what your report may look like, check out AICPA’s example here. However, for those who’d like to dig deeper into what these sections entail, let’s keep going. 

SOC 2 Report Sections Explained

Receiving and understanding your SOC 2 report shouldn’t be like deciphering a foreign code. Here’s what you can expect from each section. 

Section 1: Management Assertion

In this section, your company declares that all the information provided in the report is accurate and relevant. Leadership and management also state that they did not omit anything pertinent to the system from their customers. Ultimately, this section plainly states, “We use infrastructure, software, people, procedures, and data to provide the service.”

This section typically provides a general affirmation from leaders/management that the report contains relevant, accurate information and omits nothing that could deceive customers.

Section 2: Independent Service Auditor’s Report

At some point, you’ve got to get graded, right? This is that point – buckle in, folks. Section two mainly concerns the external auditor’s opinion on how well your organization has implemented the controls and complied with the relevant TSCs. For Type II in particular, it’s not just about the implementation; it’s about whether the controls operated effectively over a certain period, demonstrating that they consistently followed these data management practices.

This section will also reveal your auditor’s opinion. Naturally, this is one of the most critical sections. There are 4 types of opinions:

  1. Unqualified Opinion – the auditor is satisfied that your controls are designed properly and are operating effectively.
  2. Qualified Opinion – the auditor found that at least one or more of the controls were not designed properly or that they were not operating effectively.
  3. Disclaimer of Opinion – the auditor is unable to express an opinion, which is often due to insufficient information and evidence provided i.e. scope limitations are pervasive.
  4. Adverse Opinion – Your systems are not reliable and do not provide an adequate degree of information security.


Section 3: System Description

Remember when we mentioned that you don’t have to get into the technical stuff in the management assertion? Well, that’s because it lives here. In this section, management must accurately write down the system description for review by the auditor. If section one was a sneak peek into your organization, this is the deep dive. It covers the finer details about the system(s) – like what it does, what’s included, and what rules it follows. 

Specifically, based on what businesses believe their customers will find relevant, details include: 

  • The types of services provided.
  • The key “service commitments” that they want to demonstrate in the report (e.g., feature sets, specific encryption standards they noted to use, uptime, and user privacy rights commitments).
  • Components in their system (infra, software, people teams, procedures, data) to deliver the service.
  • Any system incidents relevant to the reporting period (e.g., if it was a control failure or impacted a service commitment).
  • Mapping of their controls to criteria
  • Complementary User Entity Controls (CUECs)
  • Complementary Subservice Organization Controls (CSOCs)
  • Disclosure of which areas of TSCs may not be relevant and why (e.g., if they use AWS, then they’re not responsible for control of physical security of production servers hosting their customer data).
  • Significant changes to control design (if any) occurred in the period.

This section is also significant because it’s the part customers will review when deciding whether they can trust the system and its security posture. 

Section 4: Description of Controls and Test Results

The auditor will explain how the controls have been tested in this section. This again provides authenticity to the report and further transparency into the report results. In brief, this section includes control descriptions, testing procedures, and test results. This is usually provided in a table showing how each control did in the tests. Did it pass with flying colors, or did it need some work? Keep in mind that there is no mention of how the control is implemented.  For example, if the control says, “user access is reviewed quarterly,” there is no in-depth detail to explain how the review is done, by whom, and when.

Section 5: Other Information Provided by the Management

The final section is optional and serves as a space for an organization to include any additional information not contained in the report. The purpose of this section is to provide extra context and reference elements not tested or covered in the report. Management can tailor this section and include information on the following:

  • Plans or expectations for new systems
  • A detailed response from management to a qualified opinion report

Right, after all of this, it’s evident that a SOC 2 report doesn’t come easy. With Scytale’s SOC 2 experts in your corner, you can leverage industry-leading guidance to help you step-by-step through the compliance process and fully prepare you for your audit. Additionally, check out our fully automated SOC 2 compliance solution and see how your organization can get (and stay) SOC 2 compliant up to 90% faster.