SOC 2 Type II Explained: What Certified Means and How to Verify a Vendor

SOC 2 Type II is an independent auditor's report confirming that a company's security, availability, and other controls were not just designed well, but actually operated effectively over an extended observation period. It is the standard most enterprise buyers look for before trusting a vendor with their data.

Torii is SOC 2 Type II compliant (details, and a direct line to our security team, are on our security page). This guide covers what SOC 2 Type II actually means, how it differs from Type I, and the concrete steps to verify that a vendor's SOC 2 claim holds up before you rely on it.

💡Key Points:

• SOC 2 Type II tests whether a company's controls actually operated effectively over an observation period of several months, not just whether they were designed well.
• SOC 2 is an attestation report from an independent, licensed CPA firm, not a certificate, so "SOC 2 certified" is really shorthand.
• A badge or logo on a website proves nothing on its own. Only the report itself, and the auditor's opinion inside it, counts as evidence.
• Torii is SOC 2 Type II compliant, and preparing for your own audit gets easier with a clear controls checklist.

What Is SOC 2 Type II?

SOC 2 stands for System and Organization Controls 2, an auditing framework maintained by the American Institute of Certified Public Accountants (AICPA). A SOC 2 report is produced by an independent, licensed CPA firm that examines a company's controls against the AICPA's Trust Services Criteria.

Technically, SOC 2 is an attestation report, not a certificate. There is no badge-issuing body and no pass or fail stamp. When people say a vendor is "SOC 2 certified," they really mean the vendor went through an audit and received a report with the auditor's opinion attached. That shorthand is common enough that it isn't worth fighting, but it's worth understanding what's actually being claimed.

The "Type II" part matters most. A Type I report checks whether controls were designed appropriately at a single point in time. A Type II report goes further: the auditor observes whether those controls actually operated effectively across an observation period, usually several months. Type II is the version most enterprise buyers ask for, because it tests real behavior, not just a policy document.

The Five Trust Services Criteria

Every SOC 2 report is built on the AICPA's Trust Services Criteria. Security is mandatory in every SOC 2 report; the other four are optional, and a company chooses which ones apply to its systems and scope.

• Security: protection against unauthorized access, both physical and logical. This is the "common criteria" required in every SOC 2 report.
• Availability: systems are available for operation and use as agreed.
• Processing integrity: system processing is complete, accurate, timely, and authorized.
• Confidentiality: information designated as confidential is protected as committed.
• Privacy: personal information is collected, used, retained, and disposed of in line with the company's privacy notice.

When you review a vendor's report, check which of these criteria are actually in scope. A report that only covers security says less than one that also covers availability and confidentiality.

SOC 2 Type I vs. Type II

A Type I report is a reasonable first step for a young company, but it isn't the same assurance as a Type II report. If a vendor only has a Type I report, ask when they expect to complete their first Type II observation period.

SOC 1 vs. SOC 2 vs. SOC 3

These three report types are often confused, but they answer different questions.

• SOC 1 covers controls relevant to a customer's financial reporting, the kind of report a payroll or billing vendor provides to support its customers' own financial audits.
• SOC 2 covers security, availability, processing integrity, confidentiality, and privacy. It's a detailed, restricted-use report typically shared under NDA with customers and prospects.
• SOC 3 is a general-use summary of a SOC 2 report, written for public distribution. It confirms the same audit took place without disclosing the detailed findings.

If a vendor only publishes a SOC 3, you can still request the full SOC 2 report for the detail a real security review needs.

How to Check Whether a Vendor Is SOC 2 Type II Compliant

