◇ OpenCyber Academy
Technical · Chapter 13 · English

Chapter 13 — Privacy and data protection: troubleshooting

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 13 — Privacy and data protection: troubleshooting

Lesson map

Lesson 13 published. Map, example, EX049.

flowchart TD
  N0["Learning outcomes"]
  N1["13.1 The symptom"]
  N2["13.2 Following the data"]
  N3["13.3 Root cause"]
  N4["13.4 Preventing recurrence"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX049"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["13.1 The symptom"]
  N2["13.2 Following the data"]
  N3["13.3 Root cause"]
  N4["13.4 Preventing recurrence"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX049"]
[Learning outcomes]
    |
    v
[13.1 The symptom]
    |
    v
[13.2 Following the data]
    |
    v
[13.3 Root cause]
    |
    v
[13.4 Preventing recurrence]
    |
    v
[Worked example] --> [Exercise EX049]

Learning outcomes

You will (1) diagnose a privacy fault methodically; (2) find the root cause; (3) prevent recurrence.

13.1 The symptom

A patient complains that she received a whitening offer by email although she never agreed to marketing. The data protection officer asks Leila to investigate technically. Leila starts by writing down exactly what is known: the patient's synthetic test equivalent, the date of the email, the campaign name and the patient's current marketing setting, which is off. She resists guessing at causes before collecting facts, because early guesses tend to focus attention on the wrong system and waste time. Facts first, theories later.

13.2 Following the data

Leila traces how the campaign list was built. The marketing platform receives a nightly export from the practice-management system of patients with marketing consent. She compares the export from the campaign date with the consent table and finds that the export query used the field for appointment reminders instead of the field for marketing consent. Every patient who accepted reminders, about four times as many people as had agreed to marketing, was included in the campaign list for that night. The affected list is reconstructed.

13.3 Root cause

The query had been edited two weeks earlier when the practice-management vendor renamed several fields during an upgrade. The person updating the query chose the wrong field because both had similar names: contact_ok and marketing_ok. There was no test to check that the export contained only consenting patients. Leila identifies three causes: confusing field names, no review of the query change and no automated check. She notes that blaming the individual would leave all three causes in place. The rename was undocumented.

13.4 Preventing recurrence

Leila adds an automated check that compares each export with the consent table before it is sent and stops the export if any patient lacks marketing consent. Query changes now require review by a second person. The vendor is asked to document field meanings clearly. Marlow suppresses marketing to all affected patients, sends an apology and records the event as a breach of its own rules, with the data protection officer deciding whether notification is required under Article 33. The check also runs for SMS lists.

Worked example

Leila traces an unwanted marketing email to an export query that used the reminder field after a vendor renamed fields, adds an automated consent check and second-person review.

Synthetic case. The fault is synthetic; GDPR Article 33 is real.

Errors and limits

A quick fix to the query alone would not stop the next similar mistake.

Exercises

Continue studying — lesson 13 (chapter 13 of 18)

← Chapter 12 · Course chapter index · Chapter 14 →

Continue to the next authored lesson.