A Real-World SOC 2 Report Example
Seeing a real example of how a SOC 2 report might look can be incredibly useful when preparing for an audit.
Here’s a sample SOC 2 report from Carta, the online equity management solutions platform.
What is a SOC 2 Report?
A SOC 2 report provides detailed results of a SOC 2 audit. They also contain a wealth of information about your company’s security posture, specifically as it relates to the security standards covered by SOC 2.
SOC reporting and standards
Understanding the core concepts of SOC 2 can help you better understand the report structure.
Developed by the American Institute of Certified Public Accountants (AICPA), SOC 2 reports are meant specifically for audits related to security and privacy controls.
SOC reports are also categorized as either Type I or 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 mitigate risk.
A security control, for example, could be using multi-factor authentication to prevent unauthorized logins. SOC reports use the Trust Services Criteria:
- 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.
A SOC 2 report evaluates how well a service organization has implemented these security controls.
SOC 2 Report Structure
The main goal of SOC 2 reporting is to discuss whether a particular system meets the audit criteria. A SOC 2 report must provide detailed information about the audit itself, the system, and the perspectives of management.
SOC 2 reports include:
- Report from the auditor
- Management assertion
- System description
- Tests of controls
- Other information
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 summary of the entire SOC examination, including the scope, period, and the auditor's opinion.
For many, the most important part of this section is the auditor’s opinion, which says whether the service organization is in compliance with SOC 2 requirements. Here, auditors sometimes use special terms to describe the results.
- Unqualified: The company passed its audit.
- Qualified: The company passed, but some areas require attention.
- Adverse: The company failed its audit.
- Disclaimer of Opinion: The auditor doesn’t have enough information to make a fair conclusion.
2. Management assertion
The management assertion allows the company to make claims about the audited systems and controls.
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
While the management assertion might provide a brief system description, this section goes into more detail. It covers everything from system components to procedures to system incidents.
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.
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.
Most SOC 2 reports show tests in a table 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
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 management’s response to specific test results. In the example below, Carta used this section to provide feedback for tests where auditors noted exceptions.
SOC 2 Report Example: Carta
As a fintech company, Carta's business relies on keeping its customer data secure. Their SOC 2 report, outlined below, shows how they do that through the standard set by the AICPAs Trust Services Criteria.
While their report has over 100 pages of documentation, we'll focus on highlighting some of the most actionable areas.
Section I: Report from the auditor
Of all the pages in this report, this section’s five pages are the most read. Carta’s auditor, BDO, provides a detailed audit summary, beginning with an outline of the purpose and a brief system description.
Here’s a snippet of the SOC 2 system description example:
This text provides a general understanding of Carta’s technology stack. The rest of the section provides short descriptions of:
- Auditor’s responsibilities
- Management’s responsibilities
- Audit limitations
- Auditor’s opinion
The auditor’s opinion is the part that most people flip to when they first receive their report. This is where the auditor shares the results of the audit.
This report reveals that Carta’s controls “operated effectively” throughout the period of the audit. This means Carta passed the audit and is SOC 2 compliant. Despite the positive outcome, the auditors may still have found opportunities for improvement. Details on that information are further down in the report.
Section II: Management assertion
In this section, Carta’s management gives its own system description. This confirms that both Carta and BDO are on the same page.
Management also asserts that its security controls are “suitably designed” and “operated effectively.”
Section III: System description
Previous sections provide a summary of the system, but this section goes into much greater detail.
The system description includes the personnel involved, along with their roles and responsibilities. Finally, system components and controls are grouped with their respective Common Criteria.
Section IV: Tests of controls
Although this is by far the longest section of the report (75 pages), it’s the easiest to read. It outlines the general auditing procedure and shows individual tests in a table format.
This test reviews Carta’s internal controls under the Control Environment (CC1) criteria. The auditor checks whether Carta “demonstrates a commitment to integrity and ethical values” (Trust Services Criteria) by reviewing controls related to information security policies.
Specifically, BDO asked Carta personnel whether security policies are reviewed (1.1a) or acknowledged by new hires (1.1b). The auditor noted that 1 in 45 new hires didn't acknowledge the policies. 2 in 45 new hires only reviewed them long after accepting the job.
Section V: Other information
While many SOC 2 reports end at this point, Carta’s report provides management responses to exceptions noted in the tests. Here Carta acknowledges that some new hires didn’t review security policies and commits to checking more frequently.