SOC 2 Type II is the baseline certification for enterprise software, and rightly so. It is the first artefact a law firm's information-security team requests, and effectively every legal AI vendor either holds one or is pursuing one. It is also, measured against the specific risk a firm is carrying, an incomplete answer — and the incompleteness is systematic rather than incidental.

What the report attests

A Type II report is an auditor's opinion that the controls a vendor described were suitably designed and operating effectively across a defined observation period, against selected trust services criteria. Two features of that sentence do most of the work. The vendor describes the controls, and the vendor chooses the scope.

Neither is a criticism of the framework — it was built for exactly this, and it does it well. It simply means the report answers "did they do what they said" rather than "was what they said appropriate for privileged legal material".

The gaps that matter here

Four of them recur, and none is addressed by the badge on the website.

  • Scope: the report may cover the SaaS platform while the inference path sits outside the boundary
  • Isolation: controls typically evidence tenant separation, not matter separation inside a tenant
  • Model pathways: context assembly, retrieval indexes, caches and evaluation samples are rarely enumerated as data flows at all
  • Sub-processors: the model provider behind the vendor is often a separate assurance question the report does not reach
SOC 2 tells you the vendor has good processes. It does not tell you their architecture is appropriate for privileged legal work.

The frameworks that go further, and where they stop

ISO/IEC 27001 certifies an information security management system and is stronger on governance than a point-in-time attestation. ISO/IEC 42001, published in 2023, is the first management-system standard for AI specifically and asks useful questions about oversight and lifecycle. The NIST AI Risk Management Framework gives a serious vocabulary for describing what could go wrong.

All three are worth having and none of them answers the firm's question either, for the same structural reason: they certify that an organisation manages risk deliberately. They do not certify that a particular architecture keeps one client's matter out of another's, and they were never intended to.

What to ask for instead of the badge

Certification is a filter, not a finding. Once a vendor has passed it, the questions that actually discriminate are architectural, and they are answerable in a paragraph each: where the matter boundary is enforced, whether retrieval is scoped at index time, what is retained in caches and operational logs, whether the audit record is produceable without the vendor, and which of these are properties of the system rather than commitments of the company.

The distinction in that last clause is the whole subject. A commitment is only as good as the company behind it and is tested only after something has gone wrong. A property holds because there is no code path by which it could fail — and a firm can verify it, which is the part that survives a change of ownership, a change of terms, or a bad quarter.

Ask for the report. Read the scope section first. Then ask the five architectural questions, and notice which ones produce a diagram and which produce a paragraph of reassurance.