A SOC 2 Compliance Checklist for AI Tools in Schools
When an AI vendor hands your district a SOC 2 report, check six things before treating it as evidence of anything: the report type (Type I or Type II), which Trust Services Criteria are actually in scope, whether any exceptions are noted, whether subservice organizations are disclosed, how recent the report date is, and whether Complementary User Entity Controls apply to your district. A vendor that can't answer these six on request hasn't actually given you a usable report, badge or no badge.
Quick Answer: Don't stop at "do they have SOC 2." Request the actual report, then run it through six checks: Type I vs. Type II, the Trust Services Criteria covered, the exceptions section, named subservice organizations, the report's age, and any Complementary User Entity Controls your district needs to satisfy. And remember going in: SOC 2 is a security-controls audit, not a FERPA, COPPA, or GDPR compliance certificate.
Say your district's technology committee is midway through an RFP for an AI writing-feedback tool, and the vendor's proposal leads with "SOC 2 Type II certified" in bold on page one. That single line tells you almost nothing on its own; a report scoped to Security alone, four months into a stale twelve-month-old audit window, with an undisclosed subprocessor handling the actual model calls, says something very different from a fresh, five-category report with zero exceptions. This checklist is how you tell those two vendors apart.
Before the Checklist: What SOC 2 Is, in One Paragraph
SOC 2 is a voluntary attestation, not a government certification, produced when an independent, licensed CPA firm audits a vendor's internal controls against the AICPA's Trust Services Criteria. No agency issues a pass/fail seal; a private accounting firm examines the vendor and signs an opinion, which the vendor then chooses whether and how to share publicly.
For the full explanation of what SOC 2 is, how Type I differs from Type II, and why "SOC 2 certified" is technically the wrong phrase, see EduGenius's SOC 2 and AI in Education: A Guide for Administrators. This article assumes that background and gets straight to the document itself: what to actually check once a vendor hands you the report.
One fact from that deeper guide is worth restating here, because it's the single most common misunderstanding in AI procurement: a clean SOC 2 report is not proof of FERPA, COPPA, or GDPR compliance. SOC 2 asks whether a vendor's systems are operated securely. FERPA asks whether a school properly controlled disclosure of education records. Those are different questions, audited by different parties, and passing one says nothing definitive about the other. Run this checklist alongside, never instead of, the legal review covered in EduGenius's AI, FERPA & COPPA: The Complete School Data-Privacy Guide (2026).
The Six-Item SOC 2 Report Checklist
Work through these six items in order, every time a vendor sends a SOC 2 report, and write the answer down rather than trusting memory from a sales call.
1. Is It Type I or Type II?
Type I confirms a vendor's controls were designed appropriately on a single date; Type II confirms those same controls actually operated effectively over a review period, typically six to twelve months. A Type II report is meaningfully stronger evidence, because it demonstrates sustained operating discipline, not a one-day snapshot that could have been assembled specifically for the audit.
- Pass: The vendor provides a Type II report, or can explain a specific, near-term date when a Type II audit will complete if currently only holding Type I.
- Red flag: A vendor that's held only Type I reports for multiple years running, with no Type II ever scheduled.
2. Which Trust Services Criteria Are Actually in Scope?
Security is the only mandatory category in any SOC 2 report; a vendor chooses whether to include Availability, Processing Integrity, Confidentiality, and Privacy, and two vendors both saying "SOC 2 Type II" can have audited completely different ground.
| Trust Services Criterion | What it actually verifies | Why a school should care |
|---|---|---|
| Security (mandatory) | Access controls, risk management, basic incident response | The floor every vendor clears; verifies nothing beyond it alone |
| Availability | Uptime, backups, disaster recovery | Matters for tools used during instructional time or exams |
| Processing integrity | Whether the system processes data completely and accurately | Relevant if the AI tool grades, scores, or generates official records |
| Confidentiality | Protection of information designated confidential under agreement | Directly relevant to student work, IEP notes, and behavioral data |
| Privacy | Whether personal data is handled per the vendor's own stated policy | The category most likely to touch retention and disclosure practices, though many reports skip it |
- Pass: The report explicitly covers Security plus Confidentiality at minimum for any tool touching identifiable student data.
- Red flag: A report scoped to Security only, presented as if it answers privacy questions it never touched.
3. Does the Report Include Any Noted Exceptions?
Every real SOC 2 report contains an auditor's opinion, and many legitimately include noted exceptions, specific instances where a control didn't operate exactly as designed during the review period. An exception isn't automatically disqualifying; a handful of minor, promptly remediated exceptions is common and, in a strange way, a sign the audit was genuinely rigorous rather than rubber-stamped.
- Pass: The vendor shares the exceptions section directly, and any exceptions listed are minor, explained, and show a documented remediation date.
- Red flag: A vendor unwilling to share the exceptions section at all, or a report with zero exceptions across a full multi-year run, worth a follow-up question rather than automatic reassurance.
4. Are Subservice Organizations Disclosed?
Most AI vendors selling into schools are not themselves foundation-model builders; they route requests to an underlying provider, commonly OpenAI, Anthropic, or Google, which is a subservice organization the SOC 2 report needs to address one of two ways. The "inclusive method" audits the subservice organization's controls directly as part of the vendor's own report. The more common "carve-out method" excludes the subservice organization's controls from the audit's scope entirely, meaning the vendor's SOC 2 report says nothing about that provider's security at all.
- Pass: The vendor names its subservice organizations explicitly and states which method the report uses, ideally pointing you to that provider's own SOC 2 report if the carve-out method applies.
- Red flag: A vendor that won't name the model provider behind its product, or a report that's silent on subservice organizations despite an AI product obviously depending on one.
5. How Recent Is the Report Date?
A SOC 2 Type II report covers a fixed historical window, commonly the prior six to twelve months, and it starts aging the moment that window closes. A report covering a period that ended eighteen months ago tells you less about the vendor's current controls than a fresh one, especially for a fast-moving AI product where infrastructure and subprocessors change quickly.
- Pass: The audit period ended within the last twelve months, and the vendor can name a specific date for the next audit cycle.
- Red flag: The most recent report available is more than eighteen months old, with no clear next-audit date offered.
6. Are Complementary User Entity Controls (CUECs) Listed, and Can Your District Meet Them?
Most SOC 2 reports list Complementary User Entity Controls near the end of the system description, controls the vendor assumes the customer, your district, will implement on its own side. A district that never reads this section can end up relying on a control that was never actually put in place on either end.
- Pass: Your team reviews the CUEC list, confirms which apply to your deployment, and documents how each one is met (SSO enforcement, admin account review cadence, and so on).
- Red flag: Nobody on the district side has ever read the CUEC section, meaning any gap between the vendor's assumptions and your actual setup stays invisible until an incident forces the question.
A Seventh Check Worth Adding: Who Actually Performed the Audit
A SOC 2 report is only as credible as the CPA firm behind it, and the report's cover page names that firm directly. AICPA membership and licensure are the baseline; beyond that, a firm with a specific practice in technology and SaaS audits generally applies more scrutiny than a generalist accounting firm doing its first SOC 2 engagement. This isn't a formal checklist item the way the six above are, since there's no official tier system to grade auditors against, but it's a reasonable tiebreaker when two vendors otherwise clear the same six checks.
- Pass: The auditing firm is independently verifiable (a real, licensed CPA firm with a public track record of SOC 2 engagements).
- Red flag: The audit firm is difficult to find any independent information about, or the vendor is vague about who actually performed it.
The One-Page Version: A Checklist You Can Bring to a Vendor Call
Print this table, or paste it into your RFP template, and score each vendor against it in one sitting rather than reconstructing the six items from memory.
| # | Check | Ask the vendor | Red flag if... |
|---|---|---|---|
| 1 | Report type | "Is this Type I or Type II, and when is the next Type II audit?" | Only Type I, indefinitely |
| 2 | Criteria in scope | "Which of the five Trust Services Criteria did the audit cover?" | Security only, marketed as full privacy assurance |
| 3 | Exceptions | "Can we see the exceptions section, not just the summary opinion?" | Vendor won't share it |
| 4 | Subservice organizations | "Which subprocessors, including the AI model provider, are named, and inclusive or carve-out method?" | Vendor won't name the model provider |
| 5 | Report date | "What period does this report cover, and how old is it?" | Audit window closed 18+ months ago |
| 6 | CUECs | "What Complementary User Entity Controls does this report list for us?" | District has never reviewed this section |
A Procurement Scenario: Two Vendors, Two Very Different Reports
Say you're evaluating two AI tutoring platforms for a Grade 6 math intervention pilot, and both proposals list "SOC 2 Type II" as a headline credential. Requesting the actual reports changes the comparison entirely.
Vendor A's report covers Security and Confidentiality, closed four months ago, names its foundation-model provider explicitly under the inclusive method, and lists two minor exceptions related to password-rotation timing, both remediated within two weeks. Vendor B's report covers Security only, closed nineteen months ago, doesn't mention a model provider anywhere, and the vendor declines to share the exceptions section when asked directly.
Neither report alone settles the procurement decision, since neither addresses FERPA's school-official test or COPPA's consent pathway. But Vendor A has now answered five of six checklist items with specifics; Vendor B has answered one, poorly. That gap is exactly what "SOC 2 Type II certified" on a pricing page was never going to tell you by itself.
Applying the Checklist to a Content-Generation Tool Specifically
The six checklist items above apply the same way to a teacher-facing content generator as they do to a student-facing chatbot, but a few items get easier to answer depending on the product's architecture. A worksheet or quiz generator built around a teacher-managed class profile, rather than individual student logins, has a narrower scope for items 2 (Confidentiality) and 6 (CUECs) simply because fewer people ever touch the system with credentials that need auditing.
That's a useful lens when you're comparing a content-generation platform against a student-facing tutoring tool in the same RFP. A tool like EduGenius, where a teacher sets a class profile and student-identifying information is kept in server-side data structures rather than exposed to the client, gives a reviewer fewer individual accounts and less client-side exposure to ask a SOC 2 report to cover in the first place. That's a question worth asking any vendor directly: does the product's own design shrink what the checklist even needs to verify, or does every student's individual account expand it?
Pro Tips for Actually Getting the Report
- Ask before you're deep into a sales cycle. A vendor confident in its posture shares the report readily, often under a standard mutual NDA; hesitation this early is itself informative.
- Request the full report, never just a summary letter or a badge image. The exceptions section and CUEC list, the two most useful parts for a school, rarely appear in marketing summaries.
- Keep a shared scorecard across the district, so the technology office, business office, and any teacher-led pilot committee all reference the same six-item review instead of separately re-litigating it.
- Treat ISO 27001 as a reasonable substitute if a vendor offers it instead. It's a different audit framework with a similar purpose, an internationally recognized information-security management standard, and still beats a vendor's own self-description.
- Ask the model-provider question even when a vendor's own SOC 2 report looks clean. A vendor's report can be excellent and still say nothing about the subservice organization actually processing the AI request, especially under the carve-out method.
- Re-run the checklist annually, not just at initial signing. CoSN's May 2025 State of EdTech District Leadership report found 80% of districts already had generative AI initiatives underway while 43% still lacked formal governing policies, a gap that tends to widen, not close, without a recurring review date (CoSN, 2025).
What to Avoid
- Accepting "we have SOC 2" as a complete answer. That sentence alone tells you nothing about which of the six checklist items would actually pass.
- Assuming Type I and Type II carry equal weight. They answer different questions; a district relying on a Type I report for ongoing assurance is relying on a single day's snapshot.
- Skipping the subservice organization question because the vendor's own report looks strong. The FTC's December 2025 enforcement action against Illuminate Education, following a breach traced to unrevoked former-employee access and unencrypted data, is a reminder that a downstream gap can undo an otherwise solid security story (FTC, 2025).
- Filing the report away unread. A SOC 2 report that nobody actually opens past the cover page provides exactly as much protection as not having one, at the cost of a false sense of security.
Key Takeaways
- Six checks turn a SOC 2 report from a marketing claim into usable evidence: report type, Trust Services Criteria in scope, exceptions, subservice organizations, report date, and Complementary User Entity Controls.
- Type II reports (a 6-to-12-month review period) are meaningfully stronger evidence than Type I (a single-day snapshot).
- Security is the only mandatory Trust Services Criterion; a report can say "SOC 2 Type II" while covering nothing about privacy or confidentiality.
- Subservice organizations, especially the underlying AI model provider, are often carved out of a vendor's own SOC 2 scope entirely, which is exactly why naming them matters.
- SOC 2 still is not FERPA, COPPA, or GDPR compliance. Pair this checklist with a legal review, never treat it as a substitute for one.
- A report older than about twelve to eighteen months tells you less about a vendor's current posture than its date on the cover page implies.
- Complementary User Entity Controls put part of the responsibility on your district, and that section goes unread more often than any other part of the report.
Frequently Asked Questions
What's the difference between SOC 2 Type I and Type II for a school procurement decision?
Type I confirms a vendor's controls were designed correctly on a single date; Type II confirms those controls actually worked over a review period, usually six to twelve months. A district evaluating an AI vendor should weight Type II more heavily, since it reflects sustained practice rather than a one-time snapshot.
Does SOC 2 cover whether an AI vendor's model trains on student data?
Generally no. SOC 2's Trust Services Criteria evaluate security, availability, processing integrity, confidentiality, and privacy of the vendor's own stated commitments, not whether an AI model trains on the inputs it processes. That question belongs in the vendor's Data Processing Agreement, not the audit report.
What are Complementary User Entity Controls, and why do they matter to a district?
CUECs are controls a vendor's SOC 2 report assumes the customer, in this case a school district, will implement on its own side, such as enforcing SSO or reviewing admin access regularly. A district that never reads this section can unknowingly be missing a control the vendor's own security model depends on.
Should a district require SOC 2 Type II from every AI vendor before signing?
It's reasonable to require it for any tool touching identifiable student data, but treating it as an absolute gate can unfairly exclude newer, smaller vendors that haven't completed a full audit cycle yet. Pairing the six-item checklist with a direct security questionnaire covers newer vendors more fairly.
Is a SOC 2 report the same thing as being FERPA compliant?
No. SOC 2 verifies technical security controls through independent audit; FERPA is a federal law that makes schools, not vendors, responsible for education records, satisfied through a signed Data Processing Agreement rather than any audit report. A vendor can hold a clean SOC 2 report and still lack that agreement entirely.
What should a district do if a vendor refuses to share its SOC 2 report at all?
Treat that refusal as a data point, not a dead end. A vendor with a real report under a standard NDA usually shares it once asked directly; a vendor that deflects repeatedly, or offers only a marketing summary, hasn't given you anything the six-item checklist can actually evaluate, which is itself worth weighing against a competitor that does share the full document.
Related Reading
- AI, FERPA & COPPA: The Complete School Data-Privacy Guide (2026)
- SOC 2 and AI in Education: A Guide for Administrators
- A Data Security Compliance Checklist for AI Tools in Schools
- How Schools Can Use AI Without Violating Student Data Privacy
- Data Security and AI in Education: A Guide for Administrators
- SchoolAI vs Khanmigo: Which Is Better for Teachers?