Network Segmentation for Student Systems
A plain-language guide to network segmentation for student systems: the record, the purpose, the authority and the safeguard.
- Record
- student record system in security controls for student data
- Data
- Network Segmentation for Student Systems
- Safeguard
- least-privilege access, encryption and access logging
- First check
- Name the record and its holder before any use or disclosure.
The short answer
In short, network segmentation for student platforms turns on one question: which student record system is involved, who holds it, and what objective justifies the next step with it. Get those three answers right and most of the rest of the decision follows; miss any one of them and the rule applied will be the wrong rule for the facts in front of you.
Students retain rights over their records even when they never exercise them, and a college's duty does not depend on a student asking about it.
Copies of files given to students should be full enough to be useful, and redactions of third-party information should be explained.
Security baselines for new systems ought to be set before launch, because retrofitting safeguards after adoption rarely restores the data already disclosed.
Where two rules point in different directions, the stricter applicable requirement usually governs, and the conflict itself ought to be escalated rather than resolved quietly at a desk.
What this covers
Admissions information involves applicants who may never enrol, and their records deserve protection even though they never become students in the usual sense.
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.
Event and attendance platforms retain location information about students, and that information may reveal patterns that deserve safeguarding.
Alumni directories raise the same designation issue, because former students retain an interest in how their information is published.
Name, enrolment status and field of study are commonly designated, while grades, disciplinary outcomes and financial facts are not directory information.
Publishing a directory notice in a handbook nobody reads is weaker than publishing it where students actually encounter it at enrolment.
How to work through it
Review third-party access regularly, and remove access that is no longer needed, rather than leaving it in place for convenience.
Set security baselines before a new platform launches, since retrofitting controls after adoption rarely restores information already disclosed.
Safeguard applicant records on a specified schedule, even though applicants never become students in the usual sense.
Need a court order or subpoena process for compelled releases, and do not disclose on the strength of a letter alone.
Answer complaints regarding access in writing, with reasons, because an unexplained refusal cannot be challenged or learned from.
Encrypt employees devices, enable remote wipe, and test both, since an untested control is a hope, not a control.
Contain return of records in vendor contracts, in an usable format, because a record returned in an unusable form is not truly returned.
Assess new systems before purchase, with privacy review as a gate, not as a comment added following the contract is signed.
A worked illustration
In that illustration the parent provides the evidence, the sharing is made and logged, and the student is told what was shared.
Consider a learning app for younger students that tracks behavior across sessions and shares aggregates with a third party, without a privacy review.
In that illustration the records are removed from the broad platform, the affected students are told, and the integration is fixed so it can not happen again.
The contract in that illustration names the data, limits use to the institution's objectives, bans advertising use, and sets deletion ninety days after the contract ends.
In that illustration the instructor shares the summary, the colleague's advice improves, and no record leaves the instructor's office.
Where guides go wrong
Disclosing a disciplinary outcome beyond the limits for that offence and recipient is an error that may injury a student long after the procedure ends.
Assuming an integration passes only the information shown on a diagram is a mistake, since integrations routinely pass more than intended.
Assuming cloud hosting moves responsibility is an error, since the university remains answerable for a record another company stores.
Redisclosing a file received under an exemption, without checking whether the second sharing is covered, is an error that spreads the original sharing.
Auditing disclosures without verifying the log is an error, since a disclosure missing from the log is a finding, not a clerical gap.
Sources and evidence on the record
- Family Educational Rights and Privacy Act regulations, 34 CFR Part 99, text on eCFR.
- National Institute of Standards and Technology, Computer Security Resource Center - control guidance used here as method, not as law.
- US Department of Education, Student Privacy Policy Office, studentprivacy.ed.gov - FERPA guidance, FAQs and model notices.
Evidence basis: 34 CFR Part 99 and NIST control guidance used as method Applies when: When a college holds, uses or discloses a student record system in the context of security controls for student data