Chapter 25 — Data incidents
Lesson map
Lesson 25 published. Map, example, EX073.
flowchart TD
N0["Learning outcomes"]
N1["25.1 What counts"]
N2["25.2 An incident"]
N3["25.3 Containment and fix"]
N4["25.4 Lessons"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX073"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["25.1 What counts"]
N2["25.2 An incident"]
N3["25.3 Containment and fix"]
N4["25.4 Lessons"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX073"]
[Learning outcomes]
|
v
[25.1 What counts]
|
v
[25.2 An incident]
|
v
[25.3 Containment and fix]
|
v
[25.4 Lessons]
|
v
[Worked example] --> [Exercise EX073]
Learning outcomes
You will (1) recognise data incidents; (2) follow an incident procedure; (3) learn from incidents.
25.1 What counts
A data incident is an event that harms data confidentiality, integrity or availability, such as a lost laptop with tenant data, a wrong file sent to a contractor or a failed load leaving reports incomplete. Ravi learns Calder Valley's incident procedure: report immediately to the data protection officer or data manager, contain the problem, assess impact, notify if required and review lessons. He notes that speed matters, because legal notification deadlines may apply. Ravi keeps a printed copy of the procedure beside his desk.
25.2 An incident
Ravi notices that a contractor export sent overnight contained tenants from another contractor's area. He reports it at once. The contractor is asked to delete the file and confirm. Ravi traces the cause to a filter in the export script that used a postcode list which had not been updated after an area boundary change. The data protection officer assesses the risk to tenants and decides whether notification is required under the GDPR. Ravi records each step and its time in the incident log.
25.3 Containment and fix
While the officer assesses, Ravi pauses the export, corrects the filter to use the contractor allocation field rather than postcodes, tests it with synthetic data and resumes exports after the steward approves. He checks the previous week's exports and finds the error began three days earlier. Those contractors are also asked to delete affected files. Each action is recorded with times in the incident log. The officer uses the log to complete the assessment, and the decision on notification is recorded together with its reasons and the date it was made.
25.4 Lessons
The incident review finds that boundary changes were not communicated to the data team. The fix is to add the data team to the change process for contractor areas, and to add an export check comparing each contractor's tenants with its allocation. Ms. Moreau notes that blameless reviews focus on how systems allowed an error rather than on who made it, which encourages people to report incidents quickly in future. Both changes are made within a month, and the export check has caught no further errors since it was added.
Worked example
Ravi reports a misdirected contractor export, traces it to an outdated postcode filter, pauses and fixes the export, finds three earlier affected days and supports a review that adds the data team to boundary changes.
Synthetic case. The incident is synthetic; the GDPR is real.
Errors and limits
Delaying incident reports can miss legal deadlines.
Exercises
- EX073 — Export cause. What caused the misdirected export? Rubric: 3 = an outdated postcode list after a boundary change;; 2 = partly correct;; 1 = vague;; 0 = none.
- EX074 — Filter fix. What did Ravi filter on instead? Rubric: 3 = the contractor allocation field;; 2 = partly correct;; 1 = other;; 0 = none.
- EX075 — Review style. What do blameless reviews focus on? Rubric: 3 = how systems allowed the error;; 2 = partly correct;; 1 = who;; 0 = none.
Continue studying — lesson 25 (chapter 25 of 30)
← Chapter 24 · Course chapter index · Chapter 26 →
Continue to the next authored lesson.