FERPA-compliant platforms for sharing student behavioral health information

Districts procuring a platform that will touch student behavioral-health information have a regulatory surface most edtech vendors have never seriously engaged with. The Family Educational Rights and Privacy Act (FERPA) is specific, not a vibe, and the requirements it places on a school’s contractual relationship with a vendor are enforceable under 34 CFR Part 99.

This article gives a district-level team a working model of FERPA, walks through the “school official with legitimate educational interest” exception that governs most vendor relationships, maps the HIPAA/FERPA interaction for behavioral-health platforms, and ends with a 10-question procurement checklist.

FERPA §99 in practice — a cheat sheet

FERPA is codified at 20 U.S.C. §1232g and implemented at 34 CFR Part 99.[1][2] Five working facts matter for a district procurement team.

• Parental access. Parents of students under 18 (and students 18+ themselves, referred to as “eligible students”) have the right to inspect and review the education record.
• Consent for disclosure. The default rule is that an educational record may not be disclosed to third parties without written parent or eligible-student consent.
• School-official exception. A recipient that qualifies as a “school official with a legitimate educational interest” can receive records without separate consent, under specific conditions.
• Directory vs. non-directory information. A district may designate certain limited, non-sensitive information as “directory information” and disclose it without consent, subject to annual notice and opt-out rights. Behavioral-health information is never directory information.
• Annual notification. Districts must annually notify parents and eligible students of their FERPA rights.

The school-official exception — what a vendor has to be

The school-official exception at 34 CFR 99.31(a)(1) is the mechanism by which districts legitimately share student-level information with cloud vendors without obtaining separate consent for each record. The exception is not automatic. To qualify, a vendor must:

• Perform a service or function for which the district would otherwise use its own employees.
• Be under the direct control of the district with respect to the use and maintenance of the education records.
• Be subject to the FERPA requirements governing the use and redisclosure of personally identifiable information from education records, in §99.33(a).

In practice, this means a written agreement between the district and the vendor that names the vendor a school official, defines the legitimate educational interest being served, prohibits redisclosure and unauthorized use, and gives the district the right to audit. A vendor that cannot sign that agreement is not operating under the exception.

When FERPA and HIPAA intersect

Behavioral-health platforms sit at a jurisdictional seam. A record maintained by a school nurse in the course of providing a service required by a 504 plan or an IEP is generally an education record under FERPA, not a HIPAA protected health information record. A record maintained by a pediatric hospital is generally PHI under HIPAA. A platform that operates across both surfaces has to represent the boundary explicitly.

The US Department of Education and HHS have issued joint guidance describing this boundary in detail, and a district lawyer reviewing a vendor contract for a behavioral-health platform should expect the vendor to know it.[3] The failure mode to watch for is a vendor that treats all behavioral-health data as PHI or all of it as education record — either is wrong at the boundary.

A concrete implication: a parent’s HIPAA authorization for a hospital to release records to a school nurse does not automatically grant the school nurse the authority to put those records into the student’s education record. The nurse’s own note about the student, written at school, is a different record. Good platforms represent those two records distinctly.

What to look for in a platform

Five concrete asks for a procurement conversation.

Written school-official agreement

The vendor should offer a standard data-sharing agreement that names them a school official, defines the legitimate educational interest, restricts redisclosure, and grants audit rights. If the vendor’s standard terms of service are a clickwrap that does not mention FERPA, keep looking.

Parent-consent capture and revocation

Where the platform enables sharing with a third party outside the school-official umbrella — for example, sharing behavioral records with a treating clinician or with a parent’s chosen advocate — it must capture explicit, granular parent consent and must make revocation straightforward. A consent that can be given but not revoked is not really a consent.

Audit trail

Every read, write, and export of a student’s record must be logged with user identity and timestamp. The district should be able to pull that log at any time, not on the vendor’s schedule.

Data residency and subprocessors

The platform should be transparent about where student data is stored and which third-party services process it. Student data stored outside the United States is rarely a fit for US district procurement; subprocessors should be named and contractually bound to the same restrictions.

No ad-tech on protected surfaces

The platform should run no third-party advertising, cross-site tracking, or surveillance advertising scripts on surfaces where student-level data is displayed. Many states now have specific student-privacy laws that go further than FERPA on this point (California’s SOPIPA being the earliest well-known example); a platform that does not meet that bar is not a serious fit.[5]

What breaks FERPA compliance

Four failure modes come up repeatedly in procurement reviews.

• CC’ing a vendor email address (support@, help@) with identifiable student information and relying on the vendor’s informal handling.
• Shared spreadsheets — often Google Sheets — that spread across staff and contain identifiable behavioral information without the access governance the district’s SIS has.
• Unaudited exports. The moment a record leaves the platform as a CSV a staff member downloaded, the audit chain is broken unless the district has a separate DLP solution.
• Ad-tech trackers on protected surfaces. The risk is both FERPA and state-law exposure, and the trackers typically sit on marketing pages that, for a behavioral-health platform, are adjacent to the login page.

How NeuroPath handles the school side

NeuroPath operates as a school official under written data-sharing agreement, with a standard template that names the platform a school official with a legitimate educational interest defined by the district’s stated use case. The template prohibits redisclosure, restricts use to the defined purpose, grants the district audit rights, and names subprocessors.

• Parent-consent-gated cross-organization sharing. A family can choose to share specific records with a treating clinician, an advocate, or another district, and can revoke that share at any time. The sharing is audit-logged.
• Audit trail on every read, write, and export, exportable by the district on demand.
• US data residency. Student data is stored in US regions on Google Cloud; our subprocessor list is published.
• No third-party advertising or cross-site tracking on protected surfaces. Marketing analytics, where present, are privacy-respecting and do not run on student-facing surfaces.

Procurement checklist — 10 questions for districts

1. Will you sign our district’s standard data-sharing agreement (or offer one that names you a school official with a legitimate educational interest)?
2. Where is student data stored geographically?
3. Who are your subprocessors, and are they contractually bound to the same restrictions?
4. Do you run any third-party advertising, marketing retargeting, or cross-site tracking on surfaces where student data is accessible?
5. How does a parent grant and revoke consent for sharing outside the school-official umbrella?
6. Can the district pull an audit log of all access to a specific student’s record on demand?
7. What happens to student data when the contract ends — return, destruction, timeline, certification?
8. How do you represent the boundary between an education record (FERPA) and a clinical record (HIPAA) in your system?
9. What state student-privacy laws do you contractually commit to (e.g., SOPIPA, state-specific COPPA analogs)?
10. In the event of a data incident, what is your notification timeline and channel?