1. Look for a trust center or security page. Most vendors that take compliance seriously list their SOC 2 status, along with other certifications, on a dedicated security or trust page.
2. Request the full report. The complete SOC 2 report is usually shared under NDA, not posted publicly. Ask the vendor's sales or security contact for a copy.
3. Confirm the auditor is an independent, licensed CPA firm. The report should name the firm and confirm it holds the appropriate license; this is who is actually attesting to the findings.
4. Confirm it's Type II and check the period dates. Look for the observation period's start and end dates. If the period ended a while ago, ask for a bridge letter covering the gap until the next report.
5. Check the scope. Confirm which product or system the report covers, and which Trust Services Criteria are included. A report can be accurate and still not cover the system you actually use.
6. Read the auditor's opinion and any exceptions. Look for a qualified opinion or noted exceptions, and read the vendor's management response to understand how they were addressed.
7. Note carve-outs and your own responsibilities. Reports often carve out subservice organizations, like the cloud host, and list complementary user entity controls, the things your organization is responsible for configuring correctly on its own end.

A SOC 2 logo, badge, or SVG on a website is marketing, not evidence. Only the report itself, with the auditor's opinion inside it, tells you whether a vendor's controls actually held up.

Why Vendor SOC 2 Reviews Break Down as SaaS Sprawls

You can only review the vendors you know about. In most organizations, a meaningful share of SaaS apps are bought on a company card or adopted by individual teams without ever reaching security review, the same shadow IT and shadow AI problem that makes SaaS management relevant to SOC 2 compliance in the first place. An app nobody on the security team knows about can't have its SOC 2 report checked, its bridge letter tracked, or its renewal reviewed.

Even for apps that did go through review once, SOC 2 reports expire. A vendor's observation period ends, a new report comes out, and nobody re-checks it until the next renewal, if there's a process for that at all.

This is where SaaS management helps, without replacing the audit itself. Discovery finds every app in use, including the ones nobody submitted for review. A vendor's SOC 2 report and other security documentation can be attached directly to that app's record, and renewal dates can trigger a re-review instead of relying on someone remembering to check.

What We Learned Getting Torii SOC 2 Type II Compliant

Security and compliance have been a priority for our product and engineering teams from day one. Torii manages mission-critical SaaS applications and the data inside them, so undergoing an independent audit like SOC 2 was never really a question: it was a matter of when.

Torii completed SOC 2 compliance in 2019 as a small team of 20 employees, and came through its Type II observation period with no exceptions noted. Here's what made that possible.

Small Means Agile

For a young company, starting the SOC 2 process can feel daunting. It touches almost every part of the product and the business, and every ongoing practice has to hold up under review. But a company's youth is an asset here: crafting things as they should be at an early stage is easier than fixing long-lived, ill-fitting processes. With a small team fully on board, implementing the necessary changes moved quickly.

Compliance Is a Means, Not a Goal

Compliance is one factor in the business, not the end goal. Treat it as a way to surface problems or gaps, then design controls that fit cleanly into existing workflows. Forcing new processes that don't fit, just to satisfy a checklist, can introduce more risk than it removes. Any procedural change should be made strategically, not defensively.

Culture Over Obligation

A SOC 2 audit isn't a one-time test or a box to check. The policies and procedures a company commits to need to become a real part of its culture, not a document that only gets read before an audit. We think of it as a marathon, not a sprint: even after crossing the finish line of one audit, the work shifts to evaluating what could be better for the next one.

Automation Is Key

The whole point of a framework like SOC 2 is clear, repeatable procedures and controls. Managing the volume of information an organization produces every day is a task in itself, and automation is what makes that manageable at scale.

We built our own automation with auditability in mind, so that when it comes time to show what happened or prove a procedure was followed, a report is already there to produce. That same principle, automating controls so evidence collects itself, is also what makes getting audit-ready faster the second time around.

Getting Ready for Your Own SOC 2 Type II Audit

If you're heading into your own SOC 2 Type II audit, the controls list lives in a separate guide: 7 best practices for your SOC 2 controls list. Auditors look closely at onboarding and offboarding evidence and access reviews, the kind of control that's easy to document once and hard to keep current manually as your app stack grows.

Request a demo to see how Torii keeps that evidence current automatically.