What’s Included in a SOC 2 Report

What's Included in a SOC 2 Report

You've likely heard that a SOC 2 report is essential for building trust with customers — but what does it actually cover?

Understanding what's inside a SOC 2 report helps you prepare more effectively, set accurate expectations with your team, and communicate the value of your compliance program to prospective clients. This guide breaks down what the report actually contains and why each piece matters. (For a section-by-section walkthrough of the report's actual structure and example language, see our SOC 2 report example guide — this page focuses on what topics and criteria the report covers.)

A Holistic View of Your Control Environment

A SOC 2 report isn't just a technical audit — it's a broad assessment of how your organization protects customer data and delivers reliable service. It examines how your people, processes, and technology work together to meet the expectations defined by the Trust Services Criteria.

Rather than a simple checklist, the report is a narrative that lets customers and auditors evaluate the depth and maturity of your security program — not just whether a box got checked, but how the control actually functions day to day.

The Five Trust Services Criteria

Every SOC 2 report is built around some combination of five Trust Services Criteria (TSC). Security is mandatory for every SOC 2 audit; the other four are included based on what's relevant to your business and what your customers expect.

Security covers protection against unauthorized access, both physical and logical. This includes access controls, authentication requirements like MFA, network security, and how you detect and respond to potential security incidents. Every SOC 2 report includes this criterion — it's the baseline.

Availability covers whether your systems are reliable and accessible as agreed with customers. This includes uptime commitments, monitoring, incident response, and disaster recovery and business continuity planning. Companies with SLA commitments around uptime typically include this criterion.

Processing Integrity covers whether system processing is complete, valid, accurate, timely, and authorized. This matters most for companies whose core function involves processing transactions or data on behalf of customers — payment processors, billing platforms, and similar systems where accuracy of output is the product itself.

Confidentiality covers how sensitive, non-personal information (contracts, business plans, intellectual property, proprietary data) is protected from unauthorized disclosure. This is distinct from Privacy, which specifically concerns personal information.

Privacy covers how personal data is collected, used, retained, and disposed of in line with your stated privacy commitments. Companies handling significant volumes of personal data, or operating in regions with strict privacy regulation, often include this criterion — and many map it directly to obligations under frameworks like GDPR.

Many companies map their SOC 2 controls to complement other frameworks such as ISO 27001 or GDPR, building a unified approach to compliance that reduces duplicate audit effort across standards.

What Systems and Processes Are In Scope?

One of the most important aspects of a SOC 2 report is its defined scope. The report doesn't attempt to cover your entire business — it focuses specifically on the systems and processes that affect customer trust and data.

Scope typically includes:

• The infrastructure that processes or stores customer data

• The software systems that interact with that data

• The organizational processes that support your security and privacy objectives

• The people and third parties who manage or access critical systems

Your organization works with your auditor to clearly define this scope during the planning phase of the audit — getting scope wrong at this stage (too broad, too narrow, or missing a system customers actually care about) is one of the most common sources of audit friction later on.

How the Report Documents Evidence

SOC 2 reports are built on transparency, not self-attestation. Auditors don't take your word that controls are in place — they test them directly, review supporting evidence, and issue an independent opinion on effectiveness.

For each control area, the report documents what the control is, how the auditor tested it, and the result of that testing — including any exceptions found. (We walk through exactly what this looks like, with real example language, in our SOC 2 report example guide.)

This level of detail is what lets a customer's security team actually evaluate your program, rather than just checking a compliance box off a vendor questionnaire.

Why This Matters to Your Customers

For today's buyers — especially in regulated industries — a SOC 2 report is often a prerequisite for doing business at all. It signals that your organization takes security seriously and has a mature, well-documented approach to managing risk, backed by an independent third party rather than your own marketing claims.

Understanding exactly what your report covers lets you position it confidently in sales and customer trust conversations — and helps you spot gaps in your own program before a prospect's security team does.