Portal Downtime and Record Availability
A plain-language guide to portal downtime and record availability: the record, the purpose, the authority and the safeguard.
- Record
- student record in the cloud in cloud systems and student portals
- Data
- Portal Downtime and Record Availability
- Safeguard
- access controls, logging and a contract that follows the record
- First check
- Check that the recipient is bound to use the data only as agreed.
The short answer
Put merely, portal downtime and record availability is regarding control over a student record in the cloud that belongs, in a practical sense, to a student and is held in trust by a college. The college might use it for the objective it was collected for, share 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.
A notification that no student can find, or that no student can understand, does not do the work of permission or of a directory designation.
Biometric data can not be reissued like a password, so a biometric breach has consequences that outlast any single incident response.
Marketing uses of student information need consent analysis even when the marketing feels routine or beneficial.
Research uses of education records need their own authorization analysis, and a research exception is narrower than researchers sometimes assume.
What this covers
Accessibility data in an education platform can reveal disability status, and access to it should be limited to employees who need it for support.
Shared drives accumulate copies that outlive their objective, and periodic review of shared folders is a confidentiality task, not housekeeping.
LGBTQ students can be harmed by directory releases that reveal identity or associations, and opt-out procedures should be easy to find and use.
Advising systems retain some of the most sensitive narrative data on site, since advisers file context that grades alone never show.
Housing platforms retain residence and roommate data, and sharing of residence information needs particular care for student safety.
Discussion posts in a course system are maintained about identifiable students, and their retention should follow the course file schedule.
How to work through it
Retain applicant records on a specified schedule, and delete them when that schedule expires, rather than keeping them indefinitely.
Run internal audits on a stated cycle, and track findings to closure with owners and dates.
Audit vendor adherence, and do not accept a vendor's self-assessment as a substitute for evidence where the data is sensitive.
Honour removal rights for children's data promptly, and make removal reach backups and subprocessors on a specified timetable.
Patch systems on a specified timetable, and prioritise patches for systems holding identifiable student data.
Separate health and counseling systems from broad student systems, with access limited to the employees who provide the care.
Prepare documentation a regulator would request for, and keep it in one place, since scattered documentation reads as no documentation.
State the purpose in a sentence a student could understand, and if the sentence can not be written plainly, the purpose is probably too broad.
A worked illustration
The contract in that illustration names the data, limits use to the college's objectives, bans advertising use, and sets deletion ninety days after the contract ends.
Consider a labeled illustration: a mid-sized college adopts a new advising platform and maps which fields it shall hold before signing anything.
Consider a student who requests for a record that has already been lawfully disclosed to another department, and who is told where it went and why.
In that illustration the institution must retrofit an alternative under pressure, and the students affected have previously lost trust in the procedure.
Consider an alumni office that wants to publish a class directory and that verifies opt-outs and designations for former students before publishing.
Where guides go wrong
Retaining backups beyond the deletion schedule is a mistake that undoes an otherwise correct deletion determination.
Leaving access in place following a role alter is an error that compounds silently, because the former access looks legitimate in each log.
This guide does not interpret the law for a specific university, and readers ought to escalate cases it can not settle rather than treating its structure as a determination.
Its value is in the structure it teaches: name the file, state the purpose, settle the authorization, limit the sharing, protect the information, and keep the file.
Forgetting that a studies agreement must limit use and need destruction is an error that leaves research information in circulation after the study ends.
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 guidance Applies when: When a college holds, uses or discloses a student record in the cloud in the context of cloud systems and student portals