Chapter 5 — Engineering communication | 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 5 — Engineering communication

Lesson map

Lesson 05 published. Map, example, EX013.

flowchart TD
  N0["Learning outcomes"]
  N1["5.1 Writing for patients"]
  N2["5.2 Layered information"]
  N3["5.3 Design decision records"]
  N4["5.4 Explaining risk plainly"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX013"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["5.1 Writing for patients"]
  N2["5.2 Layered information"]
  N3["5.3 Design decision records"]
  N4["5.4 Explaining risk plainly"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX013"]

[Learning outcomes]
    |
    v
[5.1 Writing for patients]
    |
    v
[5.2 Layered information]
    |
    v
[5.3 Design decision records]
    |
    v
[5.4 Explaining risk plainly]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX013]

Learning outcomes

You will (1) write privacy notices engineers and patients understand; (2) document design decisions; (3) explain risk without jargon.

5.1 Writing for patients

In engineering communication Zara rewrites Pellmore's privacy notice. The original is long and legalistic. Articles 12 to 14 of the GDPR require information to be given in a concise, transparent, intelligible and easily accessible form, using clear and plain language. Zara reorganises the notice around patients' questions: what is collected, why, who sees it, how long it is kept and how to exercise rights. She tests the draft with five classmates who are not engineers and rewrites every sentence they misread. The final notice is shorter and more accurate.

5.2 Layered information

Zara learns that one document cannot serve everyone. She designs a layered notice: a short summary at the point of booking, a full notice linked from it, and specific explanations at the moment a feature uses data, such as when the app asks for camera access. Acquisti, Brandimarte and Loewenstein (2015) describe how people's privacy decisions depend on context and framing, which supports giving information at the moment of decision rather than only in a long document read once, if at all, when an account is created.

5.3 Design decision records

Engineers also need to communicate with each other. Zara starts a decision log for her Pellmore work. Each entry states the decision, the alternatives considered, the privacy reasoning and who approved it. For example, she records the choice to store booking references rather than names in analytics. Prof. Holm explains that such records support the accountability principle in Article 5(2) of the GDPR, which requires a controller to be able to demonstrate compliance, and that they help future engineers understand why a system looks the way it does.

5.4 Explaining risk plainly

Zara practises explaining risk to managers. Instead of saying that a dataset has high re-identification risk, she says that someone who knows a patient's postcode and birth date could find that patient's consultation history in it. Concrete explanations lead to better decisions because managers can picture the harm. She also learns to state uncertainty honestly, for example that a risk estimate depends on what an attacker knows, without hiding behind it. Communication, she concludes, is an engineering skill that determines whether good designs are adopted at all.

Worked example

Zara rewrites the privacy notice around patients' questions, layers it at decision points, starts a decision log for accountability and practises concrete risk explanations.

Synthetic case. The notice and decision log are synthetic; GDPR Articles 5(2) and 12–14 and Acquisti et al. (2015) are real.

Errors and limits

Plain language must stay accurate; simplification that misstates processing breaches transparency.

Exercises

EX013 — Transparency standard. What form must GDPR information take? Rubric: 3 = concise, transparent, intelligible, easily accessible, clear and plain language;; 2 = lists some;; 1 = says detailed;; 0 = none.
EX014 — Just-in-time notice. Why give information when a feature uses data? Rubric: 3 = decisions depend on context, so information at that moment is more useful;; 2 = mentions timing;; 1 = says once is enough;; 0 = none.
EX015 — Decision log role. Which principle does the decision log support? Rubric: 3 = accountability in Article 5(2);; 2 = mentions accountability;; 1 = names another;; 0 = none.

Synthesis

Chapter 5 makes communication part of design. Chapter 6 returns to mathematics with accumulation.

Continue studying — chapter 05 of 50

← Chapter 04 (draft) · Course chapter index · Chapter 06 (draft) →