Real-World SOC 2 Report Example: A Simple Walkthrough
Meta: There’s more to a SOC 2 report than endless pages of jargon and boilerplate. Learn how to navigate one as we walk through a real-world SOC 2 report example.
Real-World SOC 2 Report Example: A Simple Walkthrough
Nobody likes wading through 30 to 70 pages of an extra-dry SOC 2 report, but someone has to do it. If that someone is you, then come along with us as we walk through a real-world SOC 2 report example and highlight the points you need to know.
Though it may be long, a SOC 2 report offers some of the most valuable insights into your service organization’s security posture and SOC 2 compliance.
Unfortunately, it’s often difficult to pick out useful gems of information from the many pages of boilerplate and technical jargon typical of most SOC 2 reports. To help make things a little easier, we’ll review the basic structure and key points of a real-world SOC 2 report from our friends at Carta, an equity management company.
But first, it may help to recognize why such a lengthy report is really useful.
What is a SOC 2 report?
Simply put, a SOC 2 report provides detailed results of a SOC 2 audit. However, there’s more to these results than meets the eye. They also contain a wealth of information about your company’s current security posture, specifically as it relates to the security standards covered by SOC 2. Meeting these security standards is also necessary for SOC 2 compliance.
SOC reporting and standards
While you may already know what SOC 2 is, understanding its core concepts can help you better understand a SOC 2 report’s structure.
Developed by the American Institute of Certified Public Accountants (AICPA), System and Organization Controls (SOC) is a set of standards for reporting on various types of audits.
There are three types of SOC reports, each of which relates to a different kind of SOC audit. SOC 2 reports are meant specifically for audits related to security and privacy controls, whereas SOC 1 reports are for financial reporting.
SOC reports are also categorized as either SOC 2 Type I or SOC 2 Type II, depending on whether the SOC audit took place at a single point in time (Type I) or on an ongoing basis (Type II).
Controls covered by SOC
“Controls” refer to policies, procedures, or processes used to achieve certain outcomes.
A security control, for example, could be using multi-factor authentication to prevent unauthorized logins. SOC reports use the trust services criteria, a set of controls broken down into five main categories:
- Security: Firewalls, multi-factor authentication, etc.
- Availability: Disaster recovery, performance monitoring, etc.
- Confidentiality: Access control, encryption, etc.
- Processing integrity: Process monitoring, quality control, etc.
- Privacy: Encryption, access control, etc.
The trust services criteria share many parallels to the famous “CIA triad” of confidentiality, integrity, and availability. But these focus specifically on the security controls meant to achieve them. As we’ll see in the next section, a SOC 2 report is simply a measure of how well a service organization or system has implemented these security controls.
SOC 2 report structure
Despite countless pages of detailed criteria and technical jargon, a SOC 2 report has a surprisingly clear and linear structure. Unfortunately, it’s easy to lose sight of it when you’re reading about the finer points of granting system access to new users on page 76.
The main goal of SOC 2 reporting is to guide the reader through an audit of a particular system and discuss whether that system meets the audit criteria. To meet this goal, a SOC 2 report must provide detailed information about the audit itself and information about the system and perspectives of management, hence its notoriously long length and heavy detail.
In any case, all SOC 2 reports have five main sections:
- Report from the auditor
- Management assertion
- System description
- Tests of controls
- Other information
These sections walk through a SOC examination, starting with a summary and working through goals, audit details, and other relevant information. Keeping this structure in mind will help you maintain a sense of the “big picture” as you wade through the finer details in each section.
1. Report from the auditor
The first section of a SOC 2 report is a summary of the audit provided by the auditor. Short, sweet, and to the point, this section should provide a brief and correct summary of the entire SOC examination, including the scope, period, good or bad points, and an opinion or “grade.”
For many, the most important part of this section is the auditor’s opinion, which usually says whether the service organization passed. Here, auditors sometimes use special terms to describe the results.
- Unqualified: Passed.
- Qualified: Passed with some areas for attention.
- Adverse: Failed.
- Disclaimer of Opinion: Extra failed.
Though auditors don’t always use these terms, the outcome is almost always known as an “opinion.” We’ll see this later when we explore Carta’s SOC 2 report.
2. Management assertion
Usually the shortest section of the report, the management assertion allows the company to make claims or “assertions” about the audited systems and controls.
While we’ll look at a real-world example later, most management assertions are simply the company’s way of saying, “these are our systems, these are their controls, and this is what we think about it right now.” This section may also include the company’s assertions about the audit itself, such as the time and scope.
This section might seem somewhat redundant, but it’s often necessary for creating a legal basis between the company and the auditor.
3. System description
True to its name, the system description provides a detailed overview of the system. While the management assertion might provide a brief system description, this section outlines everything from system components to procedures, system incidents, and everything in between.
Common parts of a system description include:
- System scope and requirements
- System components (e.g., infrastructure, people, etc.)
- Control frameworks
- System incidents
- Complementary information (e.g., user responsibilities, etc.)
Of course, this section is only as detailed and complex as the system itself. A simple system may only need a simple description and vise-versa. Usually, however, you can expect a good 20-30 pages of detailed information.
4. Tests of controls
Easily the longest part of any SOC 2 report, this section is a complete collection of every test performed during the audit.
Since SOC 2 reports are mainly security-oriented, most of the tests found in this section relate to the “Security” trust services criterion. Here, Security breaks down into nine Common Criteria (CC).
- CC1: Control Environment
- CC2: Communication and Information
- CC3: Risk Assessment
- CC4: Monitoring Activities
- CC5: Control Activities
- CC6: Logical and Physical Access Controls
- CC7: System Operations
- CC8: Change Management
- CC9: Risk Mitigation
Before testing, auditors assign each test to a Common Criteria and a testing procedure.
Most SOC 2 reports show tests in a tabular format with the following information:
- Criteria (CC)
- Trust services category or control objectives
- Control number
- Control description from the company
- Test description from the auditor
- Test results
Though some real-world examples can approach a dizzying 100 pages in length, don’t be too intimidated. Unlike other sections, you only need to read the tests that are relevant to the controls you’re interested in. In other words, think of this section as an encyclopedia rather than a novel.
5. Other information
Some SOC 2 reports may include an extra section for additional information or, more commonly, management’s response to specific test results. As we’ll see in the next section of this guide, Carta used this section to provide feedback for tests where auditors noted exceptions.
SOC 2 report example: Carta
Now that you’re familiar with the SOC report structure, it’s time to dive into a real-world SOC 2 report.
Seeing how each section takes shape in an actual report is incredibly useful for reading and writing your own SOC 2 reports. As mentioned earlier, we’ll be exploring a SOC 2 report prepared for Carta, a technology service provider specializing in equity management solutions.
Carta’s audit and SOC 2 report
As a technology company working in the financial sector, Carta’s business relies on keeping its platform secure and maintaining SOC 2 compliance. Carta could identify key strengths and weaknesses of its security measures by having an auditor evaluate its controls against the trust services criteria.
Carta’s SOC 2 report follows the same structure we discussed earlier. Take a look at the Table of Contents below:
Here, each major section is clearly outlined in bold lettering. While the total length of the report is 114 pages, section IV — the ever-lengthy “tests of controls” section — takes up nearly two-thirds of it. As we’ll see, however, some of the most valuable information is at the very beginning.
Section I: Report from the auditor
Of all the pages in this report, this section’s five pages are the most widely read.
In this section, Carta’s auditor, BDO, has provided a detailed summary of the entire audit, beginning with a scope that outlines the purpose of the audit and a brief system description.
Here’s a snippet of the system description:
Though it may read like boilerplate, it’s enough to provide a general understanding of Carta’s technology stack. The remainder of the section provides similarly short descriptions of the auditor’s and management’s responsibilities, the inherent limitations of the audit, and, above all, the auditor’s opinion.
The auditor’s opinion is the part that most people flip to when reading the report. Here, the auditor provides the results of the audit and their opinions.
Clearly, the audit revealed that Carta’s controls “operated effectively” throughout the period of the audit. In other words, it was a successful audit. Despite this, the auditors may have still found areas for improvement. For that information, we’ll need to dive a bit deeper.
Section II: Management assertion
In this section, Carta’s management provides a system description like that of the auditor’s, if only to confirm that both parties are on the same page.
Most importantly, however, management asserts that the controls of its system are “suitably designed” and “operated effectively” to be in line with the trust services criteria.
Section III: System description
Where previous sections only provide a summary of the system, this section goes into much greater detail. While we won’t comb through the technical details, it’s worth noting that many of them use graphics and tables for clarity.
The system description isn’t all about technology, however. It outlines the personnel involved, along with their roles and responsibilities. Finally, at the end of the section, system components and controls are grouped with their respective common criteria.
Section IV: Tests of controls
Though 75 pages make this section the longest of the report, it’s the easiest to read. After briefly outlining the general auditing procedure, the rest of the section simply collects individual tests in a tabular format.
This test, for example, reviews Carta’s internal controls that fall under the Control Environment (CC1) criteria. Here, the auditor checks on whether Carta “demonstrates a commitment to integrity and ethical values” (trust services criteria) by reviewing controls related to information security policies.
In this case, BDO asked Carta personnel various things about their security policies, such as whether they were regularly reviewed (1.1a) or acknowledged by new hires (1.1b). In this test, the auditor noted that one in 45 new hires didn't acknowledge the policies and that two in 45 new hires only reviewed them long after accepting the job.
Section V: Other information
While many SOC 2 reports would end at this point, Carta’s report takes things a step further and provides management responses to exceptions noted in the tests. Here, for example, Carta acknowledges that some new hires didn’t acknowledge security policies and commits to checking more frequently (see highlighted text).
While there’s a lot to unwrap in a SOC 2 report, the key points are much easier to find than many would think. By sticking to the big picture and navigating to the most relevant areas, you’ll be able to get all the information you need without wading through 100 or more pages of boilerplate.
Even so, writing and reviewing SOC 2 reports is a massive chore, especially with other parts of the auditing process to worry about. To learn how Secureframe can help streamline your next SOC 2 audit, contact us for a free demo.