Chapter 29 — Privacy and data protection: measurement
Lesson map
Lesson 29 published. Map, example, EX085.
flowchart TD
N0["Learning outcomes"]
N1["29.1 Measuring minimisation"]
N2["29.2 Acting on the measure"]
N3["29.3 A metric set"]
N4["29.4 Metrics without new risk"]
N5["Lab — Fields collected versus needed by purpose"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX085"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["29.1 Measuring minimisation"]
N2["29.2 Acting on the measure"]
N3["29.3 A metric set"]
N4["29.4 Metrics without new risk"]
N5["Lab — Fields collected versus needed by purpose"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX085"]
[Learning outcomes]
|
v
[29.1 Measuring minimisation]
|
v
[29.2 Acting on the measure]
|
v
[29.3 A metric set]
|
v
[29.4 Metrics without new risk]
|
v
[Lab — Fields collected versus needed by purpose]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX085]
Learning outcomes
You will (1) measure data minimisation; (2) define privacy metrics; (3) report metrics without creating new risks.
29.1 Measuring minimisation
Zara wants to measure whether Pellmore collects only what it needs. She lists, for each purpose, the fields collected and the fields actually needed, agreed with the owners of each process. The booking form collects eight fields but needs five; address, gender and occupation are not needed. Video consultations collect six fields but need four; contacts and location are not needed. The newsletter collects four fields but needs only email. Overall, 8 of 18 collected fields, 44%, are not needed for their purpose. Removing them cuts exposure directly.
29.2 Acting on the measure
The minimisation figure leads to changes. Zara removes the unnecessary booking fields, stops collecting phone contacts and location in the video app, and reduces the newsletter sign-up to an email address. She plans to re-measure after a release cycle. She also notes that the measure depends on owners' honest judgement of need: an owner who claims everything is needed would make the figure look good. A second reviewer, the data protection officer, checks each need claim against the purpose description before the figure is reported.
29.3 A metric set
Beyond minimisation, Zara defines a small set of privacy metrics: records past retention, flows without complete inventory fields, rights requests answered on time, consent reconciliation mismatches, and access anomalies reviewed within a week. Each has a definition, a data source, an owner and a target. The NIST Privacy Framework encourages organisations to monitor and review privacy risk, and the metric set gives Pellmore a way to do that regularly. She keeps the set small so that people actually read the monthly report.
29.4 Metrics without new risk
Measurement can create new privacy risks. A report listing staff with access anomalies could stigmatise innocent people if shared widely. Zara aggregates the report for management and gives named details only to the investigator. Similarly, rights request metrics show counts and timings, not who made requests. She writes a short rule: privacy metrics must themselves follow data minimisation. Prof. Holm calls this the recursive principle of privacy engineering, applying the same care to monitoring data as to the data being monitored. Monitoring logs expire quickly.
Lab — Fields collected versus needed by purpose
# Data minimisation: fields collected per purpose versus fields the purpose actually needs.
collected = {"booking": {"name", "dob", "phone", "email", "address", "insurer", "gender", "occupation"},
"video consultation": {"name", "dob", "symptoms", "camera", "location", "contacts"},
"newsletter": {"email", "name", "dob", "postcode"}}
needed = {"booking": {"name", "dob", "phone", "email", "insurer"},
"video consultation": {"name", "dob", "symptoms", "camera"},
"newsletter": {"email"}}
tc = tn = 0
for p in collected:
extra = sorted(collected[p] - needed[p]); tc += len(collected[p]); tn += len(needed[p])
print(f"{p:19s} collected {len(collected[p])} needed {len(needed[p])} excess {extra}")
print(f"overall: {tc - tn} of {tc} collected fields ({(tc - tn)/tc:.0%}) are not needed")
Run with python3 lab_minimise.py. Verified output:
booking collected 8 needed 5 excess ['address', 'gender', 'occupation']
video consultation collected 6 needed 4 excess ['contacts', 'location']
newsletter collected 4 needed 1 excess ['dob', 'name', 'postcode']
overall: 8 of 18 collected fields (44%) are not needed
Worked example
Zara finds 8 of 18 collected fields (44%) are not needed, removes them, defines five privacy metrics with owners and targets, and aggregates metric reports to avoid creating new risks.
Synthetic case. Fields and purposes are synthetic; the NIST Privacy Framework 1.0 is real.
Errors and limits
Field counts ignore sensitivity; one unnecessary health field may matter more than three contact fields.
Exercises
- EX085 — Minimisation result. What share of collected fields is unnecessary? Rubric: 3 = 8 of 18, 44%;; 2 = about four in ten;; 1 = wrong;; 0 = none.
- EX086 — Need claims. Why does a second reviewer check need claims? Rubric: 3 = owners may overstate need, making the measure look good;; 2 = mentions bias;; 1 = trusts owners;; 0 = none.
- EX087 — Recursive principle. What is the recursive principle of privacy engineering? Rubric: 3 = monitoring data must also follow privacy principles such as minimisation;; 2 = mentions metrics;; 1 = vague;; 0 = none.
Synthesis
Chapter 29 measures privacy. Chapter 30 verifies controls in the first laboratory.
Continue studying — chapter 29 of 50
← Chapter 28 (draft) · Course chapter index · Chapter 30 (draft) →