Chapter 20 — Privacy and data protection: troubleshooting
Lesson map
Lesson 20 published. Map, example, EX058.
flowchart TD
N0["Learning outcomes"]
N1["20.1 A failure"]
N2["20.2 Diagnosis"]
N3["20.3 Root cause"]
N4["20.4 Prevention"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX058"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["20.1 A failure"]
N2["20.2 Diagnosis"]
N3["20.3 Root cause"]
N4["20.4 Prevention"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX058"]
[Learning outcomes]
|
v
[20.1 A failure]
|
v
[20.2 Diagnosis]
|
v
[20.3 Root cause]
|
v
[20.4 Prevention]
|
v
[Worked example] --> [Exercise EX058]
Learning outcomes
You will (1) diagnose privacy failures; (2) find root causes; (3) prevent recurrence.
20.1 A failure
A member receives a marketing email after withdrawing consent. Aisha investigates. The member complains to reception, and the complaint reaches the data protection officer, who asks Aisha to find out what went wrong. The member had withdrawn consent through the app nine days earlier. A complaint like this can damage trust and, if repeated, could lead to a complaint to the supervisory authority, so it deserves careful investigation. Aisha starts by collecting the app record, the email platform log and the job history for the nine days.
20.2 Diagnosis
She finds the withdrawal recorded in the app but not synchronised to the email platform because a nightly job failed for a week. She follows the withdrawal from the app database to the marketing platform. The app recorded the change correctly with a timestamp. The nightly job that copies preference changes to the email platform had logged errors for seven nights. During that week, 214 withdrawals in the synthetic test copy were not transferred, so the problem affected many members, not just one.
20.3 Root cause
The job failed after a password change and had no failure alert. She adds an alert and a weekly reconciliation. IT had rotated a service password as part of good security practice but did not update the job's stored credential. The job failed quietly because its error messages went to a mailbox nobody checked. The real cause was therefore a missing alert and missing ownership, not the password change itself, which was the right thing to do. Blaming IT would have fixed nothing.
20.4 Prevention
She checks other jobs that carry privacy choices and adds alerts. Mr. Reilly notes that withdrawal must be as easy as giving consent, and must actually work. Aisha lists every job that carries privacy choices: marketing preferences, heart-rate sharing settings, account deletions and vendor data deletions. Each now has an owner and an alert on failure. The weekly reconciliation compares withdrawals in the app with suppressions in the email platform and reports any differences. The affected members receive an apology and confirmation of their choice.
Worked example
Aisha traces an unwanted email to a failed synchronisation job, adds alerts and reconciliation, and checks similar jobs.
Synthetic case. The failure is synthetic; GDPR Article 7(3) is real.
Errors and limits
Fixing the symptom alone invites recurrence.
Exercises
- EX058 — Cause. Why did the member get an email? Rubric: 3 = sync job failed after a password change;; 2 = mentions job;; 1 = vague;; 0 = none.
- EX059 — Fix. What fixes did Aisha add? Rubric: 3 = an alert and weekly reconciliation;; 2 = one;; 1 = vague;; 0 = none.
- EX060 — Principle. What does Article 7(3) require? Rubric: 3 = withdrawal as easy as giving consent;; 2 = partly correct;; 1 = vague;; 0 = none.
Continue studying — lesson 20 (chapter 20 of 30)
← Chapter 19 · Course chapter index · Chapter 21 →
Continue to the next authored lesson.