What's Actually in a SOC 2 Type II Report (and What Auditors Check)

You're either about to get your first SOC 2 Type II report or you're about to read someone else's. Either way, the document you're staring at was written for auditors and procurement reviewers, not for the people who actually need to understand it.

A typical Type II report is 60 to 100 pages of carefully hedged attestation language. Most people skim Section IV, spot-check a few exception findings, and call it done. That works for low-stakes vendor reviews. It does not work when you're the one being audited, or when a prospect's security team has actually read the thing.

This post breaks down what a SOC 2 Type II actually is, what auditors check during the audit period, and what's in each section of the report. If you're going through a SOC 2 audit for the first time, this should answer most of the questions you're not sure how to ask.

SOC 2 in 60 seconds

SOC 2 (System and Organization Controls 2) is a compliance framework developed by the AICPA (American Institute of Certified Public Accountants). It defines how a service organization should protect customer data across five categories called the Trust Services Criteria.

A SOC 2 audit produces a report. The report is signed by an independent CPA firm, the auditor. The auditor doesn't say "your security is good or bad." They say: we examined the controls this organization claims to have, and here's whether those controls were designed appropriately and operating effectively during the audit period.

That distinction matters. SOC 2 is not a security score. It's an attestation that you did what you said you'd do, controls-wise, for some period of time.

Type I vs Type II: the difference that matters

There are two flavors of SOC 2 report, and confusing them is the single most common mistake when reading vendor security posture.

If a vendor sends you a Type I report and you're a serious buyer, ask for the Type II. The Type I tells you they once had controls on paper. The Type II tells you those controls actually ran.

The five Trust Services Criteria

Every SOC 2 report addresses one or more of the five Trust Services Criteria (TSC). Most reports cover only Security (often called Common Criteria, or CC). Higher-risk vendors include additional criteria.

The Common Criteria themselves are organized into nine sub-categories, CC1 through CC9, covering control environment, communication, risk assessment, monitoring, control activities, logical access, system operations, change management, and risk mitigation. Most of an audit lives here.

For most B2B SaaS vendors, "Security only" (CC) is the right starting scope. Adding criteria adds audit cost and complexity, and you don't need them unless your customers are specifically asking.

What auditors actually check

People assume auditors run technical scans or pen-test the system. They don't. SOC 2 fieldwork is largely an evidence collection exercise. Here's what an auditor actually does during a Type II engagement.

Walkthroughs (weeks 1 to 2)

The auditor schedules calls with control owners: your IT lead, security lead, HR, engineering, and others. They ask the control owner to describe the control in their own words, then ask to see the system or process in action.

Example: "Walk me through how a new engineer gets access to production." The auditor wants to see the ticket, the approval, the access being provisioned, and the eventual deprovisioning when the engineer leaves a project.

Sample testing (weeks 3 to 6)

The auditor selects a sample of events from your control population and asks for evidence each control was performed. Sample sizes depend on frequency.

For each sampled item, you need evidence the control ran. "We have a quarterly access review" means you need four pieces of evidence (one per quarter) that someone reviewed access and signed off.

Evidence inspection

Common evidence requests include:

• Access provisioning tickets and approvals
• Quarterly user access review records
• Security awareness training completion records
• Vendor risk assessments
• Change management tickets with peer review
• Backup testing logs
• Incident response records
• Vulnerability scan results and remediation tickets
• Encryption configuration evidence (KMS keys, TLS versions)
• HR records for new hires and terminations

If you can't produce evidence a control ran on a sampled date, the auditor flags it as an exception.

Exception handling (weeks 6 to 8)

When evidence is missing or inadequate, the auditor logs an exception. Exceptions don't necessarily fail the audit. Most reports include some. But a high-severity exception or a pattern of exceptions can result in a qualified opinion or adverse opinion, which is bad.

The bell curve of audit outcomes:

• Unqualified opinion (clean): Most companies aim for this. Means controls operated effectively across the period with no material exceptions.
• Qualified opinion: Specific scope or controls had issues. Disclosed in the report.
• Adverse opinion: Material failure of controls. Rare and reputationally bad.
• Disclaimer of opinion: Auditor couldn't gather enough evidence to form an opinion.

The audit timeline

For a first-time SOC 2 Type II, the realistic timeline from "we want to start" to "we have a clean report" is 9 to 15 months. Subsequent annual audits are faster.

The audit period (the 3 to 12 month observation window) is non-negotiable. You can't compress it. Most first-time audits use 3 to 6 months for the audit period to get an initial Type II faster, then extend to 12 months in subsequent years.

