Legitimate educational interest
Legitimate educational interest is the condition attached to FERPA's school official exception: a school official may access personally identifiable information from education records without consent only where the official needs the record to carry out their responsibilities for the district.
| Enforcement layer | Stops an honest mistake | Stops a bug in the query | Stops a compromised admin session | Evidence you can show an auditor |
|---|---|---|---|---|
| Policy and annual training only | Sometimes | No | No | A signed acknowledgement |
| Application-layer permission checks | Yes | No — one missing filter exposes everything | No | Code review |
| Database row filtering under the app's own role | Yes | Usually | No | Migration files |
| Row filtering under a non-owner role, failing closed | Yes | Yes — a query with no org context returns nothing | Limits blast radius to that org | Migrations plus a CI suite that tries to leak |
| Append-only hash-chained audit log | Detects, does not prevent | Detects | Detects, and tampering breaks the chain | The chain itself |
What the district has to define
FERPA does not define legitimate educational interest. It requires the district to define it, in the annual notification, along with its criteria for who counts as a school official. That is a deliberate delegation: a bus driver's need-to-know is not a federal question.
A workable definition names the two halves. Who is a school official — employees, board members acting in that capacity, contractors performing an institutional service, and volunteers under direct control. What makes the interest legitimate — the record is required to perform a duty stated in the person's role.
The regulation then adds an obligation districts routinely skip: the district must use reasonable methods to ensure school officials obtain access only to records in which they have a legitimate educational interest. That is a technical control requirement written in administrative language. A district whose only method is an annual training slide has not met it, and the regulation says as much by noting that a district without effective methods is expected to limit access physically or administratively instead.
What contractors have to satisfy
A vendor sits inside the exception only when three things hold at once. It performs an institutional service or function the district would otherwise use employees for. It is under the direct control of the district with respect to the use and maintenance of education records. And it is subject to the same limits on redisclosure and on use for other purposes that bind the district itself.
The middle condition is where vendors fail quietly. Direct control means the district decides what the data is for. Several common ed-tech business models are incompatible with it: selling a family-facing subscription built on district-supplied contact data, monetising engagement, or using district data to train a product sold elsewhere. None of those are exotic. One large platform in this category monetises families directly at about $10 a month.
What Kastr can and cannot show here. Access is filtered in Postgres under a non-owner, DML-only role set inside every transaction, so table ownership cannot bypass the policies and a request with no organisation context returns zero rows. A district sees its own and its child schools' rows and no one else's. A cross-tenant leakage suite runs in CI against real Postgres 16, including an owner-bypass regression check. Staff actions land in an append-only, SHA-256 hash-chained audit log. We have no SSO, SAML or MFA — magic-link email is the only authentication we support, and if your district requires federated staff authentication as a control, we do not meet that requirement today.
Documenting it so it survives review
Three artefacts do most of the work in a review, and all three are cheap to maintain:
- A role-to-record matrix. Which roles may see attendance, discipline, health, special education, contact and message records, with a one-line justification per intersection. Most districts have this implicitly in their SIS permission groups and have never written it down.
- The annual notification's criteria, updated when a new category of contractor appears. A district that added three vendors since its notification was written has three undocumented school officials.
- An access log you did not write yourself. The point of a tamper-evident log is that it is evidence rather than assertion. A log an administrator can edit proves only that nobody bothered.
The question that separates vendors quickly is not "do you support permissions". It is "if one of your engineers writes a query and forgets the district filter, what happens?" There are only two honest answers, and only one of them is that the database returns nothing.
This entry describes what the rule says. Whether and how it applies to your district is a question for your own counsel, not for a vendor.
Questions people actually ask
Can any teacher look up any student's records?
Not under FERPA's standard. Access is limited to officials with a legitimate educational interest as the district defines it, and the district is required to use reasonable methods to enforce that limit rather than relying on trust. In practice this is implemented as role-based permissions in the SIS and in every downstream system.
Does the school official exception cover outside vendors?
It can, where the vendor performs a service the district would otherwise perform with employees, is under the district's direct control as to the use and maintenance of the records, and is bound by the same redisclosure limits. The district's annual notification must reflect that contractors may be school officials.
How should a district document legitimate educational interest?
By defining the criteria in the annual notification, maintaining a role-to-record access matrix, and keeping an access record that cannot be edited by the people it records. The combination is what makes the position defensible if it is ever questioned.
What technical controls actually enforce need-to-know?
Application-layer permission checks stop honest mistakes but fail entirely if one query omits a filter. Database-layer row filtering under a role that cannot bypass it fails closed instead, so a missing filter returns nothing rather than everything. An append-only audit log detects what neither prevents.
One price. Every feature. Locked for three years.
$3.50 per student per year under 5,000 students. No tiers, no add-on modules, no per-message fees. Published on the site because you should not have to book a call to learn a price.