Lesson map
Lesson 28 published. Map, example, EX082.
flowchart TD
N0["Learning outcomes"]
N1["28.1 The incident"]
N2["28.2 Blameless review"]
N3["28.3 Control changes"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX082"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["28.1 The incident"]
N2["28.2 Blameless review"]
N3["28.3 Control changes"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX082"]
[Learning outcomes]
|
v
[28.1 The incident]
|
v
[28.2 Blameless review]
|
v
[28.3 Control changes]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX082]
Learning outcomes
You will (1) analyse an incident for control failures; (2) run a blameless review; (3) turn lessons into control changes.
28.1 The incident
A synthetic incident occurs: a housing officer emails a spreadsheet with tenants' arrears details to an external address with a similar name to a council contact. The recipient reports it, and the file is deleted. Sofia helps the data protection lead assess whether the breach must be reported to the regulator and whether tenants should be told, following Elmfield's procedure. The assessment considers the sensitivity of the data and the recipient's confirmation of deletion. The recipient's confirmed deletion lowers the risk to tenants but does not by itself remove the need for an assessment.
28.2 Blameless review
Sofia facilitates a blameless review. The aim is to understand how the system allowed the error, not to punish the officer. They find that email auto-completed the wrong address, that spreadsheets with arrears data were routinely emailed rather than shared through the housing system and that no warning appeared for external recipients. Sofia learns that blameless reviews encourage honest accounts, which reveal design problems. Blaming individuals tends to hide information and leaves the same conditions in place. The auto-completed address and the missing external warning are system conditions that would catch any housing officer, not just this one.
28.3 Control changes
The review leads to changes: an external recipient warning in email, a rule that arrears data are shared through secure links with expiry, and a short reminder in team meetings. Sofia updates the risk register, raising the likelihood estimate for misdirected data and recording the new controls. She learns that incidents are evidence about control effectiveness and should feed back into risk assessment, closing the loop between operations and governance. Raising the likelihood estimate for misdirected data reflects that the incident showed the risk was more likely than scored earlier.
Worked example
Sofia supports breach assessment, runs a blameless review finding three system causes and feeds changes into the register.
Synthetic case. The incident is synthetic.
Errors and limits
Blameless reviews still need accountability for repeated negligence. Warnings cause fatigue.
Exercises
- EX082 — Review aim. What is the aim of a blameless review?
Show marking criteria
Rubric: 3 = understand how the system allowed the error;; 2 = system;; 1 = punishment;; 0 = none. - EX083 — System causes. Name two system causes found.
Show marking criteria
Rubric: 3 = auto-complete and routine emailing of arrears spreadsheets;; 2 = causes;; 1 = vague;; 0 = none. - EX084 — Register update. How did Sofia update the register?
Show marking criteria
Rubric: 3 = raised likelihood for misdirected data and recorded new controls;; 2 = update;; 1 = vague;; 0 = none.
Synthesis
Blameless failure analysis turns incidents into better controls and better risk estimates.
Continue studying — chapter 28 of 40
← Chapter 27 (draft) · Course chapter index · Chapter 29 (draft) →