StudentPrivacy.college
The Privacy Ledger - protect and govern student data

Data Residency in Cloud Contracts

Data Residency in Cloud Contracts explained for colleges: the rule, the exceptions, and the record an institution should keep.

Privacy check
Record
student record in the cloud in cloud systems and student portals
Data
Data Residency in Cloud Contracts
Safeguard
access controls, logging and a contract that follows the record
First check
Name the record and its holder before any use or disclosure.

The short answer

A practical way to approach data residency in cloud contracts is to request what a student would expect if they saw the disclosing described in plain language. Where the disclosing matches that expectation and the authorization supports it, it may proceed with a log entry; where it surprises, it needs permission, a named exemption or a fresh determination, not a quiet assumption.

Role changes must trigger access reviews, or former access quietly becomes current risk.

Data minimisation is the cheapest control available: data never collected can not be breached, misused or retained too long.

A disclosure log is not bureaucracy: it is the file that lets a student, an auditor or a regulator reconstruct what happened.

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

What this covers

Media requests for student information ought to go via the privacy officer, not via the first office that picks up the phone.

Cloud platforms do not alter what counts as a file, but they alter where copies live, and each copy needs the same oversight as the original.

Career services hold employment and internship data, and sharing that data with employers needs permission analysis even when the sharing feels useful.

Bluetooth beacons in classrooms may file attendance silently, and silent collection deserves explicit notification to the students affected.

Third-party tools connected to an education system can receive more data than the integration was meant to pass, and the actual data flow should be tested, not assumed.

Email may be an education record when it is maintained about a student, and the fact that it lives in a mailbox does not remove it from the category.

How to work through it

Start each determination by naming the file in plain terms, since a determination about an unnamed file is a determination about nothing in particular.

Review third-party access routinely, and remove access that is no longer required, rather than leaving it in place for convenience.

Require verifiable parental permission for younger users, and do not accept a checkbox that anyone can tick as verification.

Document exceptions to policy with a named approver and an expiry, since permanent exceptions are just undeclared policy changes.

Bound accrediting disclosures to the scope of the exemption, and send solely what the accreditation purpose needs.

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

Test vendor information flows in a staging environment where possible, since production testing risks the very files being protected.

Keep inventories current, and treat an inventory that is a year out of date as no inventory at all.

A worked illustration

In that illustration the sheet is restricted, the members are told, and the organisation adopts a form with proper access control for future collection.

Consider a researcher who asks for identifiable student files and is offered a de-identified extract instead, with a written agreement for the study.

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

In that illustration the request is answered for the employment capacity only, and the academic file is not disclosed by error.

In that illustration the registrar explains the position politely, in writing, and offers the parent a route through the student's own consent.

Where guides go wrong

A reader who applies that structure, and who escalates the cases it cannot settle, shall make better decisions than a reader who memorises any single rule in this ledger.

Distributing a sensitive survey without settling anonymity and storage first is a mistake that can not be repaired by a later apology.

Adopting a free tool without reviewing its data practices is a mistake, since the price is frequently paid in data uses nobody reviewed.

Auditing AI tools only for accuracy, and not for data storage and prompt handling, is a mistake, because AI platforms create records that ordinary audits miss.

Collecting disability data through assistive technology without reviewing the vendor is a mistake, because usage data may reveal disability.

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

Next on the ledger