Chapter 14 — Software engineering | 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 14 — Software engineering

Lesson map

Lesson 14 published. Map, example, EX040.

flowchart TD
  N0["Learning outcomes"]
  N1["14.1 Privacy stories"]
  N2["14.2 Code review"]
  N3["14.3 Test data"]
  N4["14.4 Definition of done"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX040"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["14.1 Privacy stories"]
  N2["14.2 Code review"]
  N3["14.3 Test data"]
  N4["14.4 Definition of done"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX040"]

[Learning outcomes]
    |
    v
[14.1 Privacy stories]
    |
    v
[14.2 Code review]
    |
    v
[14.3 Test data]
    |
    v
[14.4 Definition of done]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX040]

Learning outcomes

You will (1) write privacy requirements as user stories; (2) include privacy in code review; (3) manage personal data in test environments.

14.1 Privacy stories

In software engineering Zara learns to write requirements as user stories. She adds privacy stories to Pellmore's backlog: as a patient, I want to download my records so that I can check what is held; as a patient, I want my video recordings deleted after thirty days unless I ask otherwise. Each story has acceptance criteria that can be tested. Writing privacy as stories puts it in the same planning process as features, rather than leaving it to a separate document that developers rarely read.

14.2 Code review

Pellmore's code review checklist covers style and tests but not privacy. Zara adds five questions: does this change collect new personal data; is any new data logged; does it send data to a new recipient; does it change retention; and does it affect access checks. Reviewers must answer each question. In the first month the checklist catches a change that would have sent full patient names to a crash reporting service. The example convinces the team that a few targeted questions are worth the extra minute per review.

14.3 Test data

Developers at Pellmore sometimes copied production data into test environments to reproduce bugs. Zara explains that test environments are usually less protected and that copying health data there is a serious risk. She builds a generator that produces realistic synthetic patients with the same structure and edge cases, such as long names and unusual characters. Where production data are truly needed for a bug, a documented request with approval and automatic expiry replaces informal copying. NIST SP 800-188 discusses synthetic data as one de-identification approach.

14.4 Definition of done

Finally Zara proposes changes to the team's definition of done. A feature is done only when its privacy stories pass, the review checklist is completed, the record of processing is updated if data flows change, and the privacy notice is updated if patients would be surprised. The team debates whether this slows delivery. Zara argues that fixing privacy after release is slower and more expensive, and Pellmore's engineering lead agrees to try the definition for one quarter and review the effect on delivery times.

Worked example

Zara writes privacy user stories, adds five privacy questions to code review, replaces production copies with a synthetic data generator and extends the definition of done.

Synthetic case. The backlog and review are synthetic; NIST SP 800-188 is real.

Errors and limits

Checklists become rote; rotate examples and audit samples of reviews.

Exercises

EX040 — Privacy story. Write one privacy user story from the chapter. Rubric: 3 = e.g. as a patient I want recordings deleted after thirty days unless I ask otherwise;; 2 = similar story;; 1 = vague;; 0 = none.
EX041 — Review catch. What did the review checklist catch in its first month? Rubric: 3 = a change sending full names to a crash reporter;; 2 = mentions crash reporting;; 1 = vague;; 0 = none.
EX042 — Synthetic test data. Why replace production copies with generated patients? Rubric: 3 = test environments are less protected; synthetic data avoids exposing health data;; 2 = mentions safety;; 1 = uses masking only;; 0 = none.

Synthesis

Chapter 14 embeds privacy in delivery. Chapter 15 covers security fundamentals.

Continue studying — chapter 14 of 50

← Chapter 13 (draft) · Course chapter index · Chapter 15 (draft) →