Single Sign-On and Student Identity Data

Put simply, single sign-on and student identity data is regarding control over a student file in the cloud that belongs, in a practical sense, to a student and is retained in trust by an institution. The institution might use it for the purpose 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.

Annual notifications are not a formality: they are the moment students learn what directory information means and how to opt out.

Mixed-audience platforms need a child-directed analysis for their younger users, not a single policy written for adults.

Parental access after rights transfer depends on dependency status and on the institution's own policy, not on a parent's request alone.

Alumni records do not lose protection at graduation, and the requirements for former students deserve the same care as for current ones.

Photographs and video become education records when they are maintained as part of a student's file, and a casual photo is not automatically in that category.

Network logs hold connection information that can reveal student activity patterns, and access to those logs ought to be logged in turn.

Survey platforms hold responses that can be sensitive, and the survey design should settle anonymity, storage and reporting before distribution.

Shared drives accumulate copies that outlive their objective, and periodic review of shared folders is a confidentiality task, not housekeeping.

An education file is defined by how it is maintained and whom it is about, not by the folder it sits in or the platform that retains it.

An opt-out, once exercised, must be honoured across systems, including directories, publications and data feeds that were built before the opt-out arrived.

Include students in governance, since students notification privacy problems that staff have normalised.

Start every decision by naming the record in plain terms, since a decision about an unnamed record is a decision about nothing in particular.

Run internal audits on a specified 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 information is personal.

Limit audit and evaluation disclosures to the audit purpose, and bind the receiver to that purpose in writing.

Put vendor terms in the contract, not in a sales deck, and check that the contract names the information, limits its use and needs deletion on exit.

Honour removal rights for children's data promptly, and make removal reach backups and subprocessors on a specified timetable.

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

Consider an education analytics project that begins with an issue regarding storage and ends with a dashboard that nobody may explain to a student.

Consider a site that installs cameras in a residence hall entrance and writes storage, access and disclosure requirements before the cameras are switched on.

Consider a vendor that suffers an incident affecting student records, and an institution whose contract required notification within three days.

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

The cost of fixing the badly done adoption, in renegotiation, migration and lost trust, is far higher than the cost of the review that was skipped.

Writing a policy that employees can not state without opening the document is a mistake, since the policy will not be followed under time pressure.

Sharing a full record when a summary would serve is a mistake, since the extra data adds risk without adding value to the purpose.

This guide does not interpret the law for a particular college, and readers ought to escalate cases it cannot settle rather than treating its structure as a determination.

A second common error is relying on a consent that was never specific, never explained, or obtained after the disclosure it was meant to authorise.

Collecting disability data via assistive technology without reviewing the vendor is an error, because usage data can reveal disability.