Chapter 14 — Privacy foundations
Lesson map
Lesson 14 published. Map, example, EX040.
flowchart TD
N0["Learning outcomes"]
N1["14.1 Personal data"]
N2["14.2 Principles"]
N3["14.3 Privacy by design"]
N4["14.4 Requests"]
N5["14.5 Supply chain and privacy"]
N6["14.6 Breach response"]
N7["Retention schedule"]
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 Personal data"]
N2["14.2 Principles"]
N3["14.3 Privacy by design"]
N4["14.4 Requests"]
N5["14.5 Supply chain and privacy"]
N6["14.6 Breach response"]
N7["Retention schedule"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX040"]
[Learning outcomes]
|
v
[14.1 Personal data]
|
v
[14.2 Principles]
|
v
[14.3 Privacy by design]
|
v
[14.4 Requests]
|
v
[14.5 Supply chain and privacy]
|
v
[14.6 Breach response]
|
v
[Retention schedule]
|
v
[Worked example] --> [Exercise EX040]
Learning outcomes
You will (1) identify personal data in an application; (2) apply data protection principles; (3) design privacy-friendly features; (4) handle data subject requests.
14.1 Personal data
CampusEats holds names, university emails, order histories and optional dietary preferences. Dietary information can reveal health or religious beliefs, making it sensitive.
Lena lists each data item with its purpose and who can see it. University email is needed to link orders to a student; dietary preferences help cafés prepare suitable meals but are not needed to place an order, which is why they are optional. Order history is kept so students can reorder and cafés can plan stock, and Lena sets a retention period for it rather than keeping it indefinitely.
14.2 Principles
Collect only what is needed, use it only for stated purposes, keep it accurate, delete it when no longer needed and protect it. These principles appear in data protection laws in many countries.
Lena turns each principle into a question for every new feature: what data does it need, for what purpose, for how long, and who can see it? A proposed feature to show students their friends' orders is dropped because it would use order history for a purpose students never agreed to.
14.3 Privacy by design
Dietary preferences are optional and stored separately with tighter access. Analytics use counts, not individual histories.
Café staff see dietary notes only for orders they are preparing, not a student's full profile. Weekly reports show how many vegetarian or gluten-free meals were ordered, which helps planning without revealing anyone's choices. Lena checks that the analytics tables contain no identifiers that could link counts back to individual students, and that access to the separate dietary table is logged. Tighter access is checked each term.
14.4 Requests
Students can download or delete their data from their profile page. Deletion removes personal details but keeps anonymised order counts for café planning.
Lena tests both features with a synthetic account and confirms that deleted details are gone from the live database. Backups still hold old copies for their retention period, so the privacy notice explains this and the restore procedure removes deleted accounts before restored data goes live. Requests are logged so the society can show it acted on them.
14.5 Supply chain and privacy
Third-party scripts in the browser can see page content. CampusEats removed an analytics script that collected more than needed, replacing it with server-side counts.
The removed script also loaded further code from its provider's servers, which CampusEats could not review, so removing it reduced both privacy and supply-chain risk. The server-side counts give the society the figures it needed, such as busy times, without sending student data to another company. Lena now asks of every new third-party script what page data it can see and where it sends it.
14.6 Breach response
If personal data might be exposed, the university's data protection officer must be informed quickly.
Lena's incident notes for the token leak include a short check of whether any personal data was involved; it was not, but the check is recorded. The society keeps the officer's contact details in its runbook, with a list of what to report: what data, how many students, when it happened and what has been done. Notifying early, even with incomplete facts, is better than waiting for certainty.
Retention schedule
Each data type has a retention period: sessions 30 minutes, order details two years, logs 90 days, deleted accounts' data removed within 30 days. A scheduled job deletes expired records automatically and reports counts, so the society can show it follows its own rules. Lena tests the job on synthetic data before enabling it.
Privacy notice
A short privacy notice explains in plain words what data CampusEats collects, why and for how long.
Review
The notice is reviewed yearly with the data protection officer.
Worked example
Lena reviews the token leak for privacy impact: the token gave access to the payment provider's test environment only, with synthetic data, so no personal data was exposed. She records this assessment with the data protection officer.
Synthetic case. Data and assessments are synthetic.
Errors and limits
Anonymised data can sometimes be re-identified when combined with other data; aggregate carefully.
Exercises
- EX040 — Sensitive data. Why is dietary information sensitive? Rubric: 3 = can reveal health or religion; 2 = partial; 1 = vague; 0 = none.
- EX041 — Analytics change. What did CampusEats do about the analytics script? Rubric: 3 = removed; server-side counts; 2 = partial; 1 = vague; 0 = none.
- EX042 — Leak privacy impact. Did the token leak expose personal data? Rubric: 3 = no; test environment with synthetic data; 2 = partial; 1 = vague; 0 = none.
Synthesis
Collect less, protect more and let users control their data.
Continue studying — chapter 14 of 40
← Chapter 13 (draft) · Course chapter index · Chapter 15 (draft) →