What a SOC 2 report from your auditor should actually contain

Your SOC 2 report is what customers actually read. Most companies have never looked at their own closely. They get the final PDF from the auditor, confirm it says “unqualified” somewhere near the top, and start sending it to prospects under NDA. That’s a mistake.

The report itself follows a rigid structure. If you need a primer on what SOC 2 actually is, start there. Every section serves a specific purpose. And if you don’t understand what belongs in each one, you can’t catch errors, you can’t explain things to customers who ask questions, and you can’t have an informed conversation with your auditor about what gets included and what gets left out.

The five standard sections of every SOC 2 report

The AICPA defines a standard structure that every SOC 2 report must follow, regardless of which CPA firm performs the examination. Five sections. Same order. Every time.

Section 1: Independent Service Auditor’s Report. The opinion letter. The most important part of the entire document. The auditor states whether your controls are designed properly and, for Type 2 reports, whether they operated effectively during the review period. It also covers scope and limitations.

Section 2: Management’s Assertion. This is your company’s formal statement. Your leadership signs a letter asserting that the system description is accurate and that the controls met the Trust Services Criteria. Think of it as management going on the record. The AICPA requires this assertion as the foundation the auditor tests against.

Section 3: Description of the System. Usually the longest section. It describes how your system actually works: services in scope, system boundaries, infrastructure, software, people, procedures, and data flows. Good system descriptions explain how information moves through your environment. Bad ones read like marketing copy.

Section 4: Description of Criteria and Related Controls. Your control matrix lives here. Each Trust Services Criteria point (security, availability, processing integrity, confidentiality, or privacy) maps to specific controls your company has in place. This is where someone reviewing the report can see exactly what you do to meet each criterion.

Section 5: Tests of Controls and Results. The most detailed section. For every control in Section 4, the auditor describes what they tested, how they tested it, and what they found. Exceptions show up here. Security teams at your customers’ companies will spend most of their time in this section.

Some reports include an optional Section 6 with management responses to exceptions or additional context. But the core five sections are non-negotiable.

A real compliance dashboard tracking all evidence, controls, and risks

What the auditor’s opinion actually means

Not all opinions are equal. There are four types an auditor can issue, and the differences have real consequences.

Unqualified opinion. This is what you want. It means the auditor tested your controls and found them suitably designed and operating effectively. No material exceptions. People sometimes call this a “clean” opinion. It doesn’t mean perfection. It means nothing material went wrong during the review period.

Qualified opinion. This means the auditor found problems, but they were limited to specific areas and not pervasive across the whole system. Maybe one control wasn’t operating effectively, or the auditor couldn’t get enough evidence for a particular area. You can still share a report with a qualified opinion. But expect questions.

Adverse opinion. Bad news. The auditor found material issues widespread across your controls. An adverse opinion tells readers they cannot place reliance on your system. Rare, because most companies would pull the engagement before reaching this point. But it happens.

Disclaimer of opinion. The auditor couldn’t gather enough evidence to form any opinion. Maybe the company restricted access to information. Maybe key personnel were unavailable. Extremely uncommon, and it signals something went seriously wrong with the engagement.

Here’s the thing most people miss. As I’ve written about in the context of attestation vs certification, a SOC 2 report with a qualified opinion is still a SOC 2 report. Your company can still say it “has” a SOC 2. The opinion type is what determines how much your customers should trust the contents.

Management assertion vs auditor opinion

These two sections get confused constantly, but they serve completely different functions.

The management assertion is your company’s statement. Leadership is saying: “We believe our system description is accurate, our controls were suitably designed, and they operated effectively during this period.” Both the AICPA and your auditor require it.

The auditor’s opinion is the independent check. The CPA firm examined your controls, tested them, and is saying whether they agree or disagree with management’s claim. The opinion carries legal weight. It’s the reason only licensed CPA firms can issue SOC 2 reports.

Why does this matter? Because the two can conflict. Management can assert that everything is fine. The auditor can then disagree. When you see a qualified or adverse opinion, that’s the auditor saying “management’s assertion doesn’t fully hold up based on what we tested.”

