FERPA and Third-Party Testing Tools: What School Administrators Need to Know

Most conversations about FERPA focus on the obvious stuff: don't post grades publicly, don't share records with unauthorized parties, give parents access when they ask. That's the easy part.

The part that catches administrators off guard is what happens when a school uses a third-party tool that touches student records. Assessment coordination software. Attendance tracking apps. Any platform where you're uploading a roster and expecting the tool to do something with it.

If that tool has student names, grade levels, and accommodations in it, you're dealing with education records under FERPA. And the law has specific things to say about that.

What FERPA Actually Covers

The Family Educational Rights and Privacy Act (20 U.S.C. § 1232g) protects personally identifiable information from students' education records. That includes the obvious things like grades and transcripts, but also broader categories: name, address, student ID, and any information that could be used to identify a student.

A testing roster with student names, grade levels, and accommodation flags is an education record. When you upload that to a vendor's system, you're disclosing education records to a third party.

That's not automatically a problem. FERPA has a mechanism for exactly this situation. But it requires that the vendor actually qualifies under that mechanism, and most schools don't verify this before signing up.

The School Official Exception

FERPA allows schools to disclose education records to outside parties without prior parental consent when those parties qualify as "school officials." To qualify, a vendor has to meet three conditions:

1. The vendor performs a function for which the school would otherwise use its own employees
2. The vendor is under the school's direct control with respect to how education records are used
3. The vendor is subject to FERPA requirements for use and re-disclosure of the data

An assessment coordination tool that manages testing logistics, handles roster data on behalf of the school, and operates only under the school's direction fits this definition. But the vendor has to actually commit to operating this way in writing, and the school has to maintain meaningful control over how the data is used.

What Schools Get Wrong

A few patterns show up repeatedly when schools run into FERPA problems with third-party tools.

Assuming a signed contract is enough

A vendor contract that doesn't address FERPA specifically doesn't make the relationship compliant. The contract needs to establish the vendor's role as a school official, define how data will be used, and specify what happens to student records when the relationship ends. A general software license agreement doesn't do any of this.

Not telling parents

FERPA requires schools to notify parents annually of the categories of school officials who have access to education records. If your assessment coordination vendor qualifies as a school official, they should be included in that notification. Most schools don't update their annual FERPA notice when they add new vendors.

Not verifying data deletion

When a school stops using a vendor, what happens to the student records in that system? The answer should be: they get deleted, and the vendor should be able to confirm this in writing. A lot of vendor agreements are vague about retention, which creates ongoing exposure.

Using tools not designed for student data

A generic event management tool or a shared Google Sheet with student roster data is not FERPA compliant by default. FERPA compliance is a feature that has to be designed in, not assumed. The controls, the access restrictions, the audit trail, the deletion procedures all have to be intentional.

What to Ask a Vendor Before You Share Student Data

Before uploading any student roster to a third-party system, a school administrator should be able to answer all of the following:

• Does the vendor acknowledge operating as a school official under FERPA?
  This has to be explicit, not implied. If the vendor doesn't know what this means, that's your answer.
• Is student data used only for the purpose the school authorized?
  The vendor should not be using your roster data for product analytics, model training, or anything else without your written consent.
• Who within the vendor's organization has access to student records?
  Access should be limited to the minimum number of people necessary. You should be able to get a straight answer about this.
• Is there complete data isolation between districts?
  If you're on a shared platform, your students' records should be inaccessible to other customers. This needs to be enforced at the application layer, not just by policy.
• What is the data retention and deletion policy?
  You need to know how long student records are retained and what the process is for deletion. "We delete it eventually" is not an acceptable answer.
• Does the vendor maintain an audit trail of data access and changes?
  FERPA requires schools to keep records of who accessed education records and for what purpose. If the vendor can't provide this, the school has no way to fulfill that obligation.
• What happens in the event of a data breach?
  The vendor should have a documented breach notification procedure with specific timelines. Not every state has the same requirements, but 72 hours is a reasonable baseline to expect.

The Audit Trail Requirement Is Often Overlooked

FERPA requires schools to maintain records of disclosures of student education records. That includes internal disclosures. When a staff member accesses a student's record, when a roster is updated, when a proctor checks a student in on test day, those are all events that touch education records.

A vendor that logs these events at the field level gives a school something to point to if a parent ever challenges the accuracy of a record or asks who accessed their child's information. A vendor that doesn't log them leaves the school without that protection.

This is one of the areas where generic tools consistently fall short. An event management platform might log that a file was uploaded. It won't tell you that a specific field was changed from one value to another, by whom, and at what time. That level of specificity matters for compliance.

Your School Is Still the Data Controller

Even when a vendor qualifies as a school official under FERPA, the school retains ownership and control of student education records. The vendor is a processor. If a parent asks to inspect their child's records, the school is responsible for fulfilling that request, not the vendor. If a record needs to be corrected, the school initiates that process.

This is worth being explicit about in any vendor agreement. The relationship should be structured so there's no ambiguity about who owns the data, who controls how it's used, and who is responsible for responding to parent requests.

Schools that treat this as the vendor's problem rather than their own tend to be the ones that end up in difficult situations.