Litigation Holds and the Retention Schedule
A plain-language guide to litigation holds and the retention schedule: the record, the purpose, the authority and the safeguard.
- Record
- retained student record in data retention and minimisation
- Data
- Litigation Holds and the Retention Schedule
- Safeguard
- a published schedule and deletion on schedule, not on request alone
- First check
- Check that the recipient is bound to use the data only as agreed.
The short answer
Put merely, litigation holds and the retention schedule is regarding control over a retained student file that belongs, in a practical sense, to a student and is held in trust by an university. The university may use it for the objective it was collected for, disclose it where the law or a valid permission permits, and must safeguard it everywhere else. Everything in this guide is a way of making that sentence workable at a desk, stage by stage.
Complaints regarding denied access deserve a written answer, because an unexplained refusal teaches a student that rights are discretionary.
Parental permission for younger users must be verifiable, and a checkbox that anyone may tick does not meet that standard.
Objective limitation is the thread through the whole subject: data collected for teaching ought not to drift into marketing, product development or unrelated research without fresh authorization.
The safest test for any proposed sharing is to write it down in one sentence naming the file, the receiver, the objective and the authorization, and then to read that sentence back critically.
What this covers
Research systems hold datasets that may be de-identified in name but identifiable in combination, especially in small programmes.
Third-party tools connected to an education platform can receive more data than the integration was meant to pass, and the actual data flow ought to be tested, not assumed.
Students who are additionally employees have records in both capacities, and the capacity in which a record was created matters to its treatment.
Event and attendance platforms retain location data regarding students, and that data may reveal patterns that deserve safeguarding.
Public files requests can reach student information, and employees handling them need to know which files are safeguarded before responding.
Platforms that feed directory information to outside directories need an opt-out check built into the feed, not added as a manual afterthought.
How to work through it
Analyse marketing uses of student data for permission even when the marketing feels routine, since routine is not authority.
Refuse parental access for independent students politely and in writing, with the reason stated, because an unexplained refusal invites repeated requests.
Analyse outside survey requests separately from institutional surveys, since the authority for one does not cover the other.
Respond to student access requests promptly and in an usable format, since delay turns a right into a frustration.
Build opt-out into information feeds, so that an opt-out exercised in one platform propagates to each platform that publishes the information.
Identify the authority before the information moves, not after, because retrospective authority is usually no authority at all.
Audit surveillance systems for access, retention and sharing, because cameras generate files continuously, even when nobody watches.
Establish dependency before disclosing to parents of a student, and do not assume it from a family relationship or a disclosed surname.
A worked illustration
In that illustration the logs are released solely to the extent the process requires, with redactions for students not involved.
Consider a student organisation that collects member information in a disclosed spreadsheet and discovers, during a review, that the sheet is apparent to the whole campus.
The contract in that illustration names the information, limits use to the university's objectives, bans advertising use, and sets deletion ninety days after the contract ends.
Consider a student who requests to see an advising note that contains a factual error, and who receives the note, the correction procedure and a documented decision.
In that illustration the university must retrofit an alternative under pressure, and the students affected have previously lost trust in the process.
Where guides go wrong
Including a diagnosis in an accommodation letter, when an instructor only needs to know the accommodation, is an error that discloses more than the objective needs.
Treating aggregates as anonymous when the underlying data remains identifiable is an error, since re-identification risk does not vanish at the dashboard.
Permitting monitoring in learning applications for younger students to go unreviewed is an error, because behavioral data grows quietly over a school year.
Delaying deletion of children's data following a deletion request is a mistake, since the data continues to be used while the request waits.
Conversely, a lawful disclosure may still be handled carelessly, in an unencrypted attachment or an open distribution list, and the harm is the same.
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.
- National Institute of Standards and Technology, Computer Security Resource Center - control guidance used here as method, not as law.
Evidence basis: 34 CFR Part 99 and institutional retention practice Applies when: When a college holds, uses or discloses a retained student record in the context of data retention and minimisation