This is also why the management assertion needs careful review before finalization. If management claims something that the auditor’s testing contradicts, you have an internal consistency problem. Your customers’ security teams will notice.

At Tallyfy, we learned this early. The management assertion isn’t a formality you skim and sign. It’s a commitment. Get the wording wrong, and it creates questions downstream that are entirely avoidable.

CUECs and subservice organizations

Two parts of the report that most companies gloss over. Both matter more than people think.

Complementary User Entity Controls (CUECs) are controls that your customers must implement on their side for your system to work securely. Your report lists them explicitly. Common examples: requiring customers to enable multi-factor authentication, disabling accounts for terminated employees promptly, maintaining endpoint protection on devices accessing your service.

CUECs are your company saying: “We’ve done our part, but security also depends on what our customers do.” If a customer gets breached because they never enabled MFA, and your report listed MFA as a CUEC, that matters. Wipfli published useful guidance on structuring these effectively.

The problem? Most companies list CUECs because their auditor tells them to, and then never communicate those requirements to actual customers. That gap creates risk for everyone.

Subservice organizations are the vendors that are part of your system. AWS, Google Cloud, Stripe, whatever infrastructure you depend on. The report must disclose these, and there are two methods for handling them.

The carve-out method is far more common. Your report acknowledges the subservice organization but explicitly excludes their controls from scope. You’re essentially saying: “AWS hosts our stuff, but their controls aren’t covered in our report. Go read their SOC 2 for that.” Most SaaS companies use this approach because coordinating an inclusive audit with a vendor like AWS isn’t realistic.

The inclusive method includes the subservice organization’s controls in your audit scope. The subservice organization must cooperate with your auditor, provide evidence, and sign their own management assertion. Rare outside of tightly integrated relationships.

If you’ve dealt with choosing between SOC 2 and ISO 27001, you know that every compliance framework handles third-party dependencies differently. The carve-out vs. inclusive decision shapes how much vendor risk is visible in your report.

How to review your own report before sharing

The SANS Institute recommends reviewing SOC 2 reports systematically, and that advice applies to your own report too. Before you share it with a single customer, read it cover to cover. Here’s what to check.

Verify the opinion type. Obviously. But also read the full opinion paragraph, not just the word “unqualified.” The opinion letter describes the exact scope, time period, and criteria covered. Make sure it matches what you expected.

Read your system description as if you were a prospect. Does it accurately describe what you do? Is it too vague? Too technical? This section represents your company to every security team that reads it. Outdated system descriptions are one of the most common issues in SOC 2 reports.

Check every exception in Section 5. Each exception describes what was tested, the expected result, and what actually happened. If you disagree with how an exception is characterized, discuss it with your auditor before the report is issued. Once finalized, it’s permanent.

Review your CUECs for accuracy. Are the controls you’re expecting customers to implement actually reasonable? Do they reflect how customers actually use your product? Listing a CUEC that no customer could reasonably follow weakens the entire section.

Confirm your subservice organizations are current. If you switched from AWS to GCP last year and the report still lists AWS, that’s an error. Same if you added a new critical vendor that should be disclosed but isn’t.

Check the review period. For Type 2 reports, the period matters. If your report covers January through December and a customer asks about March controls after that period ended, there’s a gap. Some companies stagger audit periods to minimize these windows.

Look for factual errors. Wrong employee counts. Outdated technology references. Inaccurate process descriptions. These won’t usually affect the opinion, but they undermine confidence. When a reviewer spots that your system description mentions a tool you stopped using two years ago, they question everything else.

The whole point of understanding your report’s structure is having a real conversation with your auditor. Push back on how exceptions are characterized. Request clearer language in the system description. Ensure the CUECs are practical. None of that happens if you treat the report as a black box you pass through to customers. And if you’re questioning whether you need a GRC platform to manage all this, the answer increasingly is no.

Worth discussing for your situation? Reach out.