Under FERPA section 99.33(a), a party receiving education records may use them only for the purposes for which they were disclosed and may not redisclose them without consent. For an edtech product, that turns analytics tools, cloud services and support platforms into questions about whether each one is covered by the same limits.
What the rule says
The Department of Education's student privacy page states that a receiving party may use records only for the purposes for which they were disclosed, and may not redisclose them without consent. It adds that if a third party improperly rediscloses records, the institution may not give that third party access to education records for at least five years (section 99.67(e)).
Education records are records directly related to a student and maintained by the institution or by a party acting for it. Personally identifiable information from them includes names, addresses, identifiers and other information that could identify a student.
Where redisclosure hides in a product
Teams usually mean well. The leaks are architectural.
- Analytics and session replay that capture names or student IDs from page content.
- Error tracking that stores request bodies containing grades or messages.
- Support tools where a screenshot of a student record ends up in a ticket.
- Email providers receiving student names and course titles.
- Machine learning vendors given records for training or tuning.
- Test and staging environments seeded with copies of real data.
Each is a disclosure to a third party. Whether it is permitted depends on the purpose and the agreement.
A practical review
- Draw the data flow for student identifiers from sign in to storage to every outbound call.
- List every subprocessor on that map.
- For each, write the purpose, the data fields sent, and the contract term that limits use.
- Remove or mask fields that are not needed for the purpose. Hash or drop student IDs in analytics events.
- Block real data from non production environments.
Contract and change control
Give schools notice before adding a subprocessor that receives student data. Keep the list on your site or in your trust materials. Review it quarterly. A new SDK added by a front end developer is the most common unreviewed change, so make dependency additions a reviewed event.
Safeguard's SBOM and dependency scanning and policy gates on pull requests can surface newly added packages so review happens before release. It does not inspect what data your runtime sends to third parties, so pair it with network and logging reviews.
Handling a request from a school
When a school asks where student data goes, answer from the data flow map, not from memory. Share the subprocessor list, the purpose for each and the fields sent. If you find a flow that was not on the map, say so, fix it and record the date. Schools generally respond better to a vendor that finds and fixes its own gap than to one that insists there are none. Keep the record of that exchange alongside the contract.
Quick check
Is anonymised analytics outside the rule?
Only if the data truly cannot identify a student. Names, addresses and identifiers are personally identifiable information per the Department's summary, so check what your events really contain.
Sources
Last reviewed: 19 October 2026.
