X

SOC 2 Type II is an auditor's report that a vendor's controls operated over months. What it covers, what it leaves out, how to read one, and when it matters.

SOC 2 Type II is an independent auditor's report stating that a vendor's security controls were not only designed appropriately but actually operated over a defined period of months. For a nonprofit buyer it is evidence that someone outside the vendor checked; it is not a certification that your data is safe, and it says nothing about how your own organization uses the product.

The name comes from the AICPA's System and Organization Controls framework. A SOC 2 report evaluates a service organization against trust services criteria covering security and, optionally, availability, processing integrity, confidentiality, and privacy. The distinction between the two report types is the one buyers most often miss.

Type I versus Type II

A Type I report describes the controls as of a single date and states whether they are suitably designed. A Type II report covers a period and states whether the controls operated effectively throughout it. Type II is the one procurement teams mean when they ask for "SOC 2," because a control that exists on paper and a control that ran every day for a year are different claims.

Before a first Type II report exists, a vendor goes through an observation period: the controls are in place, evidence is collected, and the auditor examines that evidence at the end. A vendor in this stage can honestly say "in observation, report expected on a date." It cannot honestly say "SOC 2 certified," and a buyer should hear those two statements differently.

What the report covers, and what it does not

It covers the vendor's own systems and processes within the scope the vendor defined. Scope is the first thing to read: which services, which environments, which criteria.

It usually carves out subservice organizations. A vendor running on a cloud provider or a managed authentication service relies on those providers' own reports for the infrastructure layer. That is normal. The question is whether the vendor's report addresses the vendor's controls on top of that infrastructure, or whether the vendor is pointing at a subprocessor's certification as if it were its own.

It does not cover your configuration. Who at your organization has administrator access, whether MFA is enforced, who was offboarded, what was uploaded: none of that is in the vendor's report. The shared-responsibility model exists precisely because the audit stops at the vendor's boundary.

It is a point-in-period document. A report covering last year describes last year.

When it matters for a nonprofit

Audit firms that work with the sector report that government agencies and corporate sponsors increasingly expect or require proof that the nonprofits they fund follow industry-standard security practices, and a larger organization's evaluation committee will usually ask for the report by name. Whether it matters for your organization depends on your funders, your board, your data, and your own risk tolerance. A three-person organization with no client records and a ten-person committee evaluating a platform that will hold health-adjacent data are asking different questions, and both are reasonable.

What a report does for any buyer, regardless of size, is replace a vendor's self-description with an outsider's examination.

How to read one

Read the auditor's opinion first; a qualified opinion means exceptions were significant. Read the scope and the period. Read the list of exceptions, where the auditor found a control that did not operate as described, and the vendor's response to each. Read the complementary user entity controls, which are the things the auditor assumed you, the customer, would do. Then check the subservice organizations and whether their reports are current.

Reports are typically shared under NDA. Asking for one is normal; a vendor that refuses to share a report it claims to have is a finding in itself.

TappHQ's status, stated plainly

TappHQ is in an active SOC 2 Type II observation period, with an independent auditor engaged, evidence collection underway, and a Type II report targeted for Q4 2026. The authentication backbone, Supabase, holds its own independent SOC 2 Type II certification today. ISO 27001 and HIPAA business associate agreement support are sequenced after the SOC 2 report. That is the whole status; the trust page states it the same way, with the controls in scope listed alongside, because the honest version of "in progress" is more useful to a buyer than a badge would be.