What SOC 2 Type II means for inference

This is practical guidance, not legal advice. Work with your compliance team on how third-party attestations fit into your vendor risk assessment.

Type I vs Type II — the difference that matters

A Type I report is a snapshot: the auditor confirms that controls are suitably designed as of a specific date. It tells you the provider has the right policies written down. A Type II report requires the auditor to test whether those controls actually worked, continuously, over a defined observation period — typically six to twelve months. For an inference service, that means the auditor verified, month after month, that access controls were enforced, changes were authorized, incidents were managed and monitoring operated as documented. A Type I tells you the design is sound; a Type II tells you it held.

The five Trust Services Criteria

Every SOC 2 report is organized around the TSCs. A vendor may report on some or all of them, and the scope is stated in the report itself. For inference, these are the five and what they mean in practice:

• Security. The core criterion — protection against unauthorized access, both logical and physical. For an inference provider, this covers network segmentation, encryption in transit (TLS 1.3), identity and access management, and physical data-center controls.
• Availability. Whether the system is available for operation as committed. This covers redundancy, capacity management, incident response and disaster recovery — the controls behind a contractual uptime commitment.
• Processing integrity. Whether system processing is complete, valid, accurate, timely and authorized. For inference, this covers the integrity of the request pipeline: that a prompt reaches the model unaltered and the completion is returned without tampering.
• Confidentiality. Protection of information designated as confidential under the provider's commitments. This covers classification policies, encryption at rest, access restrictions and data-disposal procedures.
• Privacy. Collection, use, retention, disclosure and disposal of personal information in accordance with the provider's privacy notice and GDPR's criteria. This is the least commonly reported TSC but particularly relevant for any service touching personal data.

How to read a vendor's SOC 2 report

Don't just confirm the report exists. Read the scope statement first — it tells you which TSCs are covered, which systems and services are in scope, and whether subservice organizations (cloud providers, colocation facilities) are carved out or included. Then read the control exceptions. Every Type II report has a section listing tests that produced exceptions. A clean report with zero exceptions over a twelve-month period is rare; what matters is whether the exceptions are material. A misconfigured alert that was detected and remediated mid-period is very different from a systemic access-control failure that went unaddressed.

SOC 2 is not HIPAA

This is the most common conflation in procurement questionnaires, so it's worth stating directly: SOC 2 is an AICPA audit attestation. HIPAA is US federal law. Holding a SOC 2 report does not make a vendor HIPAA-compliant, and signing a BAA under HIPAA does not produce a SOC 2 report. They are complementary, not interchangeable. A healthcare organization needs both: a BAA for HIPAA coverage and a SOC 2 Type II report for general security assurance. Similarly, SOC 2 doesn't replace GDPR compliance — the Privacy TSC maps to parts of GDPR, but the legal obligations, including the DPA and SCCs, are separate instruments.

How zero retention narrows the audit scope

Every SOC 2 TSC becomes simpler to meet — and simpler to audit — when the service holds no customer content at rest. The Security criterion doesn't need to test encryption-at-rest controls for data that is never written to disk. The Privacy criterion's disposal procedures are trivial when there is nothing to dispose of. The Confidentiality criterion's access restrictions can focus on metadata and operational systems because those are the only assets that exist. This isn't a shortcut — it's a genuine reduction in the control surface the auditor needs to verify. That means a leaner, more focused report with fewer control categories that can produce exceptions.

What to ask for in procurement

• A current SOC 2 Type II report with a clearly stated observation period. If the latest report is more than twelve months old, ask when the next one is due.
• The scope statement — which TSCs are covered and which services and data centers are in scope.
• The bridge letter, covering the period between the last report date and your procurement review.
• A list of subservice organizations and whether each is covered by its own SOC 2 report.
• The exception summary — ask the vendor to walk you through any exceptions, the root cause and the remediation timeline.

A procurement filter, not a stamp of approval

A SOC 2 Type II report is the starting point of a vendor security review, not the end of one. It proves that an independent auditor examined the controls and found them effective over time. But it doesn't replace your own risk assessment — your data classification, your threat model, your integration architecture. The report tells you the provider's controls held up. Whether those controls meet your organization's specific risk appetite is a question only your team can answer. The vendors worth trusting will send you the full report before you ask. For a look at how the full security posture works end to end, a solutions engineer can walk through every layer.