What does a SOC 2 report actually tell a buyer?

What a SOC 2 actually attests to

A SOC 2 report tells you whether controls for a defined system were suitably designed and, in a Type II, operated effectively over a specified period against the applicable Trust Services Criteria. That is real assurance, and a company that has been through one is ahead of a company that has not.

What it does not tell you is that the organisation as a whole is secure, or that every risk relevant to a transaction was examined. The examination is bounded by the system the company describes and by the trust categories in scope.

That boundary is the source of most misreadings in diligence. A buyer sees a clean opinion and treats it as an answer. It is closer to a well-documented partial answer, and the useful work is understanding which part.

A colleague once asked, reasonably, how a company could hold a Type II report and still have weak procedures. The answer is usually scope. Controls are frequently built to satisfy a specific examination and support a customer-facing service, not to cover every internal risk the business carries.

Type I and Type II are not the same product

This distinction gets collapsed constantly, and it matters more than almost anything else on the cover page.

A Type I addresses whether controls were suitably designed as at a point in time. A Type II addresses whether they also operated effectively across a period, typically six to twelve months. Type I is a photograph. Type II is a recording.

The work sits in that period. Reaching a Type II opinion requires testing whether controls functioned throughout the observation window, not only that they were designed appropriately at the start of it.

Confusion between the two is common at the planning stage, and expensive when it surfaces late. An organisation budgets for a Type I because that is what it believes customers require, then learns the requirement is a Type II. At that point there is no shortcut. Design testing already performed does not substitute for examining operating effectiveness over a period, because effectiveness over a period is the whole substance of a Type II.

For a buyer: check which one you are holding, and check the length of the observation window. A Type II covering three months tells you considerably less than one covering twelve.

The examination is bounded by a system the company describes

Management prepares the description of the system, including its service commitments, the risks it has identified and the controls it believes address the applicable criteria. The auditor evaluates that description and tests against it. This is a legitimate feature of the framework, since the organisation knows its own environment, and the description itself is prepared against formal criteria.

The consequence for a buyer is that scope is partly a product of how the organisation frames its own system, and there is genuine latitude in that framing. In practice, an organisation has some room to shape what it presents as central to meeting the criteria, and that shaping tends to run toward a cleaner outcome rather than a broader one.

A subsidiary, a legacy platform, a newer product line or a subservice organisation can all sit outside the described system. Where they do, the report stays clean because the excluded thing was never within the examination. Nothing is wrong with the report. It simply answers a narrower question than the one you are asking.

The same applies to trust categories. Security is always in scope. Availability, confidentiality, processing integrity and privacy are elective. A report covering security alone says nothing about uptime commitments or data handling, and buyers routinely assume otherwise.

So a clean opinion does not establish that nothing was wrong. It establishes that what was examined, within the described system and applicable categories, was found to be operating as described.

It was not commissioned for you

A SOC 2 examination exists to give customers and other users assurance about a defined service organisation system. It is commissioned by the service organisation, scoped around its service commitments, and written for user entities and their auditors.

A buyer is not the intended audience. The questions a transaction raises, including whether the technology can support the growth in your model, whether key knowledge is transferable, and whether there is exposure a seller has not identified, are outside what the examination set out to answer.

That is not a criticism of the report. It is the reason a clean SOC 2 and a technology diligence exercise are not substitutes for one another, and why finding one in a data room should change what you ask next rather than reduce it.

How to read one in diligence

Most buyers read the cover page and the opinion. The value is further in.

• Type I or Type II, and the length of the observation period. A short window is weaker assurance.
• Which Trust Services categories are covered. Security alone is common. Availability, confidentiality, processing integrity and privacy are elective and frequently absent.
• The opinion type. Unmodified, qualified or otherwise modified, and if modified, why.
• The description of the system. What is included, and what is not. Look for excluded entities, platforms and product lines.
• Subservice organisations, and whether the carve-out or inclusive method was used. Under carve-out, that provider's controls were not tested in this report.
• Complementary user entity controls. These are the things you are expected to do. If your organisation does not perform them, the assurance does not hold as written.
• Complementary subservice organisation controls, for the same reason one layer down.
• The auditor's tests of controls and results, including the procedures performed and any exceptions.
• Subsequent events, where disclosed.
• The interval between the end of the report period and today, and whether management has provided a bridge letter covering it.

Reading exceptions properly

Exceptions attract more anxiety than they deserve, and their absence attracts more comfort than it deserves.

An exception means the auditor identified an instance where a control did not operate as described, and it comes with management's response. That is information, and it is often more useful than a page with nothing on it.

No reported exceptions does not mean no broader risk exists. It means the auditor identified none through the controls described and the procedures performed. Both statements can be true at once, and the second is the one worth holding in mind.

What this does not mean

Treating SOC 2 as theatre is its own mistake.

A company that has completed a Type II has documented its controls, submitted to outside examination and sustained something over a period. In the lower middle market, plenty of targets have no attestation of any kind, and the difference is real.

The point is calibration. SOC 2 is useful assurance for a defined purpose. Technology due diligence asks a broader and different set of questions, and the report is where that work starts rather than where it stops.