Chapter 39 — Privacy and data protection: maintainability

Lesson map

Lesson 39 published. Map, example, EX115.

flowchart TD
  N0["Learning outcomes"]
  N1["39.1 Privacy debt"]
  N2["39.2 Readable controls"]
  N3["39.3 Dependency updates"]
  N4["39.4 Handover"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX115"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["39.1 Privacy debt"]
  N2["39.2 Readable controls"]
  N3["39.3 Dependency updates"]
  N4["39.4 Handover"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX115"]

[Learning outcomes]
    |
    v
[39.1 Privacy debt]
    |
    v
[39.2 Readable controls]
    |
    v
[39.3 Dependency updates]
    |
    v
[39.4 Handover]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX115]

Learning outcomes

You will (1) keep privacy controls maintainable; (2) manage technical debt with privacy impact; (3) document for future engineers.

39.1 Privacy debt

Technical debt accumulates when shortcuts are taken. Zara defines privacy debt as shortcuts that weaken privacy: temporary data copies, disabled checks, undocumented flows. She creates a register of privacy debt items with owners and repayment dates. The register reveals a temporary export created for a regulator's question two years earlier that was never removed. She deletes it. She explains that privacy debt is especially dangerous because, unlike performance debt, its costs appear only when harm occurs or an audit asks questions. She tracks it in the backlog.

39.2 Readable controls

Controls must be understandable to future engineers. Zara rewrites the access policy configuration with comments explaining each rule and its legal or clinical reason. She adds diagrams to the privacy platform documentation. She also writes architecture decision records for the major choices of the past two years, so that new engineers do not undo protections through misunderstanding. Prof. Holm notes that maintainability is a precondition for accountability, because an organisation that cannot explain its own controls cannot demonstrate compliance. Code comments cite the requirement each control satisfies.

39.3 Dependency updates

The privacy platform depends on libraries for cryptography, differential privacy and messaging. Zara sets up automated dependency checks and a policy for updating them. She tests updates against the privacy test suite before deployment. An update to the messaging library once changed retry behaviour, which would have affected erasure reliability. The test suite caught it. She records the event as evidence that the tests protect against regressions introduced by third-party code, not only by Pellmore's own engineers. A library upgrade had silently changed the default log level, and the privacy unit test failed on the first build.

39.4 Handover

As Zara's placement nears its end, she prepares a handover. Each control has an owner, documentation, tests and metrics. She runs walkthroughs with the engineers who will maintain the platform. She also lists open risks and the privacy debt register. Pellmore's engineering lead signs off the handover. Zara reflects that good maintainability is invisible when it works: nobody notices that a control still functions after two years, but they would notice quickly, and painfully, if it had silently decayed. Ownership must therefore be explicit.

Worked example

Zara creates a privacy debt register (deleting a two-year-old temporary export), documents controls with reasons, catches a messaging library regression with tests and hands over with owners and open risks.

Synthetic case. Debt items and the library change are synthetic.

Errors and limits

Debt registers need regular review or they become lists nobody reads.

Exercises

• EX115 — Privacy debt. Define privacy debt.
  Show marking criteria

  Rubric: 3 = shortcuts that weaken privacy, such as temporary copies or disabled checks;; 2 = example only;; 1 = technical debt in general;; 0 = none.
• EX116 — Library regression. What did the test suite catch after a library update?
  Show marking criteria

  Rubric: 3 = changed retry behaviour affecting erasure reliability;; 2 = mentions erasure;; 1 = vague;; 0 = none.
• EX117 — Maintainability and accountability. Why is maintainability a precondition for accountability?
  Show marking criteria

  Rubric: 3 = an organisation that cannot explain its controls cannot demonstrate compliance;; 2 = mentions explanation;; 1 = unrelated;; 0 = none.

Synthesis

Chapter 39 keeps controls healthy. Chapter 40 is the second verification laboratory.

Continue studying — chapter 39 of 50

← Chapter 38 (draft) · Course chapter index · Chapter 40 (draft) →