What SOC 2 does and does not tell you

A vendor's website carries a badge: SOC 2 compliant, sometimes with a report available on request. It reads like a seal of approval, the kind of thing a regulator hands out after checking a company's homework. That is not quite what it is, and the gap between the two matters for what you can fairly conclude from it.

What SOC 2 actually is

SOC 2 is a report written by an outside auditor after examining a company's internal controls. "Controls" here means the practical steps a company takes to protect data: who is allowed to log in and see what, how changes to the software get reviewed before they go live, whether anyone is watching for unusual activity. The auditor writes an opinion about whether those controls existed and worked the way the company said they would.

That opinion is called an attestation, not a certification. A certification usually means a company passed a fixed, universal test administered by a certifying body and earned a pass or fail stamp. An attestation is closer to a signed, reasoned letter: this auditor looked at this company's chosen controls and formed a professional opinion about them. It is a real and useful document, just a narrower one than the badge suggests.

Security is the one category every SOC 2 report has to cover. Beyond that, a company chooses which other categories, called trust criteria, to include: availability, confidentiality, and a small number of others. Nothing requires a company to include every possible category, and the badge alone does not tell you which ones this particular report covers.

There are also two versions, Type I and Type II, and they answer different questions. A Type I report checks whether the controls were designed correctly as of one specific date, a snapshot. A Type II report checks whether those same controls actually operated correctly over a stretch of time, not just on paper for a single day.

What it genuinely tells you

A SOC 2 report, at its best, tells you the company took its own security process seriously enough to invite an independent outsider in to examine it. Access controls were looked at: who can reach the systems that hold student data, and how tightly that access is limited. Change management was looked at: whether software changes are reviewed before they reach production, rather than pushed out unchecked.

Monitoring was looked at too: whether the company has a way of noticing when something goes wrong, rather than finding out from someone else. None of that is nothing. A company willing to have these things checked by an outsider, and willing to show you the result, has cleared a bar that many vendors never attempt.

What it cannot tell you

Here is the plain limit: a SOC 2 report says nothing about what the privacy policy permits. It is an audit of whether the doors lock, not a description of where the data is allowed to go once someone with the right key opens them. Those are two separate documents, written for two separate purposes, and passing one says nothing about the content of the other.

A company can pass a SOC 2 audit with flying colors while its privacy policy separately allows selling de-identified data, training an AI system on the content families upload, or transferring everything to a new owner in an acquisition. None of that is a contradiction. The audit was never asking that question in the first place.

Two different questions, two different documents A building labeled "the platform" has a padlock badge on its front reading "SOC 2: are the locks audited?" A delivery truck is shown leaving the building's loading dock on a road labeled "the policy decides what ships out." The audit covers the building's locks; a separate document, the privacy policy, covers what leaves through the loading dock. Two different questions, two different documents the platform SOC 2: are the locks audited? the policy decides what ships out the audit checks the locks; the policy governs the loading dock

What to ask instead of taking the badge at face value

A few direct questions get past the badge to what it actually covers.

Which trust criteria were in scope? Security alone is a much narrower audit than security plus availability and confidentiality together, and the badge does not distinguish between them on its own.

Type I or Type II? A point-in-time snapshot of control design is a different claim than a report covering whether those controls held up over a period of actual operation.

Will they share the report, or at least a summary letter, under NDA? A company confident in its audit usually has no objection to a nondisclosure agreement that lets you or your legal counsel see more than the marketing page shows.

The practical takeaway

A SOC 2 report is a real signal that a company built and tested a security process, and that is worth something. It is not, and was never designed to be, a statement about what the company's privacy policy allows it to do with the data those controls protect.

Ask which trust criteria were covered, whether the report is Type I or Type II, and whether you can see it under NDA. The checklist walks through this question alongside the rest. Two related reads: what a promise that a vendor "never sells your data" actually commits to, and what happens to those same records under the bankruptcy clause most policies quietly include.

Bring this to your next vendor demo: the full checklist.