Key Takeaways
- SOC 2 reports follow a standard AICPA structure with clear sections like the auditor’s opinion, system description, and test results.
- They’re prepared by CPA firms and shared as PDFs under NDA, often through trust portals.
- Cloud vendors issue semi-annual, rolling reports for continuous assurance.
- Reviewing a sample SOC 2 report or a SOC 2 report template helps you know what to look for.
Everyone in security has heard of SOC 2. Many have requested or reviewed a SOC 2 audit report from a vendor. But fewer have slowed down to analyze what one actually looks like. If you’ve ever wondered how to read a sample SOC 2 report, this guide will walk you through the structure piece by piece.
The Anatomy of a SOC 2 Report
Every report follows a standardized format set by the AICPA, and once you know how to read it, the layout becomes surprisingly predictable. Whether you’re looking at a real document or reviewing a SOC 2 report template, the layout is remarkably consistent: title page, auditor’s opinion, system description, control details, and test results
1. Title Page and Table of Contents
This is where the report identifies the audited company, the time period covered (for Type II), and the auditing firm that performed the work.
2. The Auditor’s Opinion
This is the headline of the entire report. It is where the independent CPA firm states whether the company’s controls are suitably designed (Type I) and operating effectively over time (Type II).
- Unqualified (clean): controls are effective.
- Qualified: mostly effective, but with exceptions.
- Adverse: controls failed in material ways.
This section is often the first (and sometimes the only) part that business stakeholders read.
3. Management’s Assertion
Here, the company itself asserts that it is responsible for designing and implementing the described controls. It is like the vendor saying, “We believe this is accurate.”
4. System Description
One of the longest sections, this provides context on what was in scope:
- The services provided
- Key system components (hardware, software, people, data)
- Boundaries of what was and was not included in the audit
This section ensures that readers understand the environment the auditor evaluated.
5. Control Objectives and Related Controls
This is the detailed map of how the company addresses the relevant trust principles (security, availability, processing integrity, confidentiality, and/or privacy). Each control objective is paired with descriptions of the controls the company has put in place.
6. Tests of Controls and Results (Type II)
For Type II reports, the auditor describes how they tested each control and what they found. This includes both successful results and exceptions. It is the technical heart of the SOC 2, showing not only what controls exist, but how well they actually worked in practice.
7. Complementary User Entity Controls (CUECs)
These are the conditions the customer must meet in their own environment for the vendor’s controls to remain effective. For example, the vendor may encrypt data at rest, but the customer must enforce strong password policies for access.
While every report follows the same core format, each organization’s SOC 2 tells a slightly different story. A SOC 2 report example for a SaaS company might focus heavily on application security and data handling, while a cloud provider’s report can span hundreds of pages of infrastructure details.
Who Prepares SOC 2 Reports and How They Are Shared
Before a SOC 2 report lands in a customer’s inbox or trust portal, there is a fairly standard process behind it.
Who Prepares the Report:
SOC 2 reports are conducted and issued by licensed CPA firms. The organization being audited provides documentation, evidence, and access. The auditor tests controls, writes the report, and signs the opinion.
Format of the Report:
Reports are issued as PDFs, usually dozens or even hundreds of pages long. They are official audit documents, complete with signed opinions, control descriptions, and test results. Because they contain sensitive system details, they are not published publicly.
How Reports are Shared:
Reports are typically provided under non-disclosure agreements (NDAs). Vendors distribute them in a few ways: through secure compliance portals (such as Microsoft Service Trust Portal, AWS Artifact, or a vendor’s own trust center), via secure file-sharing links after legal approvals, or occasionally by direct email (less common for security reasons).
How Customers Receive Reports:
Usually, someone in procurement, security, or compliance requests the report during onboarding or vendor assessments. If the vendor uses a trust portal, the customer may need to log in to retrieve it. Once received, the report is typically reviewed by security or compliance staff and filed internally as part of the vendor record.
Updates to Reports:
SOC 2 reports are point-in-time (Type I) or rolling (Type II). Vendors usually issue new reports annually or semi-annually, and may provide bridge letters between reports to cover gaps.
Why You Would Be Asked for a SOC 2 Report
SOC 2 reports are most often requested during vendor due diligence or customer assurance reviews. A procurement manager may request the report to confirm that a vendor meets internal security policies. IT or security teams often review it to make sure the systems protecting the company’s data are sound. Legal or compliance officers may need it to verify that regulatory or contractual obligations are being met.
Most requestors do not read the entire report. They focus on the sections that answer their questions:
- Scope: Does the report actually cover the services we will be using?
- Auditor’s Opinion: Is the verdict clean, qualified, or adverse?
- Exceptions: Where did controls fail, and does it affect us?
- CUECs: What responsibilities fall on us, the customer, to make the vendor’s assurances valid?
How Major Cloud Vendors Use SOC 2 Reports
Microsoft, AWS, Google Cloud, and other hyperscalers undergo SOC 2 audits just like any other service provider. The structure of their reports is the same: auditor’s opinion, system description, controls, exceptions, and CUECs. The difference lies in how they scope, update, and deliver those reports to customers.
For Azure or AWS, the “system description” section is enormous compared to a mid-sized SaaS vendor. It includes dozens of global data centers, services, and infrastructure layers. The report explains which services are in scope, such as Azure Active Directory, Azure Storage, or AWS EC2. Customers reading the report must verify that the specific cloud services they plan to use are covered.
Instead of a one-time annual audit, these providers issue SOC 2 Type II reports on a rolling 12-month window. That means the report always reflects the most recent year, not just a single fixed audit period. Microsoft, for example, publishes new reports twice a year (periods ending March 31 and September 30).
Because even a semi-annual report leaves gaps between publication and availability, Microsoft and others provide bridge letters. These are short documents from management affirming that there have not been material changes in controls since the last report. Customers can use them to maintain continuous assurance while waiting for the next SOC2 audit report.
These reports are not public. They are distributed to paying customers (or prospective customers under NDA) through compliance portals such as:
- Microsoft → Service Trust Portal
- AWS → AWS Artifact
- Google Cloud → Compliance Resource Center
Our Scoop on Exceptions
In SOC 2 language, exceptions are recorded instances where a control failed to operate as designed during the audit period. These can be small, like a missed log review or a delayed SLA ticket, or more significant, like a control that didn’t trigger when it should have.
Contrary to popular belief, customers don’t expect zero exceptions. In fact, experienced reviewers sometimes see a spotless report as a warning sign. It can suggest that the scope was too limited or the auditor wasn’t thorough enough. What matters most is the nature of the exceptions and the response to them.
When reviewing exceptions, companies focus on a few key questions:
- Are the exceptions relevant to the services we’re using?
- Were the issues remediated promptly, or were compensating controls added?
- Do similar issues appear repeatedly from year to year?
Handled well, exceptions show that issues are detected, addressed, and documented transparently.
FAQs
Is a SOC 2 report the same as a SOC 1 or SOC 3?
No. SOC 1 focuses on financial reporting controls, SOC 2 focuses on security and trust principles, and SOC 3 is a high-level, publicly shareable summary of a SOC 2 with sensitive details removed. If someone asks for your SOC 3, they usually want proof without the NDA.
How long does it take to get a SOC 2 report?
For a first-time Type II audit, the full process can take 6 to 12 months. This includes a readiness period, the actual audit window (often 3 to 12 months), and reporting. Type I reports are faster since they are point-in-time.
Do SOC 2 reports expire?
They do not technically expire, but most organizations treat reports as valid for 12 months from the end of the audit period. Many procurement teams will not accept reports older than a year.
Can a company share only part of its SOC 2 report?
Sometimes. Vendors may redact sections or provide only the opinion and scope if the full report contains highly sensitive system details. However, this can limit how useful the report is for due diligence.
Is it possible to fail a SOC 2 audit?
Not exactly. SOC 2 audits result in an opinion: clean, qualified, adverse, or disclaimed. A qualified opinion means there were exceptions, but the overall controls were sound. An adverse opinion signals major issues. Vendors do not pass or fail in the traditional sense.
Who actually reads SOC 2 reports inside a company?
Typically, security, compliance, or vendor risk teams read them closely. Procurement may just confirm receipt, and legal might check for regulatory coverage. Business owners usually rely on summaries or flags raised by these teams.
