A real SOC 2 report example isn’t something you can pull off the internet, because SOC 2 reports are restricted-use documents shared only with current and prospective customers, partners, and their auditors, usually under an NDA. What you can know in advance is the structure, which is fixed: an independent auditor’s opinion, a signed management assertion, a system description, a mapping of controls to the Trust Services Criteria, and — in a Type 2 — a testing matrix showing whether each control actually worked. The AICPA publishes illustrative sample language, but every real report from a real vendor stays behind a confidentiality agreement.1AICPA & CIMA. System and Organization Controls SOC Suite of Services
That restriction is deliberate. SOC 3 exists for the version a company can post publicly; it contains the same criteria but strips out the detailed testing results and system description. If a vendor is willing to hand you something without an NDA, you’re probably looking at a SOC 3, not a SOC 2.
The Five Sections You’ll See
Every SOC 2 report follows the same order. Knowing what each section is for lets you skim to what matters instead of reading eighty pages linearly.
1. The Independent Auditor’s Report
This opens the report. It’s the CPA firm’s professional opinion on whether the organization’s system description is fairly presented and whether the controls meet the selected Trust Services Criteria. The opinion falls into one of four buckets:
- Unqualified: no material problems. This is what you want to see.
- Qualified: specific control failures the auditor flagged, but not enough to undermine the whole report. Expect a remediation plan.
- Adverse: failures serious enough that customers shouldn’t rely on the organization’s security claims.
- Disclaimer: the auditor couldn’t gather enough evidence to form any opinion at all. A major red flag.
A qualified opinion doesn’t automatically kill a vendor relationship; the specific failures may not touch your use case. An adverse opinion or disclaimer should make you seriously reconsider.
2. The Management Assertion
Right after the auditor’s letter comes a signed statement from the organization’s leadership. Executives declare that the system description is accurate and that the controls were in place during the audit period. The signatures create accountability. When you’re reviewing a report, confirm the assertion is present and that its claims line up with the auditor’s opinion. Reports occasionally surface where the assertion is missing or contradicts what the auditor found, and that disconnect warrants a direct conversation with the vendor.
3. The System Description
This is the longest section and, in many ways, the most important. It defines the boundaries of what the audit actually covered. A vendor may have a valid SOC 2 report that says nothing useful about your risk, because the report only covers a product you don’t use.
A typical system description spells out:
- Services covered: the specific products, platforms, or applications in scope.
- Infrastructure: data centers, cloud environments, or hybrid setups hosting those services.
- Software components: operating systems, databases, and middleware.
- People: the organizational structure and roles responsible for security.
- Data flows: how information moves through the system, what’s processed, where it’s stored.
- Boundaries: explicit statements about what is excluded.
Read the boundaries carefully. Vendors sometimes scope narrowly enough to exclude the riskiest parts of their environment. A cloud platform’s SOC 2 report that covers production but excludes a staging environment where engineers routinely access customer data has a gap that matters.
This section also names any subservice organizations — the downstream vendors the primary organization relies on. A SaaS company might host on AWS, process payments through Stripe, and use a third-party data center for backups. There are two ways a report can handle them. Under the carve-out method, the downstream provider’s controls are excluded from the audit scope; the report acknowledges the dependency without testing it. This is by far the more common approach, especially for smaller companies without the leverage to demand control evidence from major cloud providers. Under the inclusive method, the subservice organization’s controls are pulled in and tested alongside the primary organization’s. This is rare.
When you see a carve-out, your next step is requesting the subservice organization’s own SOC 2 report. A carve-out isn’t a red flag by itself. A carve-out combined with no monitoring of the subservice provider is.
4. Trust Services Criteria and Control Activities
Every SOC 2 report maps controls to the AICPA’s Trust Services Criteria. The current framework is the 2017 criteria with revised points of focus published in 2022.2AICPA & CIMA. 2017 Trust Services Criteria with Revised Points of Focus 2022 Five categories exist, but only one is mandatory:
- Security (required): protection against unauthorized access, physical and logical. Every SOC 2 report includes this.
- Availability: whether the system is up and running as promised.
- Processing integrity: whether data processing is complete, accurate, and timely.
- Confidentiality: protection of information the organization has designated as confidential.
- Privacy: how personal information is collected, used, retained, and disposed of.
The organization picks which criteria beyond security to include. A vendor that doesn’t handle personal data may skip privacy entirely. A vendor whose uptime doesn’t affect your operations may leave availability out. Check which criteria were selected and whether they cover the risks that matter to you. A report that covers only security is perfectly valid under the standard but may not answer the questions you actually have.
Within each selected criterion, the report lists specific control activities. These range from technical measures — firewall rules, encryption configurations — to administrative processes like background checks and quarterly access reviews.
5. Tests of Controls and Results
This section only appears in a Type 2 report, and it’s where the report earns most of its value. It’s a detailed table: each control activity, the specific test the auditor performed, and the result.
Auditors use several testing methods. They inspect access logs to verify only authorized personnel entered a secure system. They review termination records to confirm departing employees lost access promptly. They pull population samples — every change management ticket from a quarter, for instance — and check whether each one followed the approval workflow. The point is independent verification rather than taking the organization’s word for it.
The results column shows whether any exceptions were found. An exception means a control didn’t work as described for at least one instance. Maybe a quarterly security review was skipped, or an access removal took five days instead of twenty-four hours. Not every exception is catastrophic. One missed review out of four quarters tells a different story than systematic failures across the entire period.
When auditors find exceptions, the organization includes a management response right alongside — root cause, any compensating controls, and a remediation plan. A thoughtful response that acknowledges the gap and provides a specific fix carries more weight than a vague dismissal. If a report contains exceptions but no management responses, that silence should concern you.
The number and severity of exceptions directly influence the auditor’s opinion. A handful of isolated exceptions usually won’t change an unqualified opinion. Widespread or repeated failures push the opinion to qualified, and pervasive breakdowns lead to adverse.
Type 1 vs. Type 2: What the Example Looks Like
SOC 2 comes in two flavors, and the type shapes what you’ll actually see in the report.
A Type 1 report captures a snapshot: it evaluates whether controls are properly designed at a single point in time.3PwC. System and Organization Controls (SOC) Reports and Other Attestation Services The report includes the auditor’s opinion, management assertion, system description, and the mapping of controls to criteria. There’s no testing matrix showing operational results because there’s no observation period to test over.
A Type 2 report goes further by testing whether those controls actually worked over a sustained period, typically three to twelve months. Same first four sections, plus the tests-of-controls matrix with results and any exceptions. That distinction matters more than it might seem. A control can look perfectly designed on paper and fail repeatedly in practice because of staff turnover, configuration drift, or simple neglect.
Type 1 has its uses: an early-stage company, an organization that just overhauled its security infrastructure, or a vendor trying to close an enterprise deal on a short timeline can get something credible in front of a prospect faster with a Type 1. Turnaround is shorter because the auditor only evaluates design at one moment.
Most organizations end up at Type 2. Many enterprise buyers now reject Type 1 reports outright because a snapshot tells them nothing about day-to-day execution. If a vendor sends you a Type 1 when your risk profile calls for Type 2, that’s worth pushing back on.
Complementary User Entity Controls
One section in the report gets skipped more than any other and often matters most: complementary user entity controls, or CUECs. These are specific actions you, the customer, have to take for the vendor’s controls to work as intended. The vendor builds the framework; certain pieces only function if you do your part.
Common CUECs include requiring your users to enable multi-factor authentication, managing user access permissions within the platform, maintaining appropriate password policies, and restricting API key distribution. If the vendor’s report lists a CUEC for MFA and your organization hasn’t enabled it, there’s a gap in the chain the vendor’s controls can’t cover.
When you review a report, pull out every listed CUEC and confirm your organization has a corresponding control in place. If one isn’t being met, you need a plan. Documenting how you handle each CUEC is part of sound vendor management; your own auditors may ask how you’ve addressed the CUECs listed in your vendors’ reports.
How to Actually Review a Report You’ve Been Given
Reading a SOC 2 report cover to cover takes time. A practical sequence:
- Check the report period. Some vendors try to pass off expired reports. A Type 2 from eighteen months ago tells you very little about today’s controls.
- Verify the auditor. Look up the CPA firm on the AICPA’s peer review database or your state accountancy board. If you can’t find them, that’s a problem.
- Read the opinion first. If it’s anything other than unqualified, understand why before investing time in the rest.
- Confirm the scope covers your use case. Check the system description for the specific products and services you use. If your service isn’t in scope, the report doesn’t apply to you.
- Review which Trust Services Criteria were included. Make sure the criteria that match your risk profile are covered.
- Check for subservice organization carve-outs. If critical infrastructure providers were carved out, request their SOC 2 reports separately.
- Scan the testing matrix for exceptions. Read the management responses and assess whether the remediation is credible.
- Document CUECs. Identify every one and confirm your organization meets it.
What a Bridge Letter Is (and Isn’t)
SOC 2 reports cover a fixed period, but your fiscal year or audit cycle may not line up with your vendor’s reporting window. A bridge letter, sometimes called a gap letter, covers the interim between the end of one SOC 2 report and the start of the next. Management signs it confirming that no material changes have occurred to the control environment since the last report.
Bridge letters are not SOC 2 reports. They’re self-attestations from the vendor, not independently verified by a CPA firm. They’re meant to cover short gaps of no more than three months. If a vendor is asking you to rely on a bridge letter for six months or longer, their audit cycle has slipped and you should push for an updated report.
Don’t Confuse SOC 2 With SOC 1
One last boundary worth naming. SOC 1 focuses exclusively on controls relevant to financial reporting. If you’re evaluating a payroll processor or a company handling financial transactions on your behalf, SOC 1 is the report your auditors care about, and it tells you nothing about broader security practices. SOC 2 is the report you want when evaluating a SaaS vendor, cloud provider, or any service organization that touches your data beyond financial transactions. Ask for the wrong one and you’ll get a document that answers a question you weren’t asking.