Introduction
"FERPA compliant AI" is one of the most common phrases on AI vendor sites aimed at colleges, and one of the least precise. The Department of Education does not certify software as FERPA compliant. FERPA governs what your institution does with education records; a vendor becomes part of that picture when you disclose records to it, and whether the arrangement complies depends on the contract, the controls, and how the vendor uses the data.
So the useful question for an IR office is not "is this tool FERPA compliant?" It is "can this vendor operate as a school official under our control, and can it prove the controls that requires?" This post walks through the regulation and the Department's guidance, where AI tools raise new versions of old questions, what SOC 2 and the HECVAT do and do not tell you, and a checklist you can send before the second demo.
This is not legal advice. Your general counsel, registrar, and privacy or security office own FERPA interpretation at your institution, and state student privacy laws may add requirements beyond FERPA. Bring them in early.
What FERPA actually requires of a vendor
Most institutions disclose student records to software vendors under the school official exception in 34 CFR § 99.31(a)(1). A contractor or other outside party can be treated as a school official if it performs an institutional service or function your institution would otherwise use employees for, is under your direct control with respect to the use and maintenance of education records, and is subject to the rules in § 99.33(a) on use and redisclosure of personally identifiable information. The Department's Privacy Technical Assistance Center adds that the vendor must meet the criteria in your annual FERPA notification for a school official with a legitimate educational interest.
The Department's guidance for third-party service providers (PTAC, August 2015) turns that into practical expectations. Providers should collect the minimum personally identifiable information needed for the task, use it only for purposes in the contract, avoid data mining for other purposes such as targeted advertising, be clear about de-identification methods, have a breach response plan, and plan for data destruction with a timeline and method. It also warns that contracts letting a vendor change terms unilaterally make it hard for the institution to show direct control.
Two points from that guidance matter more for IR than for most offices. First, PII is broader than names and IDs: indirect identifiers and even aggregate information can be PII if a reasonable person in the school community could identify a student from it. Small-cell tables are an IR problem by nature. Second, the Department's cloud computing FAQ confirms FERPA does not prohibit hosting education records with a cloud provider. Cloud is not the issue; control is.
Where AI changes the question
- Training on your data. The redisclosure and authorized-use rules were written before large language models, but they apply cleanly: if a vendor uses your students' records to train or improve a model that serves other customers, that is a use outside your institutional function. Get the answer in the contract, not the FAQ page.
- Subprocessors you did not pick. Many AI products send prompts and retrieved data to a model provider. That provider is a subprocessor handling your records, so its retention, logging, and training terms matter as much as the vendor's own.
- Prompts and outputs are records too. A question like "which students in my 9 a.m. section are on academic probation" puts PII in the prompt, and the answer contains more. Ask where prompts, retrieved rows, and outputs are logged, for how long, and who can read the logs.
- Permissions at retrieval, not generation. In a retrieval-augmented system, a leak happens when retrieval pulls rows the user should not see; the model then writes them into a friendly paragraph. Access control has to be enforced on the data before the model sees it.
- Aggregates can re-identify. An assistant that will happily answer "retention rate for first-generation international students in the nursing cohort" can produce a cell of two. Ask whether the tool applies any minimum cell size or suppression rule, and whether you can configure it.
What SOC 2 and HECVAT prove, and what they do not
A SOC 2 report is an independent CPA examination of a service organization's controls against the AICPA Trust Services Criteria: security, availability, processing integrity, confidentiality, and privacy. Security is always in scope; the other four are included when the vendor chooses them. A Type 1 report evaluates control design at a point in time. A Type 2 report tests whether the controls operated effectively over a review period, which is why reviewers ask for Type 2. Read the scope section and the list of exceptions, and check which criteria were included. A SOC 2 that covers security only says nothing about the privacy criteria.
The HECVAT (Higher Education Community Vendor Assessment Toolkit) is a standardized security and privacy questionnaire maintained by EDUCAUSE for colleges to send vendors. Version 4, released in early 2025, combined the earlier Full, Lite, and On-Prem versions into one workbook and, as Campus Technology reported, added AI-specific questions and a new privacy section. A completed HECVAT is self-reported, so it tells you what the vendor claims, in a format your security office already knows how to read.
Neither document is a FERPA determination. SOC 2 tells you the controls work; HECVAT tells you what the vendor says it does; the contract is where direct control and authorized use live. You need all three.
The vendor question checklist
Data use and training
Questions to send before the contract stage.
- Will our data, prompts, or outputs be used to train or improve any model, yours or a third party's? Where does the contract say so?
- Which data elements do you need for the use case we described, and can we withhold the rest?
- Do you use de-identified or aggregated data from our institution for any other purpose? Describe the de-identification method.
Subprocessors and model providers
Every party that touches the data, not just the vendor.
- List every subprocessor that receives our data, including model providers, with their roles and locations.
- What are each model provider's retention and training terms for data sent through your account?
- Will you notify us before adding a subprocessor, and can we object?
Access control
Whether the right person sees the right rows.
- Do you support SSO with our identity provider and enforce MFA?
- Is row-level or role-based access enforced before data reaches the model?
- Can a user retrieve records outside their role by rephrasing a question? How did you test that?
- Do you apply minimum cell sizes or suppression to aggregate answers, and can we set the threshold?
Logging, retention, and destruction
Where the records go after the answer.
- Where are prompts, retrieved data, and outputs stored, for how long, and who at your company can access them?
- Can we export our audit logs?
- What is your destruction process at contract end, on what timeline, and will you certify it in writing?
Assurance and incidents
The documents your security office will ask for anyway.
- May we see your current SOC 2 Type 2 report? Which Trust Services Criteria are in scope, and were there exceptions?
- Will you complete the current HECVAT, including the AI and privacy sections?
- What is your breach notification commitment, in hours, and who notifies whom?
- Will you sign our data protection or FERPA addendum, naming you as a school official under our direct control?
Answers that should slow you down
- "We are FERPA certified." No federal FERPA certification exists. Ask what they mean.
- Training terms that live only on a marketing page or in terms of service the vendor can change unilaterally. PTAC specifically flags unilateral changes as a direct-control problem.
- A SOC 2 report that is Type 1 only, more than a year old, or scoped to a different product than the one you are buying.
- No list of subprocessors, or a model provider whose terms the vendor cannot describe.
- Permissions enforced "in the prompt" by telling the model not to reveal certain data. That is an instruction, not an access control.
Running the review
One way to shorten the review is to sequence the scope. Start a pilot on public federal data (IPEDS, College Scorecard) and aggregate institutional data, then add student-level records after the security review clears. That order lets you test whether a tool is useful before you spend your security office's time on the full review, and it keeps student-level records out of the pilot. Small-cell aggregates still need the suppression rules above.
Send the checklist above along with your institution's standard HECVAT request, ask for the SOC 2 report under NDA, and route the contract through whoever owns your FERPA addendum. If the tool will sit behind your identity provider, our guide to setting up SSO shows what that configuration involves on our side. The vendor questions section of our retrieval-augmented generation explainer covers the accuracy side of the same review.
For our own answers, Clema's security overview covers encryption, access controls, and incident response, and is Clema SOC 2 and FERPA compliant? covers our SOC 2 Type II report, the school-official framework we operate under, and the documents your security team can request. Hold us to the same checklist.
Sources
- eCFR, 34 CFR § 99.31: conditions for disclosure without consent, including the school official exception.
- U.S. Department of Education, Privacy Technical Assistance Center, Responsibilities of third-party service providers under FERPA (PTAC-FAQ-5, August 2015).
- U.S. Department of Education, Privacy Technical Assistance Center, Cloud computing FAQ.
- AICPA and CIMA, SOC 2: SOC for service organizations, Trust Services Criteria.
- EDUCAUSE, Higher Education Community Vendor Assessment Toolkit (HECVAT), and Campus Technology, Educause HECVAT vendor assessment tool gets an upgrade (February 2025).
Bring your security questions to the demo
We share our SOC 2 Type II report under NDA and walk your security team through how access control works at retrieval.
Book a demo