What's in the report

A SOC 2 Type II report has five standard sections. Here's what each contains and what to actually look at.

Section I: Independent Service Auditor's Report

Two pages. The auditor's formal opinion. This is where they state whether the report is unqualified, qualified, adverse, or disclaimed. Read this first. If the opinion is anything other than unqualified, dig into why before reading further.

Section II: Management Assertion

Three pages of management asserting that the descriptions and controls in the rest of the report are accurate. Mostly boilerplate. Skim it.

Section III: Description of the System

15 to 30 pages. The vendor describes their system, services offered, infrastructure, data flow, and the boundaries of the audit. This is where you find out what was actually in scope.

What to check:

• Does the system description match what you're actually buying from them?
• Are the relevant subprocessors named?
• Are the locations and infrastructure providers listed?
• Are excluded services or features called out?

A common gotcha: a vendor may have SOC 2 for their core platform but not for a specific module you're using. The system description tells you.

Section IV: Trust Services Criteria, Controls, and Tests of Controls

This is the meat of the report. Typically 30 to 60 pages. For every applicable Trust Services Criterion, you'll see:

1. The criterion (e.g., CC6.1: "The entity implements logical access security software, infrastructure, and architectures over protected information assets...")
2. The vendor's controls mapped to that criterion
3. The auditor's tests of those controls
4. The test results (no exceptions, or exceptions noted)

What to check:

• Are exceptions limited and addressed?
• Do the controls listed cover the things you actually care about (encryption, access, monitoring)?
• Are there areas where the vendor is "monitoring" rather than enforcing?

Section V: Other Information Provided by Management

Optional. Sometimes includes additional context not formally part of the audit. Treat as supplementary.

The 5 things that delay SOC 2 most often

After watching companies go through this, the same patterns show up again and again.

1. Insufficient evidence collection. Controls run, but nobody documents them. When the auditor samples, you can't produce proof.
2. Inconsistent access reviews. Quarterly access review gets done in Q1 and Q2, then skipped in Q3 because someone left. That's an exception.
3. Vendor risk gaps. SOC 2 expects you to assess your subprocessors. If you've onboarded vendors without doing risk assessments, the auditor will flag every one.
4. Change management without peer review. Code that ships to production without a PR review or approval ticket. This is one of the most-tested controls.
5. HR control failures. A terminated employee who still has access on day 1 of audit testing. This single finding can become a qualified opinion if it happens to a sampled employee.

How to prepare (the boring but real version)

If you're starting a SOC 2 Type II audit, the honest preparation list:

• Pick the right auditor. Specialty SOC 2 firms (A-LIGN, KirkpatrickPrice, Schellman, AssuranceLab, Prescient) understand SaaS. Big-four auditors are slower and pricier with no real benefit for most companies.
• Do a gap assessment first. Most auditors offer one as a separate engagement. It tells you where your controls don't yet match SOC 2 expectations.
• Pick the right scope. Start with Security only. Add Confidentiality if your customers are asking. Don't take on Privacy or Processing Integrity unless explicitly required.
• Decide your audit period. Three months is the minimum that most auditors will issue a Type II for. Six months is more common for first-time audits.
• Centralize evidence collection from day one. Don't try to gather evidence at the end of the audit period. Use a compliance platform or, at minimum, a structured folder with controls mapped to evidence.
• Run your access reviews on time. This is the single most common exception finding.

How TrustLab fits

Most of the SOC 2 audit experience is evidence wrangling. TrustLab connects to your infrastructure (AWS, Okta, GitHub, Google Workspace, and 40+ other tools) and pulls configuration evidence continuously, so when an auditor samples a control, you have real, current evidence ready instead of scrambling for screenshots.

It also indexes your policies and SOC 2 report itself, so when prospects ask security questions during your sales cycle, the answers come back grounded in the same evidence your auditor relied on.

If you're thinking about SOC 2 prep or want to see how live evidence collection changes audit prep, we'd be happy to walk through it.

The bottom line

SOC 2 Type II is not a security certification. It's an attestation of operating effectiveness over time. Reading one well, or going through one well, requires understanding what was in scope, what controls were tested, and what the exceptions were.

If you're going through SOC 2 for the first time, the headline is: pick the right auditor, scope correctly, collect evidence continuously, run your access reviews on time. Most failures aren't about security. They're about evidence and consistency.

If you're reading someone else's SOC 2 report, the headline is: read the auditor's opinion first, check the system description for scope, and look at the exceptions in Section IV. The badge on their website is the least informative part.