Chapter 2 — Governance and authority
Lesson map
Lesson 02 published. Map, example, EX006.
flowchart TD
N0["Learning outcomes"]
N1["2.1 Why authority matters"]
N2["2.2 The charter"]
N3["2.3 Pre-approved actions"]
N4["2.4 Escalation"]
N5["2.5 Reporting"]
N6["2.6 Privacy"]
N7["Reviewing the charter"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX006"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["2.1 Why authority matters"]
N2["2.2 The charter"]
N3["2.3 Pre-approved actions"]
N4["2.4 Escalation"]
N5["2.5 Reporting"]
N6["2.6 Privacy"]
N7["Reviewing the charter"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX006"]
[Learning outcomes]
|
v
[2.1 Why authority matters]
|
v
[2.2 The charter]
|
v
[2.3 Pre-approved actions]
|
v
[2.4 Escalation]
|
v
[2.5 Reporting]
|
v
[2.6 Privacy]
|
v
[Reviewing the charter]
|
v
[Worked example] --> [Exercise EX006]
Learning outcomes
You will (1) define who owns security operations decisions; (2) write a SOC charter; (3) agree pre-approved actions; (4) link SOC reporting to the board.
2.1 Why authority matters
In March, even if someone had seen the alert, nobody had authority to disable an IT technician's account at night. Authority must be written down before it is needed. Without authority, an analyst who sees an attack at night can only send an email and wait. In March, the attacker had Domain Admins rights for fifteen minutes and sent out 1.4 GB of design files before anyone acted. Priya's charter answers this by deciding in advance who may act, on what, and when, so a night-time decision does not depend on finding a manager. The managing director's signature makes that authority clear to the provider and to staff.
2.2 The charter
Priya writes a two-page charter: mission, scope, services, the authority to take pre-approved actions, escalation paths, and how the SOC reports. The managing director signs it. Two pages is short enough for the managing director and the provider to read in full. Each part answers a question that was unclear in March: what the SOC protects, what it does, who may act, who is called and who is told afterwards. The provider's service agreement refers to the charter for authority, so both documents say the same thing. Priya reviews the charter each year, and any change needs the managing director's signature again.
2.3 Pre-approved actions
The provider may disable any user account, block an address at the firewall and isolate an office PC without calling Fenwick first. Isolating servers needs Priya or her deputy, because production could stop; the first draft gave factory PCs the same rule. These actions were chosen because they are quick, reversible and would have limited March: disabling j.harper's account would have stopped the attacker. The charter workshop replaced that draft rule for factory supervisory PCs: the provider phones the shift supervisor before isolating one, unless ransomware activity is seen, in which case it isolates first and calls immediately after. Each action taken is recorded and reported the next morning.
2.4 Escalation
Severity levels decide who is called: medium goes to the morning queue, high wakes the on-call IT person, critical wakes Priya and the operations director. Linking severity to the people called keeps night calls for alerts that need them. Medium alerts can wait for Tom in the morning; a high alert needs someone from IT who can act on systems; a critical alert needs the people who can make business decisions, such as stopping production. The provider holds a call list with deputies for each role, and Priya updates it when staff change or holidays begin.
2.5 Reporting
A monthly one-page report goes to the board's risk committee: incidents, coverage, open risks, decisions needed. This places the SOC within CSF 2.0's Govern function. The report gives the risk committee what it needs to make decisions without technical detail: what happened, how well the SOC sees Fenwick's systems, which risks remain and what the committee is asked to decide. Placing the SOC in the Govern function shows that it reports to the board and is directed by it, rather than running as a technical project. The committee's decisions are recorded in its minutes and reported back to the provider and Tom.
2.6 Privacy
Monitoring staff accounts raises privacy questions. The charter states monitoring is for security only, and HR and the staff council review it. Staff accounts are monitored because March began with one, but monitoring could be misused to watch performance or private activity. The charter limits use of monitoring data to security, names who may see it, and requires HR approval before any data is used in a disciplinary matter. The staff council reviews the arrangement each year and reports its findings to the managing director. Priya publishes a short notice to staff explaining what is monitored and why.
Reviewing the charter
The charter is reviewed every year and after any major incident. Changes need the managing director's signature again, and the provider receives the new version the same week so its analysts act on current authority.
Worked example
In the charter workshop, the operations director objects to the provider isolating factory supervisory PCs. They agree: the provider may isolate them only after phoning the shift supervisor, unless ransomware activity is seen, in which case it isolates first and calls immediately after.
Synthetic case. The charter is invented.
Errors and limits
A charter that nobody reads is useless; brief every manager and the provider on it.
Exercises
- EX006 — March authority gap. What authority gap existed in March? Rubric: 3 = nobody authorised to disable a technician's account at night; 2 = partial; 1 = vague; 0 = none.
- EX007 — Charter contents. List four charter sections. Rubric: 3 = mission, scope, services, authority, escalation, reporting (four); 2 = two; 1 = one; 0 = none.
- EX008 — Provider actions. Which actions can the provider take alone? Rubric: 3 = disable accounts, block addresses, isolate office PCs; 2 = two; 1 = one; 0 = none.
- EX009 — Factory compromise. What was agreed for factory PCs? Rubric: 3 = call shift supervisor first, unless ransomware: isolate then call; 2 = partial; 1 = vague; 0 = none.
- EX010 — Privacy safeguard. How is staff privacy addressed? Rubric: 3 = security-only purpose; HR and staff council review; 2 = partial; 1 = vague; 0 = none.
Synthesis
Write authority down, pre-approve safe actions and report to the board.
Continue studying — chapter 02 of 12
← Chapter 01 (draft) · Course chapter index · Chapter 03 (draft) →