Privacy by Design for New College Systems

For privacy by design for new university systems, think in terms of a chain: a student, an institutional data practice, an objective, an authority, a receiver, a safeguard and a retention date. Break any link and the disclosing fails, even if each other link is sound. This guide walks that chain link by link, so the reader may see exactly where a proposed disclosing retains and where it breaks.

Copies of files given to students should be full enough to be useful, and redactions of third-party information should be explained.

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

Amendment is not the same as removal: a successful challenge corrects or explains a record, and the original entry often remains in the file with the challenge noted.

Access rights matter because errors in files have consequences, and a student who cannot see a record cannot challenge it.

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

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

Disciplinary releases to victims and others have specific limits, and the outcome that may be shared depends on the offence and the receiver.

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

Cloud systems do not alter what counts as a record, but they alter where copies live, and every copy needs the same governance as the original.

Parents of independent students do not acquire access by asking, however strongly they feel the request is justified.

Test phishing resilience for staff who handle files, since social engineering targets people, not firewalls.

Read exceptions narrowly and on their own terms, and do not stretch an exemption to cover a purpose that merely resembles the named one.

Encrypt staff devices, enable remote wipe, and test both, because an untested control is a hope, not a control.

Delete on schedule, and make removal verifiable, since a removal that cannot be shown is a removal that will be doubted.

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

Review assistive technology vendors for the usage information they collect, since that information may reveal disability.

Write notifications in plain language, and test them on students, because a notification that confuses its readers has failed its purpose.

Inform students through the yearly notification that releases to schools where they seek to enrol occur, because surprise releases damage trust even when lawful.

Consider a network team that holds connection logs and is asked for them during a disciplinary procedure, and that verifies the disclosure requirements before releasing any log.

Consider the same incident without a notification term: the institution learns regarding it weeks later from a press report, and students learn regarding it at the same time.

In that illustration the officer verifies the disciplinary disclosure limits, confirms what may be disclosed, and provides the media a written, limited answer.

In that illustration the older logs are deleted, the new period is published, and future logs expire automatically.

Consider an university that adopts the same platform without an alternative, and that discovers too late that some students can not or will not enrol.

Keeping applicant records indefinitely is an error, because applicants who never enrol still have records that deserve a stated schedule.

Auditing releases without checking the log is a mistake, because a sharing missing from the log is a finding, not a clerical gap.

Writing a notice that no student can find, or that no student can understand, is a mistake that undermines each later reliance on that notice.

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

Accepting a checkbox as verifiable parental permission is an error, because a checkbox that anyone may tick verifies nothing.