FERPA for vendors

Most edtech vendors receive student records under the school official exception in 34 CFR 99.31(a)(1). The exception normally covers a school's own staff, but the regulation lets a school treat a contractor, consultant, volunteer or other outside party as a school official when it has outsourced an institutional service or function to that party.

The outside party qualifies only when all of the following are true. It performs a service or function the school would otherwise use its own employees for. It is under the direct control of the school with respect to the use and maintenance of the education records. It is subject to the redisclosure limits in 34 CFR 99.33(a), which means it uses the records only for the purposes the school authorized and does not pass them on. And it meets the criteria the school published in its annual notice for who counts as a school official with a legitimate educational interest.

Read those conditions as a description of the relationship a district expects. The vendor is an extension of the school, doing a job the school assigned, on the school's terms. Anything that looks like the vendor using student data for its own purposes breaks that picture.

Direct control is not defined precisely, and that is why contracts carry so much weight. Districts usually establish it in writing: a services agreement and a data privacy agreement that say what data the vendor receives, what it may use the data for, who at the vendor can access it, how it is secured, when it is deleted, and what happens in a breach. The Department of Education's guidance on online educational services recommends exactly this kind of written agreement, and warns that click-through terms of service a teacher accepts on their own can leave the school without the control the exception requires.

For a vendor, direct control usually shows up as product and operations requirements. The district can see and export its data. The district can ask for deletion and get a confirmation. Access inside the vendor is limited to staff who need it, and that access is logged. Data is not combined across customers in ways the district did not approve. Sub-processors are disclosed and bound by the same terms.

The school must also use reasonable methods to make sure school officials, including vendors, access only the records in which they have a legitimate educational interest (99.31(a)(1)(ii)). That is the regulatory root of role-based access control in a school product: a counselor sees their caseload, a teacher sees their sections, and an engineer debugging production should not be browsing student records without a reason.

Under 34 CFR 99.33, a party that receives PII from education records may not redisclose it without consent, except in the ways the regulations allow, and may use it only for the purposes for which the disclosure was made. A vendor that sells the data, shares it with an advertising partner or hands it to an unrelated affiliate has crossed this line.

FERPA has a specific consequence for third parties here. If the Department of Education determines that a third party improperly redisclosed PII, the school may not give that third party access to PII from education records for at least five years (99.33(e)). For an edtech company that sells to schools, that is close to a business-ending penalty, and it applies even though FERPA does not otherwise regulate vendors directly.

Vendors collect more than the records a school sends. Usage logs, clickstreams, device data and timestamps are generated as students use a product. The Department's online services guidance points out that metadata linked to a student can be PII from education records, and that properly de-identified metadata can be used for purposes such as improving the product, if the contract allows it.

The safe pattern is to be explicit. State in the agreement what operational data the product collects, whether any of it is used beyond delivering the service, and how it is de-identified first. A vague right to use data to improve services is one of the clauses district reviewers flag most often.

FERPA was written long before large language models, but its structure applies cleanly. The questions to ask about any AI feature are the same ones the school official exception asks about any processing. Is this use part of the function the school outsourced to us? Is the data going to anyone else, including a model provider, and are they bound by the same limits? Does any student data leave the purpose the school authorized?

Three patterns deserve the most care. First, sending student records to an outside model API makes the model provider a sub-processor, so its terms on data retention and training must match your obligations. Second, using one district's student data to train or fine-tune a model that serves other districts is very hard to square with use only for the authorized purpose, and districts increasingly prohibit it in writing. Third, retrieval features that pull from a shared index can expose one school's records to another school's users if access control is not enforced at retrieval time. Track 3 covers how to test for that.

This module's reading of FERPA for AI is a practical interpretation for learning purposes, not legal advice. When a decision matters, check the current guidance from the Student Privacy Policy Office and talk to counsel.