Incident Management

Get it working again

When a pipe bursts, the first job is to stop the water and get the kitchen usable again. Working out why the pipe burst comes later, and is somebody else’s job.

An incident is any unplanned interruption to a service, or drop in its quality. Incident management has one goal: restore normal service as quickly as possible and keep the business impact small.

The process

Detect and log: users report through the service desk, or monitoring raises an alert. Every incident is logged.
Categorise by service, component and type, so trends can be analysed.
Prioritise by impact (how many users, how critical the service) and urgency (how soon it hurts).
Diagnose: the service desk checks known error records and the knowledge base.
Escalate if needed:
- functional escalation goes sideways, to a more specialist team
- hierarchical escalation goes upwards, to managers, when SLAs are at risk or bigger decisions are needed
Resolve: a fix or a workaround gets the service back.
Close, only once the user confirms it’s working, with the resolution recorded. Closing without confirmation makes the metrics look better than reality.

Major incidents

Incidents with severe business impact follow a separate, faster procedure: a named incident manager, a dedicated team, shorter timescales, regular updates to stakeholders, and a review afterwards.

Incident vs problem

Incident management restores service; problem management removes the root cause.

	Incident management	Problem management
Goal	Restore service fast	Find and remove the root cause
Timing	Reactive, immediate	Reactive and proactive; can take longer
Output	Service restored, perhaps via a workaround	Known error record; permanent fix through change

Incidents that keep coming back should trigger a problem record.

Example. Users report slow access to the CRM every morning. Each time, the service desk restarts the application server and closes the ticket. Forty tickets later, nobody has raised a problem record. The finding: incident management works in isolation, and recurring incidents aren’t analysed.

Security incidents are different

Security incidents (malware, breaches, unauthorised access) follow the incident response process covered in Domain 5. The service desk must recognise them and route them correctly, because evidence must be preserved and legal or regulatory notification may apply. A quick “restart and close” can destroy the evidence.

How the exam asks about it

If the question asks…	The answer is usually…
Primary objective of incident management	Restore service as quickly as possible
How priority is set	Impact and urgency
Escalation to a more skilled team	Functional escalation
Recurring incidents with the same symptoms	Raise a problem record for root cause analysis
When to close an incident	After the user confirms resolution

In short

Incident management restores normal service as quickly as possible and minimises business impact.
Every incident is logged, categorised and prioritised by impact and urgency.
Functional escalation moves an incident to a more skilled team; hierarchical escalation involves management.
Workarounds restore service; root cause analysis belongs to problem management.
Major incidents follow a separate, faster procedure with dedicated communication.
Incidents are closed only after the user confirms service is restored.

Exam traps

The goal of incident management is restoring service, not finding root cause.
Security incidents follow the incident response process, with evidence preservation, and may need different handling.
Closing incidents without user confirmation distorts metrics.
Repeated incidents with no linked problem record show the incident and problem processes aren't connected.

Slides

Click the slide and use the arrow keys. F toggles full screen.