SOC 2 Type II
SOC 2 Type II is an audit report in which an independent CPA firm tests whether a service organisation's stated controls were designed appropriately and operated effectively over a defined period, usually three to twelve months. It is an attestation about a company's processes, not a certification of a product.
| Substitute | What it evidences | Strength | Cost to the vendor |
|---|---|---|---|
| Independent penetration test with a scoped report | That a third party attacked the actual system and what they found | Strongest available substitute | High |
| Isolation and security tests running in continuous integration | That the control is verified on every change, not once a year | Strong, and continuous rather than point-in-time | Low, if built in from the start |
| Published architecture describing the enforcement mechanism | That claims are specific enough to be falsified in a technical review | Moderate — verifiable by your team, not by an auditor | Low |
| Contractual breach notification, indemnity and audit rights | What happens if it goes wrong, and who pays | Moderate — remedy rather than prevention | Low |
| Signed state DPA and Student Privacy Pledge | Commitment to data-use limits | Baseline, not evidence of security controls | Low |
| A completed security questionnaire | What the vendor says about itself | Weakest — self-assertion | Low |
Type I versus Type II, and the trust services criteria
Type I tests whether controls are suitably designed at a single point in time. It is a photograph. A vendor can pass by having written policies that existed on the audit date.
Type II tests whether those controls operated effectively across a period — the auditor samples evidence from throughout the window. It is the one worth asking for, and the period length matters: a three-month window is the minimum and considerably weaker than twelve.
Reports are scoped to one or more of five Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality and Privacy. Only Security is mandatory, and most reports in the market cover Security alone. A vendor saying "we are SOC 2 Type II" without naming the criteria has usually told you they were audited against one of five. If availability matters to you, ask whether Availability is in scope; if student data handling matters, ask about Privacy and Confidentiality.
Two further things to read rather than accept. The opinion: unqualified is clean; qualified means the auditor found something. And the exceptions section, which lists control failures observed during testing — a report can carry an unqualified opinion and still document exceptions worth discussing. Finally, check what is in scope: a report covering a corporate environment but excluding the production system you are buying is not uncommon.
What it does not prove
SOC 2 attests that a company followed its own stated controls. It does not establish that the controls are the right ones, that the product is well engineered, or that a specific vulnerability class has been addressed. A vendor can hold a clean Type II report and ship a product with a cross-tenant data leak, because tenant isolation architecture is not something the framework specifically tests.
It is also expensive — typically tens of thousands of dollars annually, plus internal effort — which means it functions partly as a proxy for company size and funding. That is a legitimate thing for a district to care about. It is not the same thing as security, and conflating the two is how procurement processes end up excluding smaller vendors with better architecture while admitting larger ones with worse.
Our own position, stated plainly
Kastr does not have a SOC 2 report of any type. We are pre-launch, we have not engaged an auditor, and there is no audit in progress. Any page on this site or elsewhere that implies otherwise is a defect we want reported.
What we offer instead, mapped to the table above: isolation tests that run in continuous integration against real Postgres 16 on every change, including an owner-bypass regression check; a published architecture describing exactly how row-level security, the non-owner role, and the hash-chained audit log work, in enough detail that your team can falsify it; and contractual terms covering export (§7.1), family data use (§9.4) and change of control (§11.2). We have not commissioned an independent penetration test. If SOC 2 Type II is a hard requirement in your procurement, we do not meet it, and that is a legitimate reason to buy elsewhere.
How to actually read a report you are given
- Check the period covered and whether it ends recently. A report covering a window that closed fourteen months ago tells you about last year's company.
- Check the criteria in scope. Security only, or more?
- Check the system description for the boundary. Does it include the production environment that will hold your student data?
- Read the opinion, then read the exceptions. Do not stop at the opinion.
- Read the complementary user entity controls — the things the report assumes you do. These are frequently overlooked and are sometimes substantial.
- Check the subservice organisations and whether they are carved out or included. A carve-out means the auditor did not test them, and your data may sit there.
Questions people actually ask
What is the difference between SOC 2 Type I and Type II?
Type I evaluates whether controls are suitably designed at a single point in time. Type II evaluates whether they operated effectively across a period, usually three to twelve months, with the auditor sampling evidence throughout. Type II is substantially more meaningful, and the length of the period matters — three months is the floor, not a good result.
Does SOC 2 mean a product is secure?
No. It means an auditor tested the controls the company said it had and found they operated. It says nothing about whether those controls are the right ones for the risk, and nothing about product architecture — a vendor can hold a clean report and still have a tenant isolation flaw, because the framework does not test that specifically.
Can a district buy from a vendor without SOC 2?
Yes, and many do, particularly for smaller or newer vendors. What a district should do is substitute deliberately rather than waive silently: require a scoped penetration test, security tests running in continuous integration, published architecture, and contractual breach and indemnity terms. Document the substitution in the file, because that is the question that gets asked afterwards.
What should a district ask for if a vendor has no SOC 2 report?
In order of evidentiary value: an independent penetration test report, evidence that isolation and security tests run automatically on every change, a published description of the enforcement mechanism specific enough to verify, and contractual breach notification with indemnity. A completed questionnaire is the weakest of these because it is self-assertion.
One price. Every feature. Locked for three years.
$3.50 per student per year under 5,000 students. No tiers, no add-on modules, no per-message fees. Published on the site because you should not have to book a call to learn a price.