De-Identified Student Data Under FERPA: What the Rule Requires
Separating direct identifiers into a controlled system can be a useful security and data-minimization control. It isn't de-identification, and FERPA draws that line differently than most engineering teams expect.
Here's the failure mode. Your pipeline strips names, emails, and student IDs, then ships the rest to a model API. What remains is a grade level, a school, an ELL flag, a disability category, and an intact teacher narrative.
Under FERPA, that record may still contain PII. If so, providing it to an outside recipient is a FERPA disclosure and must be authorized by consent or a valid FERPA exception; whether it is permitted by a data-processing agreement is a separate contractual question.
Below: what the standard actually requires, why field-stripping fails it, and a four-question test to run before student data leaves your system. It sits beneath the PII vault control in our guide to EdTech compliance in 2026.
What counts as de-identified student data under FERPA?
Under § 99.31(b)(1), an educational agency or institution—or a party that received education-record information under FERPA—may release information without consent after removing all PII and making a reasonable determination that the student is not personally identifiable. FERPA sets this standard in 34 CFR § 99.31(b)(1). The regulation does not establish a fixed list of fields whose removal automatically proves de-identification.
The test has three core elements: remove all PII; make a reasonable determination that the student is not identifiable; and account for unique patterns across single or multiple releases and other reasonably available information.
That last clause means the release should be evaluated in context, including prior or concurrent releases and other information reasonably available to the relevant audience.
FERPA's definition of PII is wider than your schema
Section 99.3 includes a student's name; the names of family members; address; personal identifiers such as a Social Security number or student number; and biometric records. It also lists indirect identifiers such as date and place of birth and mother's maiden name.
Privacy researchers often describe attributes such as date of birth, location, and demographic characteristics as quasi-identifiers because they may become identifying when combined with other information. Some may not identify a student by themselves but may identify one when combined with other information.
Clause (f) is the catch-all. It reaches any other information, alone or in combination, that is linked or linkable to a student and would let a reasonable person in the school community, one who lacks personal knowledge of the circumstances, identify that student with reasonable certainty.
That qualifier decides real cases. The regulatory test is not limited to whether the student's own teacher could recognize the record. It asks whether a reasonable person in the school community, without personal knowledge of the relevant circumstances, could identify the student with reasonable certainty.
Paragraph (g) separately treats information as PII when it is requested by someone the educational agency or institution reasonably believes already knows the identity of the student to whom the record relates.
Teams familiar with HIPAA may expect a fixed identifier checklist, but HIPAA Safe Harbor and FERPA use different de-identification frameworks.
| Dimension | HIPAA Safe Harbor | FERPA § 99.31(b)(1) |
|---|---|---|
| Fixed list of identifiers | Yes. HIPAA's Safe Harbor method identifies 18 categories of identifiers that must be removed, subject to the regulation's requirements | None published |
| Method | Remove the listed categories | Removal of all FERPA PII plus a reasonable determination that the student is not identifiable, considering single or multiple releases and other reasonably available information |
| Prior releases count | No | Yes, single or multiple releases |
| Recipient matters | Via the "no actual knowledge" condition | Yes, explicitly (§ 99.3(g)) |
| Free-text narratives | Free-text fields are not a separate numbered Safe Harbor category, but they must be reviewed because they may contain identifiers or information that reasonably identifies an individual | Covered by the linkable standard |
Teams that borrow the HIPAA checklist for student records end up with a clean-looking artifact that satisfies the wrong law. FERPA asks a different context-specific question; whether it is 'harder' depends on the dataset, recipient, and release environment.
Why doesn't removing names de-identify student data?
Because information that appears non-identifying in isolation may become identifying when combined with other fields or external information. Researchers at Imperial College London and UCLouvain found that 15 demographic attributes would correctly re-identify 99.98% of Americans in any dataset (Rocher, Hendrickx and de Montjoye, Nature Communications 10:3069, 2019). A student record may contain many attributes, but the number of fields alone does not establish re-identification risk. Evaluate the attributes, their granularity, the population size, the recipient, and available outside information.
Free text can create substantial identification risk because it may describe distinctive events, relationships, locations, or circumstances that automated removal of names does not capture. IEP narratives, counselor notes, and teacher feedback describe circumstances no name-detection model can strip.
Picture a comment about the student who transferred in December after a family move. It names nobody, and in a small cohort it describes exactly one child.
Then there's the part teams read past. Section 99.31(b)(1) requires the determination to hold across single or multiple releases, so last quarter's export is part of this quarter's risk. The Department of Education's Privacy Technical Assistance Center adds that public directory information counts as reasonably available too (PTAC, Data De-identification: An Overview of Basic Terms).
The pressure to move fast is real. A 2025 Center for Democracy and Technology survey of 806 middle and high school teachers found 85% used AI during the 2024-25 school year, while only about one in five reported any instruction on AI risks like bias or overreliance (CDT, Hand in Hand). Student work is going into general-purpose tools with or without your pipeline.
The Linkability Test: four questions before student data leaves your system
The Linkability Test is an editorial framework based on FERPA's use of the terms 'linked or linkable.' It is not a test prescribed by the regulation.
It turns the regulatory standard into four operational questions to ask before a record crosses a system boundary. Answer them in code review, not in a policy document.
- Who receives it, and what do they already hold? A model vendor with no roster context may present a different re-identification risk from a district analytics partner that already holds enrollment data. The recipient's reasonably available information and existing knowledge must be considered. Under § 99.3(g), the recipient's existing knowledge is part of the test.
- What survives redaction in the free text? Run your redaction pass, then read ten real narrative fields end to end. If the remaining information would allow a reasonable person in the school community, without personal knowledge of the relevant circumstances, to identify the student with reasonable certainty, removing names and obvious entities was not sufficient.
- What does this combine with, including what you already shipped? Evaluate combinations across releases, not columns in isolation. Grade, school, disability category, and enrollment date may become identifying in a small school or cohort. Test that combination against the actual population and information reasonably available to the recipient rather than assuming it is unique in most buildings.
- If the determination fails, is the transfer still authorized? De-identified data falls outside FERPA's consent rules, so teams treat it as unrestricted. When the determination does not hold, the transfer remains a disclosure of PII and must be supported by consent or a valid FERPA exception. A DPA may help document the relationship and permitted purpose, but it does not independently authorize a FERPA disclosure.
Question two is the five-minute version of this whole article. Most teams have never read their own redacted output.
At least two of these questions require architectural controls, including data-flow mapping, release tracking, access controls, and review of free-text exports. Your retrieval layer and export paths have to know what they're handing over, which is the design work behind the PII vault pattern and the code-level controls that enforce it.
Building an AI feature that touches student records?
Talk to our team about a trust boundary review before it reaches district procurement.
Request a Trust Boundary Review →Which fields actually leak identity?
Direct identifiers are usually easier to locate, but removing them does not resolve indirect or contextual identification risk. The fields below may remain identifying after direct-identifier redaction, depending on their granularity, combination, population size, recipient, and available outside information.
| Field | Why it links | Control |
|---|---|---|
| Free-text narratives (IEP, counselor, feedback) | May describe distinctive circumstances, relationships, locations, or events without using a name | Keep inside the trust boundary; never export raw |
| Disability or ELL category | May create identification risk when categories are uncommon or combined with school, grade, cohort, or dates | Consider cell suppression or broader aggregation for small groups, but select thresholds based on the release context and evaluate differencing or repeated-release risks |
| Enrollment or withdrawal date | May identify a student when the event is distinctive or can be matched with public or recipient-held information | Generalize to term or semester |
| Date of birth | Named as an indirect identifier in § 99.3 | Generalize to birth year or age band |
| School plus grade plus cohort | May be unique in a particular school or cohort; test the combination against the actual population | Generalize to district or grade band |
| Record codes linking releases | Can enable linkage across releases and therefore require controls on generation, disclosure, permitted use, and access | Follow § 99.31(b)(2): never derive from personal data |
That last row has its own rule. Section 99.31(b)(2) permits a code that lets a researcher match records from one source, but it can't be derived from a Social Security number or other personal information, and you can't disclose how it's generated.
Small-cell suppression is the control most teams skip. A result involving three students may carry substantial identification risk, particularly in a small population or when combined with other information. Suppression is not automatic proof of de-identification, and no universal three-person threshold applies under FERPA.
Frequently asked questions
Properly de-identified information may be released without the consent otherwise required by FERPA under § 99.31(b)(1). The exemption depends on satisfying the regulation's standard; labeling data 'anonymous' or removing names alone is not enough. Other laws, contracts, and institutional policies may still apply.
Only if the record genuinely meets § 99.31(b)(1), which student work rarely does. Essays and narrative responses carry writing style, personal circumstances, and specific detail that survive entity redaction. In practice, route this data through a controlled retrieval layer governed by your DPA instead.
No automatic safe harbor. K-anonymity may be one disclosure-limitation technique, but FERPA still requires a reasonable determination for the specific release. PTAC describes de-identification and disclosure-avoidance methods as risk-reduction approaches; the institution must still evaluate whether the resulting data remains identifiable in the specific release context.
Either the school or you. Section 99.31(b)(1) lets an educational agency or institution, or a party that received education records under Part 99, make the determination. If you de-identify data obtained through the School Official Exception, your process carries that judgment, so your DPA should say who makes it.
De-identification is a determination, not a delete statement
FERPA provides a context-specific standard rather than a fixed identifier checklist, so a redaction script alone cannot establish de-identification. The determination should consider the remaining information, the recipient's reasonably available information, prior or multiple releases, and other reasonably available information, including information that may be publicly accessible.
Treat de-identification as field-stripping and the risk moves downstream into your model pipelines and exports. Treat it as a boundary decision and you build the suppression, generalization, and release-tracking controls that hold up when a district asks how you made the call.
That work belongs in the data layer, alongside the compliance-ready architecture district procurement now tests against.
Ready to find out what your platform is actually exporting?
Get in touch for an architecture assessment that maps your student data flows against FERPA's de-identification standard.
Get an Architecture Assessment →- eCFR — 34 CFR § 99.31(b), De-identified records and information
- eCFR — 34 CFR § 99.3, Definitions
- US Department of Education, PTAC — Data De-identification: An Overview of Basic Terms
- Rocher, Hendrickx & de Montjoye — Estimating the success of re-identifications in incomplete datasets using generative models, Nature Communications 10:3069 (2019)
- HHS Office for Civil Rights — Methods for De-identification of PHI, 45 CFR § 164.514(b)
- Center for Democracy and Technology — Hand in Hand: Schools' Embrace of AI Connected to Increased Risks to Students (2025)
