OpenCyber AcademyLesson map
Lesson 21 published. Map, example, EX061.
flowchart TD
N0["Learning outcomes and connection"]
N1["21.1 Incidents as socio-technical systems"]
N2["21.2 The coordination graph"]
N3["21.3 Role ambiguity"]
N4["21.4 Incentives"]
N5["21.5 Handoffs"]
N6["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX061"]
Logical drawing
flowchart LR
N0["Learning outcomes and connection"]
N1["21.1 Incidents as socio-technical systems"]
N2["21.2 The coordination graph"]
N3["21.3 Role ambiguity"]
N4["21.4 Incentives"]
N5["21.5 Handoffs"]
N6["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX061"]
[Learning outcomes and connection]
|
v
[21.1 Incidents as socio-technical systems]
|
v
[21.2 The coordination graph]
|
v
[21.3 Role ambiguity]
|
v
[21.4 Incentives]
|
v
[21.5 Handoffs]
|
v
[Chapter synthesis]
|
v
[Worked example] --> [Exercise EX061]
Learning outcomes and connection
You will be able to (1) model an incident's decision flow as a coordination graph; (2) identify role ambiguity, communication delay and misaligned incentives; (3) analyse handoffs as points of information loss; and (4) propose a testable change to an approval process. Chapter 19 introduced coordination theory; this chapter makes it analytical. Chapter 30 tests these ideas in a multi-team simulation.
21.1 Incidents as socio-technical systems
Technical evidence does not act; people decide. A socio-technical view treats the incident as a system of people, roles, tools and rules whose interactions produce the outcome. Many response failures are coordination failures: the right information existed but did not reach the person who could act, or the person who could act lacked authority.
In the pharmacy-server case, the evidence at 14:05 was enough to request isolation; the delay came from who could decide and when they were available. Reading the case only as a technical problem would miss that the fix lies in roles and options.
21.2 The coordination graph
Draw vertices for roles (SOC analyst, incident lead, service owner, IT operations, communications, legal) and directed edges for information flows and approvals, annotated with typical delays. The critical path to a decision is the longest chain of required approvals and information transfers; reducing it speeds response more than working faster at any single node.
In the pharmacy-server example, drawing the graph shows the critical path of 87 minutes and that 70 of them were spent waiting for the incident lead. Analysing faster in the SOC would not have shortened that path; a deputy who could decide would.
21.3 Role ambiguity
When it is unclear who decides, decisions stall or are made twice. Typical signals: "I thought you were going to…", parallel conversations in different channels, duplicated actions. A RACI-style assignment (Responsible, Accountable, Consulted, Informed) for key decisions — containment of production systems, external communication, law-enforcement contact — reduces ambiguity, but only if rehearsed.
In the pharmacy-server case, the SOC, the service owner and the incident lead each assumed someone else would break the deadlock; no deputy existed. The proposed change names a deputy and a 15-minute limit, which removes the question of who decides rather than asking people to try harder.
21.4 Incentives
People optimize what they are measured on. A service owner measured on uptime resists containment that causes downtime; a SOC measured on ticket closure may close cases early. These are rational responses to incentives, not character flaws. Good designs make the trade-off explicit and give the decision to a role accountable for the whole risk.
The pharmacy service owner was measured on order throughput, so refusing isolation during afternoon orders was rational. The SOC, measured on detection, pushed for isolation. Both positions made sense locally; the design flaw was that nobody accountable for the whole risk was available to weigh them.
21.5 Handoffs
Every handoff (shift change, SOC to IT, internal to vendor) can lose context. Research in healthcare on structured handover informs practice here: a minimum content standard and a read-back reduce omissions. Chapter 26 of the technologist book teaches operational handoffs.
In the pharmacy-server case, the SOC's escalation to the incident lead went by chat while the lead was in a meeting, so the message waited. A handoff standard would specify a channel that reaches the person, the minimum content of the request, and confirmation that it was received, so that a decision request cannot sit unread for over an hour.
21.6 Worked example (synthetic): SOC versus service owner
Fictional. At 14:05 Harbourline's SOC sees signs that the pharmacy ordering server may be running an unknown remote-access tool. The SOC wants to isolate the server. The pharmacy service owner refuses: afternoon orders are being processed and isolation stops them. The incident lead is in a meeting; the decision waits until 15:20.
Coordination graph: SOC → (request) → service owner (refuses) → SOC → (escalation by chat) → incident lead (unavailable 14:10–15:15) → decision 15:20 → IT operations isolates at 15:32. Critical path: 87 minutes, of which 70 are waiting for the incident lead.
Analysis: role ambiguity (no deputy for the incident lead); incentive conflict (owner measured on order throughput); missing option (no partial containment, such as blocking outbound traffic except to the supplier's ordering endpoint).
Testable change: "For severity-2 or higher containment disputes, the duty incident lead or a named deputy must decide within 15 minutes; an approved partial-containment option (egress allow-list) is pre-defined for the pharmacy server." Test: run two tabletop exercises before and after the change with the same scenario structure and measure time from dispute to decision and whether the partial option is used. This is a measurable process change, not a blame assignment.
21.7 Common errors and limits
- Explaining delays by individual failings when structure caused them.
- Adding approvers in response to every incident, lengthening the critical path.
- RACI charts that are never exercised.
-
Simulation results may not reflect real-incident stress; validate cautiously.
-
Measuring only how quickly the SOC acted, while the waiting time sat elsewhere in the graph.
- Assuming a named deputy will decide when the rule has never been exercised.
- Proposing a process change without a way to test whether it shortened the critical path. Simulations help, but real stress differs.
Exercises — chapter 21
Attempt each exercise before opening the worked results. Every case, organization, person, address and number in an exercise is synthetic unless a cited public source is named.
EX061 — Draw the graph. Steps: draw the §21.6 coordination graph with times and mark the critical path. Rubric: 3 = all roles and edges, delays annotated, critical path correct; 2 = minor omission; 1 = no times; 0 = none.
EX062 — RACI for containment. Steps: write a RACI row for "isolate a production clinical server". Rubric: 3 = one Accountable role (incident lead or deputy), Responsible (IT operations), Consulted (service owner, clinical safety), Informed (communications, management); deputy named; 2 = multiple accountable; 1 = incomplete; 0 = none.
EX063 — Evaluate the change. Steps: list two ways the proposed 15-minute rule could fail and how the tabletop test would detect them. Rubric: 3 = deputy also unavailable, owner bypasses decision, partial containment not technically ready; detection through injects and observer notes; 2 = one; 1 = vague; 0 = none.
Chapter synthesis
Model incidents as coordination among roles with incentives; find the critical path, remove ambiguity with one accountable decider and rehearsed deputies, design partial options, and test process changes as measurable hypotheses.