Cloud Vendor Lock-In and Record Portability
A plain-language guide to cloud vendor lock-in and record portability: the record, the purpose, the authority and the safeguard.
- Record
- student record in the cloud in cloud systems and student portals
- Data
- Cloud Vendor Lock-In and Record Portability
- Safeguard
- access controls, logging and a contract that follows the record
- First check
- State the purpose in a sentence a student could understand.
The short answer
A practical way to approach cloud vendor lock-in and file portability is to ask what a student would expect if they saw the disclosing described in plain language. Where the disclosing matches that expectation and the authority supports it, it can proceed with a log entry; where it surprises, it needs permission, an identified exception or a fresh decision, not a quiet assumption.
Complaints regarding denied access deserve a documented answer, because an unexplained refusal teaches a student that rights are discretionary.
Annual notifications are not a formality: they are the moment students learn what directory information means and how to opt out.
Group mailboxes and shared drives are where access control most frequently fails, because nobody owns the membership list.
An exception that fits the facts of one case does not automatically fit the next case, even when the two cases involve the same system or the same department.
What this covers
Accrediting bodies receive data under a particular exception, and the scope of that exception ought to bound what is really sent.
Undocumented students face grave consequences from file disclosing, and employees should be especially careful about disclosing that could reveal status.
Wi-Fi monitoring can reconstruct a student's movements across campus, and that capability ought to be governed before it is used, not after it is discovered.
Publishing a directory notification in a handbook nobody reads is weaker than publishing it where students actually encounter it at enrollment.
Attendance information, participation logs and advising notes may all be education files when they are maintained about an identifiable student.
Third-party tools connected to a learning platform may receive more data than the integration was meant to pass, and the actual data flow ought to be tested, not assumed.
How to work through it
Design age screening to collect as little as possible, because screening that collects more than it needs becomes the problem it was meant to solve.
Inform students via the yearly notification that disclosures to schools where they seek to enroll occur, since surprise disclosures damage trust even when lawful.
Build opt-out into information feeds, so that an opt-out exercised in one platform propagates to every platform that publishes the information.
Assess biometric platforms with the highest gate of all, since the information cannot be reissued if compromised.
Read exemptions narrowly and on their own terms, and do not stretch an exception to cover a purpose that merely resembles the identified one.
Test phishing resilience for employees who handle records, since social engineering targets people, not firewalls.
Scrutinise monitoring in learning applications for younger students, because behavioural data grows quietly over a school year.
Audit disclosures against the log, and treat a disclosure missing from the log as a finding, not as a clerical gap.
A worked illustration
Consider a site that installs cameras in a residence hall entrance and writes storage, access and disclosure rules before the cameras are switched on.
In that illustration the disclosure log makes the answer easy, and the student leaves with a clearer picture of how their record travels.
Consider a labeled illustration: a mid-sized university adopts a new advising platform and maps which fields it shall hold before signing anything.
Consider a learning analytics project that begins with an issue about retention and ends with a dashboard that nobody can explain to a student.
Consider an instructor who wants a second opinion from a colleague about support for a student, and who first checks whether a summary without identifiers would serve.
Where guides go wrong
Assuming cloud hosting moves responsibility is a mistake, because the college remains answerable for a file another company stores.
Distributing a sensitive survey without settling anonymity and retention first is a mistake that cannot be repaired by a later apology.
The most common mistake is treating a record as informal since it lives in an email thread, a chat log or a shared drive rather than in the platform of record.
Responding to a media request from the first office that answers is an error, since the first office is rarely the office that knows the sharing limits.
Responding to an access request slowly, or in an unusable format, is a mistake, since delay turns a right into a frustration.
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