Chapter 10 — Incident response service model and operating roles
Lesson map
Lesson 10 published. Map, example, EX028.
flowchart TD
N0["Learning outcomes and connection"]
N1["10.1 Response as a service"]
N2["10.2 Charter elements"]
N3["10.3 Roles"]
N4["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX028"]
Logical drawing
flowchart LR
N0["Learning outcomes and connection"]
N1["10.1 Response as a service"]
N2["10.2 Charter elements"]
N3["10.3 Roles"]
N4["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX028"]
[Learning outcomes and connection]
|
v
[10.1 Response as a service]
|
v
[10.2 Charter elements]
|
v
[10.3 Roles]
|
v
[Chapter synthesis]
|
v
[Worked example] --> [Exercise EX028]
Learning outcomes and connection
You will be able to (1) define Fernmoor's incident response service with its customers, scope, authority and service levels; (2) assign operating roles with clear handoffs; and (3) write the service charter that later chapters implement. This is the turning point of the course: from now on you are building and running a service, not studying components.
10.1 Response as a service
The FIRST CSIRT Services Framework describes services a response team may offer: information security event management, incident management, vulnerability management, situational awareness and knowledge transfer. A technologist chooses which services Fernmoor will provide now, documents them in a service catalog entry and defines how customers request them. ISO/IEC 27035 similarly describes planning and preparing an incident management capability before incidents occur. Fernmoor's charter starts small: three technologists and a shared on-call rota, with service levels and pre-approved actions written down.
10.2 Charter elements
Mission and scope (which systems, which organizations — does the service cover the water utility's operational technology? Fernmoor decided: not yet, refer to the OT team); customers (city departments, residents via the contact centre); authority (what the service may do without asking — for example isolate a workstation — and what needs the system owner or executive approval); hours (business hours with on-call out of hours); service levels (time to acknowledge, time to triage by severity); interfaces (service desk, IT operations, legal, privacy, communications, suppliers); and review cadence.
10.3 Roles
- Duty analyst: watches the queue, triages, opens cases, performs runbook steps.
- Incident lead: owns a case at severity S1–S2, coordinates, decides within authority, escalates.
- Technical responders: platform, identity, network, application staff who execute changes.
- Communications and liaison: internal updates, resident communication with the communications office, supplier contact.
- Approver: the system owner or on-call manager for actions beyond the duty analyst's authority.
- Scribe: keeps the case record current during major incidents.
One person may hold several roles in a small team, but a case always has exactly one named lead. The Google SRE book's chapter on managing incidents gives a practical model of separating the incident commander from the people doing hands-on work.
10.4 Worked example (synthetic): Fernmoor's first charter
Fictional. The Response Desk is three technologists plus an on-call rota shared with IT operations. Service levels: acknowledge S1 within 15 minutes at any hour, S2 within 30 minutes in hours and 60 out of hours; triage within 60 minutes of acknowledgment. Pre-approved actions for the duty analyst: disable a user account, revoke sessions, isolate a single workstation, block a single external address at the edge. Actions needing the system owner: isolate a server, disable a public service. Actions needing the director: notify regulators or residents (with counsel and the privacy officer). Review: monthly service report; charter review yearly or after any S1.
10.5 Common errors and limits
- A charter that grants no authority, so every action waits for a meeting.
- Service levels without the staffing to meet them.
- Roles named but not trained or rostered.
- Scope ambiguity discovered during a crisis (OT, suppliers, residents' data held by a contractor).
Fernmoor's charter answers each risk explicitly. The duty analyst may disable an account or isolate a workstation without waiting, service levels were set with the on-call rota in mind, and OT scope was formally excluded with a referral procedure rather than left vague. Training for each named role is scheduled in the sustainment calendar, so roles are practised before they are needed.
Exercises — chapter 10
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.
EX028 — Authority table. Steps: build a table of eight response actions and who may authorize each at Fernmoor. Rubric: 3 = eight actions graded duty analyst/system owner/director with reasons; 2 = six; 1 = unstructured; 0 = none.
EX029 — Role card. Steps: write a one-paragraph role card for the incident lead. Rubric: 3 = responsibilities, authority limits, handoff duty, escalation triggers, what they must not do (hands-on work in S1); 2 = missing two; 1 = vague; 0 = none.
EX030 — Scope decision. Steps: argue whether the service should cover the water utility's OT systems in year one. Rubric: 3 = considers skills, tooling, safety, interface with OT team, phased approach with referral path; 2 = one-sided; 1 = assertion; 0 = none.
Chapter synthesis
Define response as a service: scope, customers, authority, hours, service levels, interfaces and review. Assign roles with one named lead per case and pre-approved actions that let the service act quickly within limits.
Continue studying — chapter 10 of 30
← Chapter 09 · Course chapter index · Chapter 11 →
Continue to the next authored lesson.