Chapter 20 — Security governance, risk and compliance: foundational cases
Lesson map
Lesson 20 published. Map, example, EX058.
flowchart TD
N0["Learning outcomes"]
N1["20.1 Reading cases"]
N2["20.2 Lessons for Elmfield"]
N3["20.3 Root causes"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX058"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["20.1 Reading cases"]
N2["20.2 Lessons for Elmfield"]
N3["20.3 Root causes"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX058"]
[Learning outcomes]
|
v
[20.1 Reading cases]
|
v
[20.2 Lessons for Elmfield]
|
v
[20.3 Root causes]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX058]
Learning outcomes
You will (1) analyse published governance cases; (2) extract lessons for a small organisation; (3) distinguish root causes from symptoms.
20.1 Reading cases
Sofia studies governance lessons from public reports. GAO-21-105263, a 2021 testimony by the United States Government Accountability Office, describes weaknesses in the federal oversight of pipeline security after the ransomware attack on Colonial Pipeline's business systems, including risk assessments that lacked cybersecurity information and an incident protocol not updated since 2010. She reads such reports for patterns rather than blame: incomplete risk information, stale response plans and slow follow-up on recommendations recur. Public audit reports are valuable teaching material because they rest on evidence, though their settings may differ from Elmfield's.
20.2 Lessons for Elmfield
From the cases, Sofia draws lessons scaled for Elmfield: name one person accountable for the security programme, write a short risk appetite statement approved by the board, keep a register reviewed quarterly and report progress to the board twice a year. She avoids copying large-organisation structures that Elmfield could not sustain. She learns that good lessons are about principles, such as clear accountability, rather than specific committees or tools. A twice-yearly board report, for example, suits a board that meets only a few times a year.
20.3 Root causes
Sofia practises separating symptoms from causes. In a synthetic Elmfield incident, a contractor's account was used after the contract ended. The symptom was an active account. The root cause was that no one owned contractor offboarding, since contracts were managed by the repairs team while accounts were managed by IT. She recommends assigning ownership and linking contract end dates to account expiry. Fixing causes prevents repeats; fixing symptoms alone does not. Linking contract end dates to account expiry also closes the same gap for any future contractor.
Worked example
Sofia reads public audit cases for patterns, draws proportionate lessons for Elmfield and traces a contractor account incident to missing ownership.
Synthetic case. The Elmfield incident is synthetic; GAO-21-105263 is real.
Errors and limits
Cases from large organisations may not transfer. Root cause analysis can stop too early.
Exercises
- EX058 — GAO weaknesses. Which two weaknesses did GAO-21-105263 describe? Rubric: 3 = risk assessments lacking cyber information and an outdated incident protocol;; 2 = two;; 1 = vague;; 0 = none.
- EX059 — Board reporting. How often should progress be reported to Elmfield's board? Rubric: 3 = twice a year;; 2 = twice;; 1 = vague;; 0 = none.
- EX060 — Contractor root cause. What was the root cause of the contractor account incident? Rubric: 3 = no one owned contractor offboarding;; 2 = ownership;; 1 = active account;; 0 = none.
Synthesis
Cases teach principles; root causes, not symptoms, must be fixed.
Continue studying — chapter 20 of 40
← Chapter 19 (draft) · Course chapter index · Chapter 21 (draft) →