Chapter 29 — Response operations, roles and measurement
Lesson map
Lesson 29 published. Map, example, EX085.
flowchart TD
N0["Learning outcomes and connection"]
N1["29.1 Roles"]
N2["29.2 Queues and service objectives"]
N3["29.3 Metric validity"]
N4["29.4 Review cycle"]
N5["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX085"]
Logical drawing
flowchart LR
N0["Learning outcomes and connection"]
N1["29.1 Roles"]
N2["29.2 Queues and service objectives"]
N3["29.3 Metric validity"]
N4["29.4 Review cycle"]
N5["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX085"]
[Learning outcomes and connection]
|
v
[29.1 Roles]
|
v
[29.2 Queues and service objectives]
|
v
[29.3 Metric validity]
|
v
[29.4 Review cycle]
|
v
[Chapter synthesis]
|
v
[Worked example] --> [Exercise EX085]
Learning outcomes and connection
You will be able to (1) define response roles and their responsibilities; (2) manage a case queue with service objectives; (3) assess whether operational metrics are valid; and (4) recommend a review cadence. Chapters 15 and 21 gave you measurement and coordination; this chapter combines them in running a response function. Chapter 30 exercises the operation in a simulation.
29.1 Roles
Typical roles: triage analyst (assess and route), incident handler (investigate and coordinate technical work), incident lead/commander (decide and coordinate across teams), service owner (accept changes to their service), communications lead, and scribe (record decisions). In small organizations one person holds several roles, but the roles — especially "who decides" — should still be named per incident. The FIRST CSIRT Services Framework describes the services a team offers, which helps decide which roles are needed.
At Harbourline, with a two-person IT team, one person may be both handler and scribe.
29.2 Queues and service objectives
A service-level objective (SLO) states a target such as "90% of severity-2 cases receive first analyst action within 30 minutes". Queue health depends on arrival rate, handling time and staffing; when arrival exceeds capacity, waiting times grow quickly. Track backlog age, not only counts.
Lab 29 shows the pattern: as monthly volume rose from 100 to 122 cases, the mean wait for severity-3 cases grew from six to nine hours, a sign that capacity is being approached before any objective is formally breached. Watching backlog age catches that earlier than counting open tickets.
29.3 Metric validity
A metric is valid if it measures what it claims and cannot be easily improved without improving the underlying reality. "Cases closed per analyst" rewards early closure; "time to first action" can be gamed by a quick placeholder note. Pair metrics (speed with quality review), and watch for definition drift — for example, severity labels changing over time, so that "severity-1 cases" in Q1 and Q3 are not the same population.
Lab 29 is a case of definition drift in practice: initial labels changed meaning while final labels stayed stable.
29.4 Review cycle
A cadence of reviews: daily queue review, weekly case-quality sampling, monthly metric review with trends and data-quality checks, quarterly review of corrective actions and capability gaps. Each review needs inputs, an owner and outputs (decisions, actions).
For Harbourline, the weekly sample might include every case upgraded to severity 1, since Lab 29 shows upgrades rising from none in January to eight in March. The monthly review would check that both initial and final severity are reported, and the quarterly review would ask whether staffing matches the arrival rate. Write each review's output as decisions and actions with owners, so the next review can check what happened to them.
29.5 Worked example and lab (synthetic): changing severity labels
A quarter of Harbourline cases shows "severity-1 cases fell from 12 in January to 4 in March". Save as lab29.py.
# Lab 29 - workload and severity-label drift in a synthetic quarter of cases (stdlib only)
from collections import Counter
# (month, initial_severity, final_severity, hours_to_first_action)
CASES = (
[("Jan", 1, 1, 0.4)] * 12 + [("Jan", 2, 2, 1.0)] * 30 + [("Jan", 3, 3, 6.0)] * 58 +
[("Feb", 1, 1, 0.5)] * 7 + [("Feb", 2, 1, 1.2)] * 3 + [("Feb", 2, 2, 1.1)] * 35 + [("Feb", 3, 3, 7.0)] * 60 +
[("Mar", 1, 1, 0.6)] * 4 + [("Mar", 2, 1, 1.5)] * 8 + [("Mar", 2, 2, 1.4)] * 40 + [("Mar", 3, 3, 9.0)] * 70
)
for m in ("Jan", "Feb", "Mar"):
rows = [c for c in CASES if c[0] == m]
init = Counter(c[1] for c in rows)
final = Counter(c[2] for c in rows)
s3 = [c[3] for c in rows if c[2] == 3]
print(f"{m}: total {len(rows)} sev1 initial {init[1]} final {final[1]} "
f"upgraded to sev1 {sum(1 for c in rows if c[1] == 2 and c[2] == 1)} "
f"sev3 mean hours to first action {sum(s3)/len(s3):.1f}")
Expected output:
Jan: total 100 sev1 initial 12 final 12 upgraded to sev1 0 sev3 mean hours to first action 6.0
Feb: total 105 sev1 initial 7 final 10 upgraded to sev1 3 sev3 mean hours to first action 7.0
Mar: total 122 sev1 initial 4 final 12 upgraded to sev1 8 sev3 mean hours to first action 9.0
Interpretation: the "fall" in severity-1 is an artefact of counting initial labels. Final severity-1 counts are stable (12, 10, 12), but more cases are initially under-classified and upgraded later (0 → 3 → 8) — a triage-quality signal, not an improvement. Meanwhile total volume rose 22% and severity-3 waiting time grew from 6 to 9 hours, suggesting the queue is approaching capacity. Recommendations: report both initial and final severity; track the upgrade rate as a quality metric; review staffing against the arrival rate; sample upgraded cases weekly to learn why they were under-classified.
29.6 Common errors and limits
- Metrics that reward closing rather than resolving.
- Comparing periods across label or definition changes.
- Reviews without owners or outputs.
-
Synthetic data here is constructed to show the effect; real data will be noisier and need intervals (Chapter 12).
-
Reporting the count of initial severity labels as if it described the severity of incidents, as the January to March claim did.
- Watching averages while backlog age grows in one severity band.
- Changing a metric's definition without restating earlier periods or noting the break.
Exercises — chapter 29
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.
EX085 — Run and brief. Steps: run Lab 29 and write a five-line brief for the security manager. Rubric: 3 = explains label artefact, upgrade trend, volume and waiting time, with recommendations; 2 = misses one; 1 = repeats the original claim; 0 = none.
EX086 — Pair the metrics. Steps: propose a quality metric to pair with "time to first action" and say how it is measured. Rubric: 3 = e.g., share of sampled cases whose first action was substantive and correctly classified, scored by a second reviewer weekly; 2 = metric without method; 1 = another speed metric; 0 = none.
EX087 — Review cadence. Steps: write a cadence table (daily, weekly, monthly, quarterly) with inputs, owner and outputs. Rubric: 3 = all four with concrete items; 2 = three; 1 = list only; 0 = none.
Chapter synthesis
Name roles per incident, manage queues by backlog age and capacity, pair speed metrics with quality metrics, watch for definition drift, and run a review cadence in which every meeting has inputs, an owner and decisions.
Continue studying — chapter 29 of 40
← Chapter 28 · Course chapter index · Chapter 30 →
Continue to the next authored lesson.