Chapter 14 — Privacy foundations
Lesson map
Lesson 14 published. Map, example, EX040.
flowchart TD
N0["Learning outcomes"]
N1["14.1 Principles"]
N2["14.2 Data location"]
N3["14.3 Minimisation in design"]
N4["14.4 Rights"]
N5["14.5 Breach duties"]
N6["14.6 Privacy and security"]
N7["14.7 Test data"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX040"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["14.1 Principles"]
N2["14.2 Data location"]
N3["14.3 Minimisation in design"]
N4["14.4 Rights"]
N5["14.5 Breach duties"]
N6["14.6 Privacy and security"]
N7["14.7 Test data"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX040"]
[Learning outcomes]
|
v
[14.1 Principles]
|
v
[14.2 Data location]
|
v
[14.3 Minimisation in design]
|
v
[14.4 Rights]
|
v
[14.5 Breach duties]
|
v
[14.6 Privacy and security]
|
v
[14.7 Test data]
|
v
[Worked example] --> [Exercise EX040]
Learning outcomes
You will (1) apply privacy principles to StudyHub; (2) minimise and protect student data; (3) understand lawful basis and rights; (4) build privacy into cloud designs.
14.1 Principles
Collect only what is needed, use it only for stated purposes, keep it only as long as needed, keep it accurate and secure, and be transparent with students.
For StudyHub, collecting only what is needed means the coursework service stores uploads and marks but not students' addresses. Stated purposes are published in the student privacy notice. Retention limits come from the rules in the data chapter. Transparency means students can see what StudyHub holds about them and why. Each principle has a matching check or process.
14.2 Data location
Where cloud data is stored affects which laws apply. Westmere keeps student data in its home region and records this in its data register.
Choosing a region is a configuration setting that can be changed by mistake, for example when a new storage bucket is created with a default region. Samuel's checker reports any resource holding student data outside the home region. In its first run, it found a log bucket in another region, which was moved. The register records why each region was chosen.
14.3 Minimisation in design
StudyHub's analytics use aggregated data; individual records stay in the records system. Logs mask student IDs.
Analytics that need counts per course do not need names or student IDs, so they receive only aggregates. Masking IDs in logs keeps logs useful for debugging while removing the most identifying field. The analytics job described below had drifted from this design, which a periodic check found. Masking replaces each ID with a token that stays consistent within a day, so engineers can follow one request through the logs without seeing who made it. Analytics jobs are listed in the data register with the fields they read.
14.4 Rights
Students can ask for their data; systems need a way to find and export it. Knowing where data lives (chapter 9) makes this possible.
A request for a student's data means searching the records system, coursework store and any logs that still contain the student's ID. Without the data register, the team might miss a store, such as the reporting bucket that once held full copies. The register lists which stores to search and who owns each. Exporting a student's data uses a script that searches each listed store.
14.5 Breach duties
Exposure of personal data may need reporting to a regulator and students within strict time limits. Good logging lets Westmere determine what was exposed.
In the opening case, audit logging was off in one account, so Westmere could not say whether the image had been pulled. If the test database had held real data, that gap would have made it impossible to tell the regulator or students what had happened. Turning logging on everywhere is a privacy control as much as a security one.
14.6 Privacy and security
Security controls protect privacy, but privacy also asks whether data should be collected at all.
Encrypting the nightly copies of full student records would have satisfied a security checklist, yet the right answer was to stop making them. Samuel's privacy review form asks first whether data is needed, then how to protect it. That order catches problems that a security-only review would leave in place. The review also asks who will use the data and whether they could manage with less. In StudyHub's case, the course reports needed only counts, so neither names nor IDs had to leave the records system at all.
14.7 Test data
Synthetic test data avoids privacy risk in testing entirely.
The opening case showed the value: the test database's synthetic records meant that, even with a leaked connection string and missing logs, no student could have been affected. Westmere's generator produces realistic names, courses and marks so tests behave as they would with real data, without any of the risk. Developers sometimes ask for a copy of production to reproduce a bug. The answer is to generate synthetic records with the same shape, or to reproduce the bug with a single consenting test account, never to copy real student data into a test environment.
Privacy reviews
New StudyHub features go through a short privacy review: what data, why, for how long, who can access it and whether a smaller set would do. The review takes under an hour for most features and is recorded. Samuel helps redesign the review form so developers answer in plain language. In its first term, the review stops one feature from collecting date of birth where age band was enough.
Worked example
Samuel finds that an old analytics job copies full student records nightly into a reporting bucket, though the reports only need counts per course. The job is changed to produce counts directly, and the bucket's old copies are deleted after approval.
Synthetic case. Data and jobs are synthetic.
Errors and limits
Aggregated data can still identify people in small groups; suppress small counts.
Exercises
- EX040 — Principles. List three privacy principles. Rubric: 3 = minimise, purpose, retention, accuracy, security, transparency; 2 = two; 1 = one; 0 = none.
- EX041 — Logging and breach. How does logging help with breach duties? Rubric: 3 = determine what was exposed; 2 = partial; 1 = vague; 0 = none.
- EX042 — Analytics change. How was the analytics job changed? Rubric: 3 = counts instead of full records; 2 = partial; 1 = vague; 0 = none.
Synthesis
Privacy asks whether data is needed, not only how to protect it.
Continue studying — chapter 14 of 40
← Chapter 13 (draft) · Course chapter index · Chapter 15 (draft) →