SOC 2 Report: What It Actually Tells You — and What It Doesn’t

Your IT vendor just sent over their SOC 2 report — a 60-page PDF packed with auditor language, control descriptions, and carefully worded opinions. Everyone in the room nods. Nobody reads it. That is a problem. This attestation document is one of the most useful vendor due-diligence tools available, but only if you know what it is telling you and, more importantly, what it is deliberately leaving out. This guide is written for the COO or business owner making a real vendor decision — not for the auditor who produced the document.

What a SOC 2 Report Actually Is

A SOC 2 report is an independent auditor’s written opinion on whether a service organization’s internal controls meet specific criteria — called the Trust Services Criteria — published by the American Institute of Certified Public Accountants. It is not a certification. It is not a license. It is not a government approval. It is an auditor’s opinion, shaped by the scope the vendor chose and the time window the audit covered.

That distinction matters. When a vendor says “we are SOC 2 compliant,” they mean an auditor reviewed the controls they selected, over a period they helped define, and formed an opinion. That is genuinely valuable — but it is not an unconditional clean bill of health.

The five Trust Services Criteria categories are Security, Availability, Processing Integrity, Confidentiality, and Privacy. Security is the only required one. Every other category is optional. Most vendors include only Security; some add Availability. The first thing to check when you receive this kind of attestation document is which categories are actually in scope.

Type I vs. Type II — The Difference That Matters

A Type I report answers one question: “Were the controls designed appropriately at a single point in time?” A Type II report answers the harder question: “Did the controls actually operate effectively over a sustained period — typically six to twelve months?” For vendor due diligence, you want Type II. Type I tells you the vendor drew a good map. Type II tells you they made the trip.

If a vendor offers only a Type I report, that is not automatically disqualifying — they may be in their first audit period. But it is an incomplete picture. Ask when they expect their Type II report and whether they will share it once available. A vendor that has been in business for several years and still has only a Type I warrants follow-up questions.

What the Attestation Covers — and the Scope Boundaries

Every audit of this kind opens with a description of the system under review — the services, infrastructure, and processes that were examined. This section is called the System Description. Most people skip it. Don’t.

The System Description is where the vendor tells you exactly what is in scope — their cloud hosting platform, their ticketing system, their customer data processing environment. If the service they provide to you is not explicitly named or clearly implied there, the attestation does not cover it, even if it was the whole reason you asked for the document.

Read the System Description and ask yourself: “Is what we actually pay this vendor to do described here?” If the answer is unclear, ask the vendor directly before placing any reliance on the document. The Cybersecurity and Infrastructure Security Agency’s third-party risk guidance makes this point directly — scope clarity is the foundation of any meaningful vendor assessment.

What This Type of Attestation Deliberately Leaves Out

This is the section most COOs never hear about. The audit document does not cover everything — and some of those gaps are intentional by design. Understanding them separates a sophisticated buyer from one who accepts a PDF and moves on.

Here is what this attestation does not tell you:

• It does not cover your environment. The document covers the vendor’s controls, not yours. If your own internal IT is weak, a vendor’s clean audit result does not protect you from yourself.
• It does not cover subcontractors or fourth parties. If your vendor uses a subprocessor — a cloud provider, a data center, a backup service — that entity’s controls may be described but are almost never audited as part of the engagement. The vendor’s reliance on a third party is disclosed, not validated.
• It does not evaluate the quality of controls — only their existence and operation. A vendor can have a fully passing attestation and still have controls that are technically compliant but practically weak. “Control was in place” and “control was strong” are not the same statement.
• It does not cover the period between reports. If a vendor’s last Type II audit ended six months ago, you have no visibility into what has changed since. Leadership turnover, infrastructure migrations, and security incidents can all occur in the gap.
• It does not guarantee no breaches occurred. An attestation can be issued for a period during which a breach took place — particularly if the breach happened late in the audit period or had not yet been discovered. Attestation and breach history are two different things.

How to Read the Auditor’s Opinion in Under 2 Minutes

