Chapter 30 — Verification laboratory I | 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 30 — Verification laboratory I

Lesson map

Lesson 30 published. Map, example, EX088.

flowchart TD
  N0["Learning outcomes"]
  N1["30.1 Tests from threats"]
  N2["30.2 Rights tests"]
  N3["30.3 Evidence"]
  N4["30.4 Retesting"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX088"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["30.1 Tests from threats"]
  N2["30.2 Rights tests"]
  N3["30.3 Evidence"]
  N4["30.4 Retesting"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX088"]

[Learning outcomes]
    |
    v
[30.1 Tests from threats]
    |
    v
[30.2 Rights tests]
    |
    v
[30.3 Evidence]
    |
    v
[30.4 Retesting]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX088]

Learning outcomes

You will (1) verify privacy controls with tests; (2) design tests from threats; (3) record evidence for accountability.

30.1 Tests from threats

In the first verification laboratory Zara turns the threat scenarios from Chapter 23 into tests. For linkability, she checks that analytics events carry recipient-specific pseudonyms and that no two recipients receive the same identifier. For misdirected results, she sends synthetic results with mismatched names and checks that the system blocks them. For staff snooping, she simulates record views without appointments and checks that the anomaly signal fires within a day. Each test has an expected result defined before running, which prevents interpreting results generously afterwards.

30.2 Rights tests

Zara tests data subject rights end to end. She creates a synthetic patient, uses the app for a week of fake appointments and messages, then requests access, rectification and erasure. The access export includes all data except chat logs, which are stored by a vendor and not yet integrated. The erasure request removes data from four of five stores, but the analytics store keeps events under the pseudonym. Both failures become defects with owners. She records that end-to-end tests with realistic synthetic patients find gaps that unit tests cannot see.

30.3 Evidence

Each test produces evidence: inputs, outputs, date and tester. Zara stores evidence in a versioned folder and summarises results in a table. The accountability principle requires that Pellmore can demonstrate compliance, and test evidence is one of the strongest forms of demonstration. She explains that a statement that erasure works is a claim, while a dated test log showing erasure across all stores is evidence. Prof. Holm asks her to include failing tests in the evidence, because hiding failures would make the folder misleading.

30.4 Retesting

After the defects are fixed, Zara repeats the tests. The access export now includes chat logs, and erasure reaches the analytics store. She records both runs, showing the failure and the fix. She also adds the tests to the continuous integration pipeline so that they run on every release. Verification, she concludes, is not a one-off certificate but a habit: privacy properties can break whenever the system changes, and only tests that run regularly catch regressions before they reach patients. Tests run on every release.

Worked example

Zara turns threats into tests, finds gaps in access (chat logs missing) and erasure (analytics retained), records evidence including failures and adds retests to continuous integration.

Synthetic case. Tests and the synthetic patient are synthetic.

Errors and limits

Tests verify what they check; untested paths can still fail.

Exercises

EX088 — Expected results. Why define expected results before running tests? Rubric: 3 = to prevent generous interpretation after seeing results;; 2 = mentions bias;; 1 = not needed;; 0 = none.
EX089 — Erasure gap. Which store kept data after erasure in the first run? Rubric: 3 = the analytics store, under the pseudonym;; 2 = names analytics;; 1 = vague;; 0 = none.
EX090 — Claim versus evidence. Distinguish a claim from evidence about erasure. Rubric: 3 = a claim says it works; evidence is a dated test log across stores;; 2 = mentions logs;; 1 = equates them;; 0 = none.

Synthesis

Chapter 30 verifies controls. Chapter 31 implements the next generation of features.

Continue studying — chapter 30 of 50

← Chapter 29 (draft) · Course chapter index · Chapter 31 (draft) →