Chapter 21 — Integrate response with service management
Lesson map
Lesson 21 published. Map, example, EX061.
flowchart TD
N0["Learning outcomes and connection"]
N1["21.1 Where the processes meet"]
N2["21.2 Emergency change"]
N3["21.3 Confidentiality"]
N4["21.4 On-call integration"]
N5["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX061"]
Logical drawing
flowchart LR
N0["Learning outcomes and connection"]
N1["21.1 Where the processes meet"]
N2["21.2 Emergency change"]
N3["21.3 Confidentiality"]
N4["21.4 On-call integration"]
N5["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX061"]
[Learning outcomes and connection]
|
v
[21.1 Where the processes meet]
|
v
[21.2 Emergency change]
|
v
[21.3 Confidentiality]
|
v
[21.4 On-call integration]
|
v
[Chapter synthesis]
|
v
[Worked example] --> [Exercise EX061]
Learning outcomes and connection
You will be able to (1) connect security incidents to IT service-management processes for incidents, problems, changes and configuration; (2) design an emergency change path for containment; and (3) prevent the two common failures — security cases lost in the IT queue, and security changes that break services. Chapter 17 placed the case tool inside the ITSM platform; this chapter integrates the processes.
21.1 Where the processes meet
IT incident management restores normal service; security incident response also investigates, preserves evidence and may need confidentiality. Problem management finds root causes; change management controls modifications; the configuration management database (CMDB) holds the inventory (Chapter 11). Frameworks such as ITIL describe these practices; ISO/IEC 20000-1 specifies requirements for a service-management system. The integration points: routing (an IT ticket that looks like security becomes a security case, restricted), linking (outages caused by a security incident link both records), changes (containment and remediation are changes), and problems (recurring security causes become problems with owners).
21.2 Emergency change
Containment cannot wait for a weekly change board. Define a security emergency change: pre-approved standard changes for the actions in Chapter 18 (logged after the fact), and an emergency change path for others with a named approver available at any hour, a minimum record (what, why, risk, rollback) and a retrospective review at the next board. The goal is speed with accountability. During the ransomware outage, isolating fs-01 went through this path as emergency change CHG-3301, approved by the on-call infrastructure manager at 06:31.
21.3 Confidentiality
Security cases may involve staff misconduct, personal data or attacker monitoring of IT tickets. Use restricted record types; keep sensitive details out of broadly visible change titles ("Rotate credentials for service X" rather than "Attacker has svc-patch password"). In the ransomware outage, the service desk saw IT major incident INC-8812 with neutral wording, while the investigation details stayed in the restricted security case FCS-260. Staff could follow the outage without learning anything that would help an attacker watching the tickets. The problem record about the shared admin credential was worded with the same care.
21.4 On-call integration
The response on-call rota should live in the same paging system as IT operations, with escalation if unacknowledged. Chapter 9's lab showed out-of-hours triage delays; Fernmoor's fix was paging S1–S2 to the response on-call through the IT paging tool with a 15-minute escalation to the deputy. The ransomware outage tested this arrangement: the response on-call was paged by the ITSM rule and acknowledged at 06:16, six minutes after the service desk logged the call. The escalation to the deputy was not needed that night, but it is checked during each exercise. Both on-call rotas are visible to the service desk, so callers know who is responding.
21.5 Worked example (synthetic): linking a ransomware outage
Fictional. At 06:10 the service desk logs "billing system slow, files renamed". The ITSM rule matches the keywords "renamed" and "ransom" and routes a restricted security case, paging the response on-call (acknowledged 06:16). Records created and linked: security case FCS-260 (S1), IT major incident INC-8812 for the billing outage (visible to service desk, with neutral wording), emergency change CHG-3301 to isolate fs-01 (approved by the on-call infrastructure manager at 06:31), and later problem PRB-140 "shared admin credential across file servers". Status updates to the service desk came from INC-8812; investigation details stayed in FCS-260.
21.6 Common errors and limits
- Security cases closed by IT once the service is restored, before investigation ends.
- Emergency changes without retrospective review.
- Sensitive details in broadly visible tickets.
- Separate paging systems that nobody watches at night.
The ransomware outage avoided each. FCS-260 stayed open while IT closed the outage, CHG-3301 was reviewed at the next change board, the service desk saw only neutral wording, and paging went through the system IT operations already watched at night. The problem record about the shared credential kept the cause visible after the service was restored, so it could be fixed rather than forgotten.
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 — Routing rules. Steps: write four rules that route IT tickets to security cases. Rubric: 3 = specific triggers (keywords, categories, asset tier, reporter type) with restriction and paging; 2 = vague triggers; 1 = one; 0 = none.
EX062 — Emergency change record. Steps: write CHG-3301 minimum record. Rubric: 3 = what, why (neutral), risk, rollback, approver, time, link to case, retrospective date; 2 = missing rollback; 1 = vague; 0 = none.
EX063 — Closure rule. Steps: define when INC-8812 and FCS-260 may each be closed. Rubric: 3 = INC on service restoration and owner acceptance; FCS on investigation complete, residual risk accepted, review done; linked problem open as needed; 2 = one; 1 = same rule; 0 = none.
Chapter synthesis
Integrate response with incident, change, problem and configuration processes; give containment a fast, accountable emergency change path; protect confidentiality; and keep service restoration and security closure as separate, linked decisions.
Continue studying — chapter 21 of 30
← Chapter 20 · Course chapter index · Chapter 22 →
Continue to the next authored lesson.