Chapter 23 — Privacy and data protection: threat and failure analysis | Engineering Privacy and data protection

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 23 — Privacy and data protection: threat and failure analysis

Lesson map

Lesson 23 published. Map, example, EX067.

flowchart TD
  N0["Learning outcomes"]
  N1["23.1 Privacy threats"]
  N2["23.2 Failure modes"]
  N3["23.3 Insiders and errors"]
  N4["23.4 Ranking threats"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX067"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["23.1 Privacy threats"]
  N2["23.2 Failure modes"]
  N3["23.3 Insiders and errors"]
  N4["23.4 Ranking threats"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX067"]

[Learning outcomes]
    |
    v
[23.1 Privacy threats]
    |
    v
[23.2 Failure modes]
    |
    v
[23.3 Insiders and errors]
    |
    v
[23.4 Ranking threats]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX067]

Learning outcomes

You will (1) apply a privacy threat model to the platform; (2) analyse failure modes that harm privacy; (3) include non-malicious threats.

23.1 Privacy threats

Security threat models focus on attackers. Zara adds privacy threats that can occur without any attacker: linkability, identifiability, non-repudiation, detectability, disclosure, unawareness and non-compliance. She applies them to the video consultation flow. Linkability arises because the same identifier appears in video logs and analytics; unawareness because patients are not told that the vendor records sessions. Solove's taxonomy supports the same analysis from a legal angle, naming harms such as aggregation and secondary use that a purely security-focused model would miss. Both views are recorded.

23.2 Failure modes

Zara performs a failure mode analysis on the erasure process. Possible failures include a deletion job that times out, a store that is not included in the job, a backup restored without reapplying deletions and a vendor that ignores the request. For each she estimates the effect on patients and how it would be detected. The vendor failure is hardest to detect because Pellmore cannot see the vendor's systems. She proposes contractual confirmation of deletion and periodic audit rights, which Article 28 of the GDPR allows controllers to require.

23.3 Insiders and errors

Many privacy incidents involve staff error or curiosity rather than outside attackers. Zara models a receptionist sending results to the wrong email address and a clinician looking up a neighbour's record. Controls include address confirmation, access logging with anomaly signals from Chapter 17 and training. She notes that monitoring staff is itself processing of personal data and must be proportionate and transparent to employees. The analysis shows that privacy threat models must include the organisation's own people, both as potential sources of harm and as people whose own privacy deserves respect.

23.4 Ranking threats

Zara ranks threats using a simple combination of likelihood and harm, and selects the top five for detailed treatment in the data protection impact assessment. Linkability through shared identifiers, vendor retention, misdirected results, staff snooping and analytics over-collection lead the list. She writes each threat as a short scenario that non-engineers can follow. Prof. Holm points out that scenarios make threats concrete for decision-makers, as she learned in communication, and that they also become test cases for the verification laboratory later in the year.

Worked example

Zara applies privacy threat categories to video consultations, analyses erasure failure modes, models insider errors and ranks five threats for the DPIA.

Synthetic case. Scenarios are synthetic; Solove (2006) and GDPR Article 28 are real.

Errors and limits

Threat lists are never complete; revisit after incidents and design changes.

Exercises

EX067 — Non-attacker threats. Name two privacy threats that need no attacker. Rubric: 3 = e.g. unawareness and non-compliance (also linkability);; 2 = names one;; 1 = names hacking;; 0 = none.
EX068 — Vendor failure. Why is vendor non-deletion hard to detect, and what helps? Rubric: 3 = Pellmore cannot see vendor systems; contractual confirmation and audit rights;; 2 = one part;; 1 = ignores;; 0 = none.
EX069 — Staff monitoring. What constraint applies to monitoring staff access? Rubric: 3 = it must be proportionate and transparent because it processes employees' data;; 2 = mentions privacy;; 1 = unlimited;; 0 = none.

Synthesis

Chapter 23 finds threats. Chapter 24 assesses them in a DPIA.

Continue studying — chapter 23 of 50

← Chapter 22 (draft) · Course chapter index · Chapter 24 (draft) →