StudentPrivacy.college
The Privacy Ledger - protect and govern student data

Research Consent Beyond FERPA Exceptions

Research Consent Beyond FERPA Exceptions: what it means for a research dataset, who may use it, and the check to make before it moves.

Privacy check
Record
research dataset in research data and secondary use
Data
Research Consent Beyond FERPA Exceptions
Safeguard
consent or a lawful exception, plus de-identification checked for small cohorts
First check
Confirm consent, a named exception, or a contract term before sharing.

The short answer

Put simply, research consent beyond ferpa exceptions is regarding control over a research dataset that belongs, in a practical sense, to a student and is held in trust by an institution. The institution may use it for the purpose it was collected for, share it where the law or a valid consent allows, and must protect it everywhere else. Everything in this guide is a way of making that sentence workable at a desk, stage by stage.

Readiness for a regulator inquiry is built in ordinary weeks, through inventories and logs, not in the week the inquiry arrives.

Parental permission for younger users must be verifiable, and a checkbox that anyone may tick does not meet that standard.

A contract with a vendor may authorise processing on the college's behalf, but it may not authorise uses the college itself could not authorise.

Directory information is the one category where a published designation can alter the answer, and only where the designation and the opt-out were done properly.

What this covers

Wi-Fi monitoring may reconstruct a student's movements across campus, and that capability should be governed before it is used, not following it is discovered.

Mobile applications for student services can collect location, contacts or device data beyond the service itself, and that collection needs its own review.

Employment files for student employees sit in a distinct category, and the distinction matters when a record is requested.

Accrediting bodies receive information under a specific exception, and the scope of that exception ought to bound what is really sent.

LGBTQ students can be harmed by directory releases that reveal identity or associations, and opt-out processes should be easy to find and use.

Single sign-on produces an identity file of its own, including authentication events that may reveal patterns of student activity.

How to work through it

Test vendor information flows in a staging environment where possible, because production testing risks the very records being protected.

Build opt-out into information feeds, so that an opt-out exercised in one system propagates to each system that publishes the information.

Use role-based access as the default, and treat any exemption to it as a decision that needs its own justification.

Review disclosed folders periodically, and treat disclosed-folder review as a confidentiality task with an owner, not as housekeeping.

Monitor student record systems for anomalous access, and investigate anomalies, because uninvestigated anomalies teach employees that nobody watches.

Include return of files in vendor contracts, in an usable format, because a record returned in an unusable form is not truly returned.

Assess new platforms before purchase, with confidentiality review as a gate, not as a comment added following the contract is signed.

Explain redactions in access responses, because an unexplained gap teaches a student that records are edited at will.

A worked illustration

Consider a counselling service that keeps notes in a personal file and is asked whether those notes are education records, and that verifies the exception before answering.

Consider a site police unit that creates a law enforcement record and is asked to disclose it with the dean's office, and that checks the objective of the sharing first.

Consider an alumni department that wants to publish a class directory and that verifies opt-outs and designations for former students before publishing.

Consider a student who asks for a record that has previously been lawfully disclosed to another office, and who is told where it went and why.

Consider an instructor who wants a second opinion from a colleague about support for a student, and who first checks whether a summary without identifiers would serve.

Where guides go wrong

Procuring a platform before confidentiality review is a mistake that is expensive to undo, because contracts, migrations and student notifications all follow the purchase.

Responding to an access request slowly, or in an unusable format, is an error, since delay turns a right into a frustration.

Including a diagnosis in an accommodation letter, when a lecturer only needs to know the accommodation, is an error that discloses more than the purpose requires.

Giving a small college no disclosed-service option for privacy review is an error, because a college without a dedicated officer still carries the same duties.

Excluding students from privacy governance is a mistake, because students notification problems that staff have normalised.

Sources and evidence on the record

  • Family Educational Rights and Privacy Act regulations, 34 CFR Part 99, text on eCFR.
  • US Department of Education, Student Privacy Policy Office, studentprivacy.ed.gov - FERPA guidance, FAQs and model notices.
  • US Department of Education, ed.gov - guidance, Dear Colleague letters and enforcement information.

Evidence basis: 34 CFR Part 99 research provisions and review board practice Applies when: When a college holds, uses or discloses a research dataset in the context of research data and secondary use

Next on the ledger