◇ OpenCyber Academy
Bachelor's · Chapter 14 · English

Chapter 14 — Privacy foundations

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 14 — Privacy foundations

Lesson map

Lesson 14 published. Map, example, EX040.

flowchart TD
  N0["Learning outcomes"]
  N1["14.1 Privacy principles"]
  N2["14.2 Pseudonymisation"]
  N3["Lab — Keyed versus unkeyed pseudonyms"]
  N4["14.3 Data-subject requests"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX040"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["14.1 Privacy principles"]
  N2["14.2 Pseudonymisation"]
  N3["Lab — Keyed versus unkeyed pseudonyms"]
  N4["14.3 Data-subject requests"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX040"]

[Learning outcomes]
    |
    v
[14.1 Privacy principles]
    |
    v
[14.2 Pseudonymisation]
    |
    v
[Lab — Keyed versus unkeyed pseudonyms]
    |
    v
[14.3 Data-subject requests]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX040]

Learning outcomes

You will (1) apply privacy principles to Fernway's member data; (2) design pseudonymisation for analytics; (3) handle data-subject requests through architecture.

14.1 Privacy principles

Lucas studies privacy principles common to data-protection laws: lawful purpose, data minimisation, accuracy, storage limitation, security and accountability. He applies them to Fernway's member programme. Members give their address for deliveries and purchase history for rewards. The marketing team wants to analyse purchases by area. Minimisation suggests they need postcode districts and product categories, not names and full addresses. Lucas learns that privacy shapes architecture: the analytics system should receive less data than the shop holds, by design rather than by policy alone.

14.2 Pseudonymisation

For analytics, Lucas designs pseudonymisation: member identifiers are replaced by keyed hashes computed with HMAC and a secret key held by the data team, not by analysts. The same member always maps to the same pseudonym, so purchases can be linked, but analysts cannot reverse it without the key. The lab below shows this on synthetic members and why an unkeyed hash is weaker: anyone can hash candidate member numbers and match them. Pseudonymised data is still personal data under many laws, so it still needs protection, but the risk is lower.

Lab — Keyed versus unkeyed pseudonyms

# Keyed (HMAC) vs unkeyed pseudonyms for synthetic member numbers. Teaching only.
import hmac, hashlib
KEY = b"synthetic-data-team-key"
members = ["M100231", "M100232", "M100233"]
keyed = {m: hmac.new(KEY, m.encode(), hashlib.sha256).hexdigest()[:12] for m in members}
plain = {m: hashlib.sha256(m.encode()).hexdigest()[:12] for m in members}
target_plain, target_keyed = plain["M100232"], keyed["M100232"]
guesses = [f"M1002{i:02d}" for i in range(100)]
hit_plain = [g for g in guesses if hashlib.sha256(g.encode()).hexdigest()[:12] == target_plain]
hit_keyed = [g for g in guesses if hashlib.sha256(g.encode()).hexdigest()[:12] == target_keyed]
print("stable keyed pseudonym:", keyed["M100232"] == hmac.new(KEY, b"M100232", hashlib.sha256).hexdigest()[:12])
print("guessing unkeyed pseudonym recovers:", hit_plain)
print("guessing keyed pseudonym (no key) recovers:", hit_keyed)

Run with python3 lab_pseudo.py. Verified output:

stable keyed pseudonym: True
guessing unkeyed pseudonym recovers: ['M100232']
guessing keyed pseudonym (no key) recovers: []

14.3 Data-subject requests

Members may ask to see or delete their data. Lucas maps where member data lives: the shop database, email marketing, analytics, backups and the delivery partner. Without the map, Fernway could not answer requests completely. He proposes that each system expose a way to find and delete a member's records, and that backups expire on a schedule rather than being edited. Handling requests becomes a test of the architecture: if data is spread in unknown places, the organisation cannot keep its promises to members.

Worked example

Lucas applies six privacy principles to the member programme, designs HMAC-based pseudonyms for analytics and maps five data locations for data-subject requests.

Synthetic case. Members, systems and keys are synthetic.

Errors and limits

Pseudonymised data can be re-identified by combining fields. Legal requirements differ by jurisdiction.

Exercises

Synthesis

Privacy architecture minimises data per purpose, pseudonymises analytics with keys and maps every copy to honour requests.

Continue studying — chapter 14 of 40

← Chapter 13 (draft) · Course chapter index · Chapter 15 (draft) →