SOC 2 and AI in Education: A Guide for Administrators
A vendor's "SOC 2 Type II certified" badge on its pricing page tells an administrator something real about its security controls, but it is not a law, and it does not equal FERPA, COPPA, or GDPR compliance. SOC 2 is a voluntary audit against the American Institute of CPAs' (AICPA) Trust Services Criteria, performed by an independent CPA firm, producing a SOC 2 Type I or Type II report.
A vendor can hold a clean SOC 2 report and still fail to meet a district's FERPA obligations. A vendor can also satisfy FERPA's contractual requirements without ever undergoing a SOC 2 audit at all. The two run on separate tracks.
Quick Answer: SOC 2 and FERPA are different things regulated by different bodies for different purposes. SOC 2 is a voluntary security-controls attestation performed by a licensed CPA firm under AICPA standards; FERPA (20 U.S.C. § 1232g) is a federal law that makes schools and districts, not vendors, legally responsible for education records. A vendor's SOC 2 report is good evidence of operational security discipline. It says nothing about training defaults, data retention promises, or whether a signed Data Processing Agreement exists, which are the things FERPA actually requires.
That distinction, an accounting-firm attestation versus a federal statute, is the single most important fact in this guide, worth sitting with before anything else. For the full legal picture of what FERPA and COPPA require, see EduGenius's AI, FERPA & COPPA: The Complete School Data-Privacy Guide (2026). This piece explains SOC 2 specifically: what it is, what it proves, and where it fits into an AI procurement decision.
What a SOC 2 Report Actually Is
SOC 2 (System and Organization Controls 2) is an attestation report, not a government certification, issued after an independent, licensed CPA firm examines a vendor's internal controls against the AICPA's Trust Services Criteria. No governing body "certifies" a company under SOC 2; the AICPA sets the standard, but a separate accounting firm performs the actual examination and signs the opinion.
The audit itself follows the AICPA's attestation standards (AT-C Section 205), and the deliverable is the CPA firm's written opinion on whether the vendor's controls meet the criteria, not a badge, a seal, or a pass/fail grade a company can display the way it might display a trademark.
Why "SOC 2 Certified" Is the Wrong Phrase
"Certified" implies a governing body reviewed an application and issued an approval; that is not what happens with SOC 2. A vendor engages a CPA firm directly, pays for the audit, and receives that firm's opinion, which the vendor then chooses whether and how to share.
This distinction is not pedantic. A certification implies a consistent bar every recipient cleared in the same way. An attestation is a specific firm's opinion about a specific vendor's controls during a specific window, worth reading in full rather than trusting as a uniform stamp. Two vendors both truthfully claiming "SOC 2 Type II" can have meaningfully different audit scopes, different CPA firms with different rigor, and different numbers of noted exceptions, none of which "certified" as a word conveys.
The Five Trust Services Criteria
A SOC 2 audit evaluates a vendor against up to five categories, defined in the AICPA's current Trust Services Criteria framework:
- Security (the "common criteria"), required in every SOC 2 report regardless of scope.
- Availability, whether systems stay operational and accessible as agreed.
- Processing integrity, whether system processing is complete, accurate, and timely.
- Confidentiality, whether information designated confidential is protected as agreed.
- Privacy, whether personal information is collected, used, retained, and disclosed in line with the vendor's own stated commitments.
Security is mandatory. A vendor can choose which of the other four to include, which is why two vendors' SOC 2 reports can cover meaningfully different ground even though both say "SOC 2" on the label.
Type I vs. Type II, Explained
The two report types answer different questions, and the difference matters for how much weight a district should give either one:
| Report type | What it evaluates | Time window | What it tells a district |
|---|---|---|---|
| SOC 2 Type I | Whether controls are designed appropriately | A single point in time | The vendor has the right controls on paper as of the audit date |
| SOC 2 Type II | Whether those controls actually operated effectively | A review period, typically 6 to 12 months | The vendor's controls worked in practice, not just in design, over time |
A Type II report carries more weight than a Type I in a district's evaluation, because it demonstrates sustained operating discipline rather than a one-day snapshot. A vendor offering only a Type I report is not necessarily hiding something, but a district should ask when a Type II audit is planned.
The Single Most Important Fact: SOC 2 Is Not FERPA, COPPA, or GDPR Compliance
SOC 2 and student-data privacy laws answer completely different questions, and conflating them is the most common, and most consequential, mistake in AI procurement. SOC 2 asks "does this vendor operate its systems securely." FERPA asks "did this school properly control disclosure of education records." Those are related concerns, but a passing grade on one says nothing definitive about the other.
| Dimension | SOC 2 | FERPA | COPPA | GDPR |
|---|---|---|---|---|
| What it is | A voluntary AICPA attestation standard | A U.S. federal law (20 U.S.C. § 1232g) | A U.S. federal law (16 CFR Part 312) | An EU regulation on personal data |
| Who performs the review | An independent, licensed CPA firm | No third-party review; enforced by the U.S. Dept. of Education | No third-party certifier; enforced by the FTC directly | EU/EEA data protection authorities |
| What it produces | An attestation report (Type I or Type II) | No certificate; compliance runs through a signed DPA | No certificate; voluntary FTC-approved Safe Harbor programs exist | Regulatory enforcement, not a report |
| What it covers | Security, and optionally availability, processing integrity, confidentiality, privacy | Disclosure of "education records" by a school | Collection of personal information from children under 13 | Processing of personal data of EU/EEA residents |
| Binds the vendor directly? | Yes, it's the vendor's own audited controls | No, FERPA binds the school; a vendor participates via contract | Yes, COPPA regulates the operator directly | Yes, for any vendor processing in-scope EU/EEA data |
A vendor can hold a clean SOC 2 Type II report and still have no signed DPA with a specific district, still train its models on inputs by default, or still lack a documented retention policy. None of those gaps show up in a SOC 2 report, because a SOC 2 audit was never designed to check for them.
The reverse is also true, and worth stating just as plainly: a vendor without any SOC 2 report at all can still be perfectly capable of satisfying FERPA's school-official exception, simply by signing a DPA that gives the district direct control, limits the vendor's use of the data, and bars redisclosure. SOC 2 is a useful, verifiable data point about security operations. It was never designed to be, and legally cannot function as, a substitute for the contract FERPA actually requires.
Why AI Specifically Raises the Stakes for This Confusion
Generative AI vendors lean on security credentials in their marketing more heavily than most traditional edtech categories, which is exactly why the SOC 2 versus FERPA confusion shows up so often in AI procurement specifically. A student information system vendor rarely advertises SOC 2 as its headline compliance claim; an AI vendor selling into schools frequently does, often on the same page where "FERPA and COPPA compliant" also appears.
Part of the reason is that AI adds a genuinely new risk SOC 2 was never built to evaluate: whether a model trains on the inputs it receives, and whether that behavior extends through a chain of subprocessors, the foundation-model provider behind the product, that a district never directly contracted with. A SOC 2 report scoped to Security and Availability says nothing about that question, even a Type II report with a clean audit history over a full year.
That gap matters most for the two things a district actually cares about when a student's work goes into an AI system: does the model learn from it, and who else can see it downstream. Both questions belong on the FERPA and COPPA side of a procurement review, in the vendor DPA and its named subprocessor list, not on the SOC 2 side, no matter how prominently a vendor's security page features the audit.
What a SOC 2 Report Can and Can't Tell a District
A SOC 2 report is strong evidence of one thing: operational security discipline. It is weak or silent evidence of almost everything else a district actually needs to know before signing a contract involving student data.
What It's Good Evidence Of
- Access controls: who inside the vendor's organization can reach production data, and how that access is logged and reviewed.
- Encryption practices for data at rest and in transit.
- Incident-response procedures and whether they were actually followed during the audit period, in a Type II report.
- Change-management discipline: whether code and infrastructure changes go through a controlled review process.
What It Says Nothing About
- Whether the vendor trains AI models on the data it processes, by default or otherwise.
- Whether a specific district has a signed DPA satisfying FERPA's school-official exception (34 CFR § 99.31(a)(1)).
- Data retention and deletion timelines, unless the vendor scoped "privacy" into its Trust Services Criteria specifically, which many SOC 2 reports do not.
- Whether the vendor has joined an FTC-approved COPPA Safe Harbor program, such as iKeepSafe, PRIVO, or kidSAFE, which is a separate, COPPA-specific review entirely distinct from SOC 2.
A vendor answering "we have a SOC 2 report" to a question about data training or retention has answered a different question than the one asked. It's a real and verifiable credential, just not the one that resolves that particular concern.
How to Actually Read a Vendor's SOC 2 Report
Most administrators never see the full SOC 2 report itself, only a marketing claim referencing one. Requesting and actually reading the report, not just the badge, changes what a district can verify.
Check the Report Type and Period
Confirm whether it's a Type I or Type II, and if Type II, confirm the review period is recent, ideally within the last twelve months. A Type II report covering a period two years old tells a district less about the vendor's current controls than a fresh one.
Check the Trust Services Categories Included
A report scoped only to Security tells a district less than one that also includes Confidentiality and Privacy. Ask specifically which categories were audited; a vendor's marketing page rarely spells this out unprompted.
Check the Exceptions Section
Every real SOC 2 report includes an auditor's opinion, and many include noted exceptions, instances where a control didn't operate as designed during the review period. A report with zero exceptions across a full year is less common than a report noting a handful, remediated and documented; the presence of exceptions is not automatically disqualifying, but an unwillingness to share that section is a signal worth pursuing.
A Procurement Scenario: Reviewing an AI Tutor's SOC 2 Report
Say you're an administrator evaluating an AI tutoring platform for a Grade 7 math intervention program, and the vendor's proposal leads with "SOC 2 Type II certified." Requesting the actual report shows it's scoped to Security and Availability only, covering a six-month period ending four months ago, with two noted exceptions related to access-log retention, both remediated within thirty days.
That report is genuinely useful: it confirms the vendor takes infrastructure security seriously and responds to findings. It says nothing about whether the platform trains on student responses, what its retention window is, or whether a signed DPA exists for your district specifically. The SOC 2 report becomes one input into procurement, not the deciding factor; the FERPA compliance checklist still has to be run in full alongside it.
You send a follow-up request for the DPA and the training-default answer separately. The vendor provides both within a few days: training off by default for institutional accounts, a 12-month retention window, and a named foundation-model provider with a written no-training commitment extending to it. Only once both pieces, the SOC 2 report and the FERPA-specific answers, are on file together does the review actually close.
Pro Tips for Administrators
- Ask for the report, not the badge. A vendor confident in its SOC 2 posture will share the actual document, under a standard NDA if needed, rather than pointing only to a marketing page.
- Check the Trust Services Categories before assuming coverage. "SOC 2 Type II" alone doesn't confirm Privacy or Confidentiality were included in scope.
- Pair SOC 2 with a separate FERPA and COPPA review, never as a substitute for one. A content-generation tool like EduGenius, built around teacher-managed class profiles with server-side handling of personally identifiable data, still points districts toward requesting a signed DPA and its own retention documentation directly, the same standard any vendor's security posture should be checked against.
- Ask about the model provider's own security posture too, not just the AI vendor's. A SOC 2 report covering the vendor's own infrastructure says nothing about a subprocessor's controls unless that subprocessor is explicitly in scope.
- Track the audit period expiration date. A Type II report is a snapshot of a past window; ask when the next audit period begins so the district isn't relying on a report that's aged out of relevance.
- Keep the SOC 2 request and the FERPA disclosure request on separate lines of your RFP. Bundling them into one generic "security and compliance" question makes it easy for a vendor to answer the easier one and skip the harder one.
What to Avoid: Four SOC 2 Misconceptions That Create Risk
- Treating "SOC 2 certified" as equivalent to "FERPA compliant." No SOC 2 report, however thorough, substitutes for a signed DPA and a documented FERPA review.
- Accepting a vendor's SOC 2 claim without seeing the actual report. A marketing badge is not verifiable evidence on its own; the report itself is.
- Assuming a Type I report proves the same thing as a Type II. A Type I confirms design at one moment; only a Type II confirms controls actually held up over months of real operation.
- Skipping the Trust Services Categories check. A Security-only report leaves privacy and confidentiality questions completely unanswered, no matter how impressive the audit otherwise looks.
- Assuming SOC 2 says anything about model training. Even a full five-category audit was not designed to evaluate whether an AI model trains on the inputs it processes; that question belongs in the DPA, not the audit report.
Key Takeaways
- SOC 2 is a voluntary attestation, not a certification or a law. An independent CPA firm, not the AICPA itself, performs the audit and issues the opinion.
- SOC 2 evaluates up to five Trust Services Criteria: Security (mandatory), Availability, Processing Integrity, Confidentiality, and Privacy, and vendors choose which beyond Security to include.
- Type II reports (a 6-to-12-month review period) carry more weight than Type I reports (a single point-in-time snapshot).
- A clean SOC 2 report does not mean a vendor satisfies FERPA, COPPA, or GDPR. Those are legal frameworks enforced by different bodies, asking different questions than a security audit does.
- Request the actual report, not the marketing badge, and check the report type, the audit period, the Trust Services Categories in scope, and any noted exceptions.
- SOC 2 and a FERPA compliance review are complementary, not interchangeable. Run both; neither substitutes for the other.
- COPPA's Safe Harbor programs (iKeepSafe, PRIVO, kidSAFE) are a separate, COPPA-specific review process entirely distinct from SOC 2, despite both sometimes appearing on the same vendor trust page.
Frequently Asked Questions
Does having a SOC 2 report mean a vendor is FERPA compliant?
No. SOC 2 evaluates a vendor's internal security controls; FERPA is a federal law that makes schools, not vendors, responsible for education records. A vendor can hold a clean SOC 2 report and still lack the signed Data Processing Agreement FERPA's school-official exception requires.
What's the difference between SOC 2 Type I and Type II?
Type I evaluates whether a vendor's controls are designed appropriately at a single point in time. Type II evaluates whether those same controls actually operated effectively over a longer review period, typically 6 to 12 months, making it stronger evidence of sustained security practice.
Who actually performs a SOC 2 audit?
An independent, licensed CPA firm, not the AICPA itself, examines the vendor's controls and issues the report under AICPA attestation standards. The AICPA sets the Trust Services Criteria the audit is measured against, but does not conduct or approve individual audits.
Should a district require SOC 2 in every AI vendor RFP?
It's reasonable to request it as one data point, especially a Type II report, but requiring it as a hard gate can unfairly exclude smaller, newer vendors that haven't completed the audit yet despite having sound practices. Pairing a SOC 2 request with the FERPA-specific disclosure questions gives a fuller picture than either alone.
Does SOC 2 cover whether an AI 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 learns from the inputs it processes. That question needs its own written answer in the vendor's DPA, separate from anything a SOC 2 report covers.
Related Reading
- AI, FERPA & COPPA: The Complete School Data-Privacy Guide (2026)
- Diffit and Student Data Privacy: What Teachers Should Know
- A FERPA Compliance Checklist for AI Tools in Schools
- How Schools Can Use AI Without Violating FERPA
- AI Tools That Don't Train on Student Data
- SchoolAI vs Khanmigo: Which Is Better for Teachers?