Chapter 14 — Privacy foundations
Lesson map
Lesson 14 published. Map, example, EX027.
flowchart TD
N0["Learning outcomes and connection"]
N1["14.1 Security is not privacy"]
N2["14.2 Principles"]
N3["14.3 Personal data in unexpected places"]
N4["14.4 Privacy in security operations"]
N5["14.6 Practical activity"]
N6["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX027"]
Logical drawing
flowchart LR
N0["Learning outcomes and connection"]
N1["14.1 Security is not privacy"]
N2["14.2 Principles"]
N3["14.3 Personal data in unexpected places"]
N4["14.4 Privacy in security operations"]
N5["14.6 Practical activity"]
N6["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX027"]
[Learning outcomes and connection]
|
v
[14.1 Security is not privacy]
|
v
[14.2 Principles]
|
v
[14.3 Personal data in unexpected places]
|
v
[14.4 Privacy in security operations]
|
v
[14.6 Practical activity]
|
v
[Chapter synthesis]
|
v
[Worked example] --> [Exercise EX027]
Learning outcomes and connection
After this chapter you can (1) explain the difference between security and privacy; (2) apply data-protection principles such as lawfulness, purpose limitation, minimisation and storage limitation; (3) identify personal data in critical-service systems, including data that becomes personal when combined; and (4) recommend privacy-protective designs for monitoring and incident data. It builds on Chapter 9 (data) and Chapter 10 (ethics) and prepares Chapter 29 (operations) and the capstone's ethics requirements.
14.1 Security is not privacy
Security protects systems and information from unauthorised access, change and loss. Privacy concerns whether the processing of information about people — even authorised processing — is appropriate, proportionate and fair. A perfectly secure hospital database can still violate privacy if it is used for a purpose patients were never told about. The NIST Privacy Framework treats privacy risk as arising from data processing itself, overlapping with but distinct from cybersecurity risk.
CT's clone detection is the example: secure storage of two years of taps would still be a privacy problem.
14.2 Principles
The EU General Data Protection Regulation sets out principles that are widely mirrored elsewhere: lawfulness, fairness and transparency; purpose limitation; data minimisation; accuracy; storage limitation; integrity and confidentiality; and accountability (Regulation (EU) 2016/679, Article 5). Health data is a special category requiring additional conditions. You do not need to become a lawyer, but you must recognise when a design question is also a data-protection question and involve the organisation's data-protection officer — and you must never present this book's summary as legal advice for a specific case.
14.3 Personal data in unexpected places
Critical services hold obvious personal data (patient records, bank accounts, emergency calls) and less obvious data. Smart-meter readings at short intervals can reveal when a household is home. Ticketing data from a transit card traces a person's movements. Security logs record who logged in, from where and when — personal data about staff. Combination matters: neither a postcode nor a date of birth alone usually identifies someone, but together with sex they often do. Pseudonymisation (replacing names with codes) reduces risk but is not anonymisation if the key exists or re-identification is possible.
14.4 Privacy in security operations
Security monitoring collects data about people by design. Privacy-protective practice: collect what the detection purpose needs, not everything available; restrict access to raw logs; set retention periods; pseudonymise where analysis does not need names; document the purpose and lawful basis; and, in an incident, share indicators (addresses, file hashes) rather than personal data where possible. During a breach involving personal data, notification duties may apply on short timescales, so incident plans include the data-protection officer from the start.
CT's revised design applies four of these: 30-day detail, keyed pseudonyms, two named analysts and a stated purpose.
14.5 Worked example: CT ticketing analytics (synthetic)
This case is synthetic. Calder Transit's security team wants to detect cloned transit cards by looking for the same card used at two stations too far apart in too short a time. The proposed design copies every card tap (card ID, station, time) for two years into the security analytics platform. A privacy review asks: is two years needed? (Clone detection needs minutes to days; retain full detail for 30 days, then aggregate.) Is the card ID needed in clear? (A keyed pseudonym suffices for matching; only confirmed cases are re-identified, by the fraud team.) Who can query it? (Two named analysts, logged.) Is passenger travel history being created as a side effect? (Yes — which is why the design limits retention and access.) The revised design meets the detection purpose with a fraction of the privacy risk.
14.6 Practical activity
Choose one service you use (a transit card, a smart meter, a hospital app). From its public privacy notice, list the personal data collected, the stated purposes and retention. Identify one data item whose purpose is unclear and draft a question you could send the provider.
Notice whether the notice states retention in days or years, or only "as long as necessary"; the latter is a question worth asking. Note whether security monitoring is listed as a purpose at all. Draft your question politely and specifically, for example asking how long journey-level data is kept before aggregation and who can access it.
14.7 Common errors and limits
- "We are secure, therefore we are compliant."
- Collecting everything "in case it is useful".
- Calling pseudonymised data anonymous.
- Forgetting staff data in logs.
- Giving legal conclusions without the organisation's legal and data-protection advisers.
Each appears in this chapter's examples. CT's original two-year tap copy was secure and still disproportionate. "In case it is useful" is how the full card ID ended up in the analytics platform. Keyed pseudonyms are reversible by the fraud team, so they are not anonymous. CVH's access-monitoring proposal in EX027 logs staff names, which is staff personal data. And none of these designs should be called lawful without the data-protection officer.
Exercises — chapter 14
EX027 — Minimise a log. Objective: apply minimisation to security monitoring. Inputs: a CVH proposal to log every staff access to patient records with full patient name, diagnosis, staff name, workstation, time, retained indefinitely, to detect inappropriate access. Steps: propose a minimised design meeting the same purpose. Expected evidence: field list, retention, access and a sentence on purpose. Rubric: 3 = record identifier instead of diagnosis, defined retention, restricted access, purpose stated, staff informed; 2 = partial; 1 = "log less" without design; 0 = none.
EX028 — Combination risk. Objective: recognise re-identification. Inputs: CW publishes "anonymised" hourly consumption per meter with postcode and property type. Steps: explain two re-identification risks and two mitigations. Expected evidence: explanation. Rubric: 3 = small postcodes with unique property types identify households, occupancy inferable from hourly patterns; mitigations: aggregation thresholds, coarser time or location, access agreements; 2 = one each; 1 = vague; 0 = none.
Chapter synthesis
Privacy asks whether processing about people is appropriate, not only whether it is secure. Apply purpose limitation, minimisation and storage limitation — especially to security monitoring itself — recognise that combinations re-identify, and involve data-protection specialists rather than offering legal conclusions.
Continue studying — chapter 14 of 40
← Chapter 13 · Course chapter index · Chapter 15 →
Continue to the next authored lesson.