Jump to the auditor’s opinion section near the front of the document. You are looking for one of three outcomes: an unqualified opinion (controls were suitably designed and operating effectively), a qualified opinion (controls were mostly in place, with specific exceptions), or an adverse opinion (significant failures). In practice, nearly all published audit reports carry an unqualified opinion — vendors rarely distribute documents they failed. But the qualifier language still matters.

Look for phrases like “except for” or “with the exception of” in the opinion letter. These signal a qualified opinion. Also check the audit period dates. A document covering three months is very different from one covering twelve. Shorter periods give the auditor less opportunity to observe whether controls held under real operating conditions.

Exceptions, Deviations, and the Ones to Worry About

The most useful part of any Type II audit document is the testing section — the long table listing each control, how it was tested, and whether any deviations were found. Most buyers never read it. This is where the real information lives.

A deviation is not automatically disqualifying. Auditors distinguish between a single instance of a control failing and a pattern of failure. One employee who missed a required training module is categorically different from a finding that access reviews were not completed for the majority of the audit period. Context matters.

When you find deviations, don’t just note them — ask the vendor what they did about them. A vendor who can explain the root cause, show a remediation timeline, and confirm the control has been strengthened is demonstrating exactly the operational maturity you want. A vendor who gets defensive is showing you something else.

The Six Questions Every COO Should Ask After Reviewing the Document

These are the questions that separate a thorough vendor review from a checkbox exercise:

• Which Trust Services Criteria categories are in scope — and why? If Confidentiality is not in scope for a vendor handling your confidential data, that gap deserves a direct conversation.
• What subprocessors are used, and do they carry their own attestations? Ask for evidence, not verbal confirmation.
• What deviations appeared in the testing section, and what is the remediation status? This question alone reveals how seriously the vendor takes the process.
• When does this document’s coverage end, and when will the next one be available? An audit report more than 12 months old is effectively stale. Ask if a bridge letter or interim controls confirmation is available.
• Has anything material changed since this report’s period ended? Leadership changes, platform migrations, or significant client additions can all shift the risk picture.
• Can you share penetration testing results and vulnerability management history? A SOC 2 report and an active penetration testing program are complementary. The attestation does not replace a real-world security test.

What Good Actually Looks Like

A mature IT or cybersecurity vendor will not flinch at any of those questions. They live inside their compliance program year-round — not just during audit season. They can point to specific controls, specific test results, and specific remediation records without being asked twice.

The strongest vendors go beyond a single audit document. They carry multiple layers of independent validation — an annual third-party cybersecurity audit conducted by a credentialed assessor alongside their attestation. They maintain a documented response to every deviation. They treat their compliance program as a business asset, not a vendor questionnaire answer.

That posture is what you want from any vendor who touches your infrastructure, your data, or your client relationships. You can learn more about how Xact IT structures its own security and compliance practices on our cybersecurity services page. If you want guidance on what a rigorous third-party risk assessment looks like in practice, our managed IT services team can walk you through it.

Red Flags That Should Stop the Conversation

Not every vendor attestation deserves equal trust. These patterns should prompt a harder conversation — or a full stop:

• The vendor cannot explain which services fall inside the System Description.
• The audit period is shorter than six months with no explanation.
• Repeated or uncorrected deviations across multiple control areas in the testing section.
• The vendor becomes defensive when asked about deviations or subprocessors.
• The audit document is more than 12 months old and no new report or bridge letter is available.
• The vendor offers only a Type I report for a service that has been in production for several years.
• The auditing firm is unknown, very small, or has no visible credentials in security attestations.

A SOC 2 report is a starting point, not a finish line. Read correctly, it gives you a structured, auditor-backed view into whether a vendor’s stated controls held up over time. Accepted passively — as a PDF filed without being opened — it is compliance theater. The COOs who catch real vendor risk ask the uncomfortable follow-up questions. The document is the door. Those questions are what is behind it.

According to NIST’s Cybersecurity Framework, assessing and monitoring third-party risks is a foundational element of a mature cybersecurity program — and a properly reviewed vendor attestation is one of the most direct tools for doing exactly that.

If you want a second set of eyes on a vendor’s audit documentation before you sign a contract, Book a Free Strategy Call with our team. We’ll tell you what we see in under 20 minutes.