Chapter 21 — Privacy and data protection: requirements
Lesson map
Lesson 21 published. Map, example, EX061.
flowchart TD
N0["Learning outcomes"]
N1["21.1 From principles to requirements"]
N2["21.2 Testable wording"]
N3["21.3 Rights as requirements"]
N4["21.4 Prioritising by risk"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX061"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["21.1 From principles to requirements"]
N2["21.2 Testable wording"]
N3["21.3 Rights as requirements"]
N4["21.4 Prioritising by risk"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX061"]
[Learning outcomes]
|
v
[21.1 From principles to requirements]
|
v
[21.2 Testable wording]
|
v
[21.3 Rights as requirements]
|
v
[21.4 Prioritising by risk]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX061]
Learning outcomes
You will (1) derive requirements from legal principles; (2) make requirements testable; (3) prioritise requirements by risk.
21.1 From principles to requirements
Zara starts the third year by deriving requirements from the principles in GDPR Article 5: lawfulness, fairness and transparency; purpose limitation; data minimisation; accuracy; storage limitation; integrity and confidentiality; and accountability. For each she writes at least one engineering requirement for Pellmore. Purpose limitation becomes: every data field shall be tagged with the purposes for which it may be used, and services shall read only fields tagged for their purpose. Turning principles into requirements forces precision that the legal text, written to apply everywhere, cannot provide.
21.2 Testable wording
A requirement that cannot be tested cannot be verified. Zara rewrites vague statements. "Data shall be kept secure" becomes "clinical notes shall be encrypted at rest with keys held in the hardware module, verified quarterly". "Patients shall be able to access their data" becomes "a patient shall be able to download all personal data held about them within one minute of request, in a machine-readable format". Each requirement now has a verification method. ISO/IEC 29100 provides consistent terms such as PII principal and PII controller, which Zara uses in the definitions section.
21.3 Rights as requirements
Zara writes requirements for each data subject right that applies to Pellmore: access, rectification, erasure, restriction, portability and objection. For erasure she specifies which stores must be covered and which exceptions apply, such as medical records that must be retained under health law. The LGPD Article 18 lists similar rights for Brazilian patients, including information about sharing with third parties. Writing the rights as system requirements reveals that portability needs a structured export format that Pellmore does not yet have. She adds a JSON export ticket.
21.4 Prioritising by risk
Not all requirements can be built at once. Zara ranks them by the harm their absence would cause and the likelihood that it would occur. Erasure of video recordings and access control for clinical notes come first; portability of appointment history comes later. She records the ranking and its reasoning in the decision log. Prof. Holm reminds her that risk-based prioritisation is supported by the GDPR, which repeatedly asks for measures appropriate to the risk, but legal duties still apply even when ranked lower.
Worked example
Zara derives requirements from each Article 5 principle, rewrites them as testable statements, specifies rights requirements for GDPR and LGPD and ranks them by risk.
Synthetic case. Requirements are synthetic; GDPR Article 5, LGPD Article 18 and ISO/IEC 29100 are real.
Errors and limits
Ranking cannot postpone a legal duty indefinitely; lower-ranked items still need dates.
Exercises
- EX061 — Purpose tagging. How does Zara turn purpose limitation into a requirement? Rubric: 3 = tag fields with permitted purposes; services read only fields tagged for their purpose;; 2 = mentions tags;; 1 = restates principle;; 0 = none.
- EX062 — Testable access. Rewrite "patients shall be able to access their data" testably. Rubric: 3 = download all data within one minute in machine-readable format;; 2 = partly measurable;; 1 = vague;; 0 = none.
- EX063 — Portability gap. Which gap did rights requirements reveal? Rubric: 3 = no structured export format for portability;; 2 = mentions export;; 1 = vague;; 0 = none.
Synthesis
Chapter 21 writes requirements. Chapter 22 models systems and data flows.
Continue studying — chapter 21 of 50
← Chapter 20 (draft) · Course chapter index · Chapter 22 (draft) →