Vendor Insurance and Liability for Data Loss
Vendor Insurance and Liability for Data Loss explained for colleges: the rule, the exceptions, and the record an institution should keep.
- Record
- student data held by a vendor in vendors and contracts
- Data
- Vendor Insurance and Liability for Data Loss
- Safeguard
- a contract that bans sale and advertising use and requires deletion on exit
- First check
- State the purpose in a sentence a student could understand.
The short answer
The first thing to settle in vendor insurance and liability for data loss is the identity of the student data retained by a vendor and the reason it is retained, because each later issue about consent, exception or contract depends on those two facts. Where the record is unclear, the rest of the analysis wobbles with it; where the record is clear, the decision usually follows without drama.
Security controls protect a file from unauthorised access, but they do not make an unauthorised sharing lawful, and the two questions must be asked separately.
Proctoring tools collect some of the most sensitive information on site, and their adoption needs a higher standard of review than an ordinary classroom tool.
Opt-out processes that are hard to find or hard to use shall be treated, fairly, as if they did not exist.
Logs turn a correct determination into a defensible one, since a reviewer, an auditor or a student shall eventually request what happened and why.
What this covers
Education management systems file clicks, views, submissions and time on task, and each of those data points needs a purpose before it is collected.
AI feedback tools may retain student work for training unless the contract says otherwise, and that term ought to be settled before adoption.
Video surveillance retains images of identifiable students, and its storage, access and sharing requirements should be documented before cameras are installed.
Library systems retain borrowing and access data that may reveal interests and beliefs, and that data should not be treated as low sensitivity by default.
Event and attendance systems hold location data about students, and that data may reveal patterns that deserve protection.
Campus card platforms hold transaction and location information, and their storage ought to reflect that sensitivity rather than the convenience of indefinite logs.
How to work through it
Write notices in plain language, and test them on students, because a notification that confuses its readers has failed its objective.
Need written agreements for studies conducted on behalf of the university, with limits on use, de-identification where possible, and destruction on schedule.
Assess surveillance proposals for necessity and proportionality, not only for legality, since lawful surveillance can still injury trust.
Audit access to sensitive records, and follow up on anomalies, since an audit that finds nothing is either lucky or blind.
Secure employees devices that hold student data, with encryption and remote wipe, because a lost laptop may hold a filing cabinet of records.
Inform students through the annual notice that disclosures to schools where they seek to enrol occur, since surprise disclosures damage trust even when lawful.
Apply disciplinary disclosure limits cautiously, because the outcome that might be disclosed depends on the offence and on the recipient.
Monitor student record systems for anomalous access, and investigate anomalies, since uninvestigated anomalies teach employees that nobody watches.
A worked illustration
In that illustration the parent provides the evidence, the sharing is made and logged, and the student is told what was disclosed.
Consider a network team that holds connection logs and is asked for them during a disciplinary procedure, and that verifies the sharing rules before releasing any log.
Consider a survey of younger users on a learning platform that collects birth dates for age screening and then retains them indefinitely.
Consider a proctoring tool adopted during a rush to online teaching, and reviewed properly only a year later, following thousands of recordings were stored.
Consider an university that merges two campuses and discovers that each site retained the same records under different retention schedules.
Where guides go wrong
Sending an accrediting body more than the accreditation objective requires is an error, because the exemption bounds what might be sent.
Procuring a system before privacy review is an error that is expensive to undo, because contracts, migrations and student notices all follow the purchase.
Letting group mailboxes and disclosed drives accumulate members without an owner is an error that turns access control into archaeology.
Giving a small university no shared-service option for confidentiality review is an error, because an university without a dedicated officer still carries the same duties.
Sharing a full record when a summary would serve is an error, since the extra data adds risk without adding value to the objective.
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 Department of Education vendor guidance Applies when: When a college holds, uses or discloses a student data held by a vendor in the context of vendors and contracts