FERPA for engineers: the school official exception is an architecture

This describes how FERPA shapes system design. It isn't legal advice, and a district's counsel will have the final word on their own interpretation.

Most engineering teams meet FERPA as a checkbox in a security questionnaire. That framing keeps it invisible until it's expensive, because FERPA isn't really a set of rules about documents. It's a set of constraints on what your system may do with data it holds, and several of them are load bearing on architecture.

What FERPA actually governs

The Family Educational Rights and Privacy Act (20 U.S.C. 1232g, implemented at 34 CFR Part 99) governs education records: records directly related to a student and maintained by an educational agency, or by a party acting for it.

That last clause is you.

FERPA gives parents, and students once they turn 18, the right to inspect their records, to seek amendment of records that are inaccurate or misleading, and to control disclosure. The obligation sits with the district. When a district hands data to a vendor, the vendor inherits the operational half of it.

Note what FERPA is not. It has no breach notification requirement of its own; that comes from state law, covered in the state patchwork. It isn't a security standard. It doesn't tell you to encrypt anything. It's about purpose, control and disclosure.

The school official exception

Ordinarily a district needs written parental consent to disclose an education record. Obviously no district collects consent forms before enabling a maths application for forty thousand students.

What makes vendor software legal is the school official exception, at 34 CFR 99.31(a)(1)(i)(B). A district may treat a contractor as a school official if the contractor:

1. Performs an institutional service or function the district would otherwise use employees for
2. Is under the direct control of the district with respect to the use and maintenance of education records
3. Uses education records only for the purposes for which the disclosure was made
4. Does not redisclose the information without authorisation

Each of those has a consequence in code.

"Under the direct control of the district"

A reviewer reads this as: can the district make us stop, make us export, and make us delete, without depending on our goodwill or our roadmap?

Which means:

• Retention is configurable per district, and the configuration is real. It drives a job, not a policy document.
• Deletion is a supported operation that completes and can be evidenced.
• Export is a supported operation producing the district's data in a form they can keep.
• Your own staff access is governed and logged. "Under the control of the district" is hard to argue when any engineer can query any district's data without a reason recorded.

"Only for the purposes for which the disclosure was made"

This is purpose limitation, and it's the condition most often broken by accident, usually with good intentions.

The district gave you rosters so you could teach mathematics. Using that data to train a general model, to build a cross-district benchmark you sell, to enrich a marketing list, or to power a feature in a different product is outside the purpose. That holds regardless of aggregation, and regardless of what your terms of service say.

The device that keeps teams honest is a data inventory with a purpose per element. Not a diagram. A table listing every field you hold, why you hold it, which feature depends on it, how long you keep it, and which subprocessor sees it.

It takes a day to write. It's the first artefact a privacy review asks for. And writing it reliably surfaces two or three fields nobody can justify.

Delete those. That conversation is much cheaper with yourself than with a district's counsel.

"Does not redisclose"

Every subprocessor is a redisclosure question: your hosting provider, error tracker, analytics, email delivery, support desk, model provider.

Two obligations follow. Keep a subprocessor register that's current and publishable, because you'll be asked and "we'll get back to you" costs a week. And make sure the constraints flow down contractually, so a vendor of yours can't do what you aren't permitted to do.

The one to be careful about: anything sending student text or work to a third-party model provider. That's a disclosure. It needs to be in the register, it needs terms prohibiting training on the data, and it needs to be disclosed plainly rather than discovered. Districts are asking this directly now, and answering it badly is fatal in a way most technical answers aren't.

The two rights that are product features

This is the part engineering teams most often haven't built, and it's needed before anyone asks.

Inspection (34 CFR 99.10). A parent may request to inspect their child's education records, and the district must respond. If your product holds part of that record and can't produce it for one student, the district can't comply.

So: per-student export, executable by a district administrator, covering everything you hold about that child, in a human-readable form. Not a database dump. A parent has to be able to read it.

Amendment (34 CFR 99.20). A parent may request correction of a record they believe is inaccurate or misleading.

So: an amendment path with an audit trail. Something in your system must be correctable by a district administrator, with a record of what changed, when and by whom.

Immutable-by-design event logs create a real tension here. Resolve it deliberately, usually by keeping the event history and layering a correction on top rather than rewriting history.

Neither of these is hard. Both are conspicuously absent from most products, and their absence is noticed by exactly the person whose approval you need.

Directory information is not your call

Districts may designate certain fields (name, grade level, participation in activities) as directory information, disclosable without consent unless a parent opts out. Some parents do opt out, and that opt-out is binding.

Two rules. The designation is the district's to make, never yours. And if your product has any public or semi-public surface (a leaderboard, a shared gallery, a class page with names on it, a certificate with a full name) you need the district's configuration and the per-student opt-out honoured, or you've made a disclosure decision that wasn't yours to make.

Termination

The contract ends. FERPA-derived contract terms almost always require return or destruction of the data.

The failure mode is mundane. Production gets deleted, and the data lives on in backups for ninety more days, in a data warehouse nobody mapped, in a support ticket attachment, in an analytics platform, in a spreadsheet an account manager exported once.

Build deletion as a real capability: enumerate every store, define what happens in each, decide the backup story explicitly, and produce a certificate of destruction. A documented rolling window with the data provably unrecoverable afterwards is defensible. "Backups are forever" is not.

The data inventory you wrote earlier is exactly the map this needs.

The engineering checklist

• A data inventory exists: every element, its purpose, its retention, its subprocessor.
• Purpose limitation is enforced by access paths, not by intention.
• Retention is per-district configuration driving a job that runs.
• Per-student export produces a readable record.
• An amendment path exists, with an audit trail.
• Staff access to district data is scoped, logged and justified.
• The subprocessor register is current, publishable, with flow-down terms.
• Any model provider touching student content is registered and contractually barred from training on it.
• Directory information is district-configured, and opt-out is honoured on every public surface.
• Deletion enumerates every store, including backups, and produces evidence.

None of this needs a rewrite if you do it early. All of it needs one if you don't.