INCIDENT MANAGEMENT

PROCEDURE

LOGO
MODIFICATION HISTORY
DATE

VER

MM/DD/YY

1.0

DESCRIPTION OF
CHANGES
Baseline

EDITED BY

APPROVED BY

Name

Name

Title

Title

Date

Date

The purpose of incident management is to

restore normal service operations as soon as
possible and to minimize the adverse impact
on business operations.
The scope of incident management includes
any event that disrupts or could disrupt a
service.

VALUE TO BUSINESS
Increased availability of services
Reduced impact on business operations
Timely resolution of incidents
Higher user and business satisfaction
Reduced unplanned labor costs for both the
business and IT support staff

REFERENCE DOCUMENTS

DEFINITIONS & ABBREVIATIONS

CMS

OLA
Priority

Second-level
Support
Service Desk
SLA
UC
Urgency

Workaround

Page: 1 / 7

Configuration Item
First-level support handles less
complicated technical incidents
An unplanned interruption or a
reduction in the quality of an IT
service
A measure of the effect of an
incident on business operations,
based on how service levels are
affected
Operational Level Agreement
Used to identify the relative
importance of an incident.
Priority is based on impact and
urgency and is also used to
identify the time required to take
action.
Request for Change
Handles complex and
specialized technical problems
(e.g., network specialists,
application specialists, and
database specialists)
Single point of contact to report
and track incidents
Service Level Agreement
Underpinning Contract
Urgency is a measure of how
long it will be until an incident
has a significant impact on the
business operations
Temporary solution to overcome
a service interruption

TRIGGERS
User contacts service desk and reports a
service disruption
Event management automatically reports a
service disruption or an event exceeding the
defined thresholds
Technical staff notices a potential failure and
reports it to the service desk
Supplier makes a request to raise an incident

ITIL Service Operation Guidance Publication

(ITIL is a registered trade mark of AXELOS
Limited)

ITEM

Impact

RFC

PURPOSE & SCOPE

CI
First-level
Support
Incident

CODE: ICM_P1

DESCRIPTION

Configuration Management
System

PROCESS INPUTS & OUTPUTS

Confidential
Copyright 2013 by IT Quality Management Solutions (PVT) LTD. All rights reserved. No part of this publication may be reproduced, stored in any
retrieval system, or transmitted in any form or by any means, electronic or otherwise, without written permission.

INCIDENT MANAGEMENT
PROCEDURE

LOGO
PROCESS INPUTS
Incident (occurrence)
SLA
CMS
Known Error Database
Customer Feedback

PROCESS OUTPUTS
Incident Log/Database
Temporary Solution/
Workaround
Request for Change
(RFC)
Problem Record
Resolved Incidents and
Resolution Actions

Criteria for Prioritizing

Satisfaction Feedback
and Escalating Incidents
Event Management
Performance Reports
Defects Database

ROLE
-

RESPONSIBILITIES
Define and maintain
incident management
procedure.
Design incident models and
workflows.
Coordinate and manage
incidents throughout the
incident lifecycle.
Provide training to service
desk agents.
Coordinate with support
personnel at various levels
to find a workaround or
temporary fix.
Monitor the effectiveness
of the incident management
process.
Manage major incidents.
Open problem tickets and
RFCs if required.
Provide periodic
management reports.
Coordinate interfaces
between incident
management and other
Information Technology
Service Management
(ITSM) processes.

Page: 2 / 7

KEY PERFORMANCE INDICATORS (KPIS)

OBJECTIVE
Efficiency
Effectiveness
Effectiveness
Effectiveness
Effectiveness
Satisfaction

ROLES & RESPONSIBILITIES

Incident Manager

CODE: ICM_P1

Efficiency

KPI
Mean time to resolve
incidents
Percentage of incidents
resolved by service desk
Percentage of incidents
incorrectly assigned
Percentage of incidents
reopened
Number of major incidents
for each IT service
User satisfaction survey
score
Number of incidents
incorrectly categorized

CRITICAL SUCCESS FACTORS

Incident manager/Process owner
Single Point Of Contact (SPOC) for recording
incidents
Management commitment
Align incident management activities and
priorities with business priorities

RISKS

Incidents recorded in multiple locations/logs

Lack of trained service desk agents
Insufficient resources and funds allocated to
the incident management process

INTERFACES
Service level management: Requires a process
capable of monitoring and resolving incidents
in specified times.
Information security management: Requires
information on security incidents to measure
the effectiveness of security controls.
Capacity management: Requires information
on performance issues and incidents related to
capacity.
Availability
management:
Requires
information on the availability of IT services
and incidents related to availability.

Confidential
Copyright 2013 by IT Quality Management Solutions (PVT) LTD. All rights reserved. No part of this publication may be reproduced, stored in any
retrieval system, or transmitted in any form or by any means, electronic or otherwise, without written permission.

LOGO

INCIDENT MANAGEMENT
PROCEDURE

CODE: ICM_P1

Page: 3 / 7

Service asset and configuration management:

Helps in assessing the impact of an incident.
Change
management: Assists in the
implementation of workarounds or resolutions.
Problem management: Provides known errors
and workarounds for faster incident resolution.

Confidential
Copyright 2013 by IT Quality Management Solutions (PVT) LTD. All rights reserved. No part of this publication may be reproduced, stored in any
retrieval system, or transmitted in any form or by any means, electronic or otherwise, without written permission.

LOGO

INCIDENT MANAGEMENT
PROCEDURE

PROCEDURE FLOWCHART

PROCEDURE DESCRIPTION
Detect, Filter, Record, & Categorize
Detect & Filter

CODE: ICM_P1

Page: 4 / 7

Incidents can be detected and reported in one

of the following ways:
a.) User contacts the service desk by
phone, fax, email, or intranet (directly
logs an incident in the incident
management tool)
b.) Supplier initiates an incident
c.) Customer contacts the call center
d.) Event management identifies an
incident or potential incident and
reports it to the service desk
e.) Technical staff identifies and reports
an incident
f.) Risk management department
g.) Information security group
2. Incident manager or a service desk agent
should review and filter incidents before
recording.
3. Incident manager or service desk agent should
consider the following while recording
incidents:
a.) If there is no incident history, start with
new incidents
b.) Recoding the same incident twice must
be avoided
c.) Incidents should be handled according
to a defined Service Level Agreement
(SLA)
d.) Incident status should be maintained
throughout the incident lifecycle
GUIDANCE & TIPS: Incident filtering guidelines
should be documented and communicated to all
service desk agents.
1.

Record
4. Incidents should be recorded in a single central
database or file, regardless of how they are
received.
5. Incidents should be given a unique reference
number and the following details should be
recorded against each incident:
a.) Unique reference number
b.) Date and time
c.) Description of symptom
d.) Category
e.) Urgency
f.) Impact
g.) Priority

Confidential
Copyright 2013 by IT Quality Management Solutions (PVT) LTD. All rights reserved. No part of this publication may be reproduced, stored in any
retrieval system, or transmitted in any form or by any means, electronic or otherwise, without written permission.

LOGO

CODE: ICM_P1

INCIDENT MANAGEMENT
PROCEDURE

h.) Name and department or function of

the person recording the incident

i.) Name of the person affected by the
incident
j.) Preferred call back channel
k.) Configuration Items (CIs) affected
from the Configuration Management
System (CMS)/Configuration
Management Database (CMDB)
l.) Related known error (if any)
m.) History of the incident (where, what,
who)
n.) Expected resolution date and time
(based on the SLA)
o.) Incident status (active, waiting, closed)
p.) Closure category
q.) Closure date and time
GUIDANCE & TIPS: Accurate and complete
details should be recorded for each incident so that
various specialist groups and suppliers can resolve
incidents in a timely manner.

Page: 5 / 7

GUIDANCE & TIPS: The level of urgency

depends on how fast the incident needs to be
resolved, and the impact depends on business
criticality and risk (number of users impacted,
number of services affected, financial losses, etc.)
10. Incident manager should communicate the
incident prioritization guidelines to all service
desk agents or support teams to enable them to
determine the correct urgency and impact.
GUIDANCE & TIPS: Incident prioritization
criteria may be printed on a card and made
available to all service desk agents and support
teams.
11. Service desk agents should also use common
sense judgement when assigning a priority to
an incident.
12. Priorities are dynamic and may be changed
during the life of the incident. Incident
manager should monitor the incident and if
conditions change, the priority should be
updated.

Categorize
6. Incident manager should ensure that incidents
are properly categorized.
GUIDANCE & TIPS: Part of the initial recording
is to categorize the incidents so that the exact type
of incident is recorded.
7. Incident categorization guidelines should be
clearly defined and communicated to service
desk agents.
GUIDANCE & TIPS: If the user is able to record
incidents directly in the system, the users must be
trained to record and categorize incidents.
8. Incidents should be categorized according to:
Incident type (standard incident, major
incident, RFC, standard change)
Category (hardware, software)
Sub-category (email, MS office)
Service (email, office automation)
Urgency and impact
Priority (high, medium, low)

GUIDANCE & TIPS:

Example of incident prioritization matrix:

Prioritize
9. Incident manager or service desk agent should
prioritize incidents based on urgency and
impact.

Initial investigation & Diagnosis

13. Service desk agents should carry out the initial
diagnosis and try to resolve the incident.

Urgency/Imp
act

High

Medium

Low

High

Medium

Low

Priority Code

Type

SLA

Major

1 hr

Critical

4 hr

High

8 hr

Medium

24 hr

Low

48 hr

Confidential
Copyright 2013 by IT Quality Management Solutions (PVT) LTD. All rights reserved. No part of this publication may be reproduced, stored in any
retrieval system, or transmitted in any form or by any means, electronic or otherwise, without written permission.

LOGO

INCIDENT MANAGEMENT
PROCEDURE

CODE: ICM_P1

Page: 6 / 7

14. Each incident should be matched with other

23. Incident manager should ensure that escalation

known errors, existing problem records, and

defects discovered during testing.
15. If a workaround or temporary fix is available,
it should be provided to the affected users so
that they can continue with normal business
operations.

thresholds are clearly defined, agreed upon,

and documented in the SLA for both functional
and hierarchical escalation.
GUIDANCE & TIPS: Targets and thresholds
should be embedded within the service desk tool.

Escalation
Functional Escalation
16. If a service desk agent is unable to resolve the
incident, it should be escalated (transferred) to
the first line support.
GUIDANCE & TIPS: Incident ownership remains
with the incident manager/service desk regardless
of where an incident is referred to during its life.
17. If it is obvious that the first line support would
be unable to resolve the incident, the incident
should be transferred/escalated directly to the
second line (technical or application support).
18. If the first line support is unable to resolve the
incident, it should be transferred to the second
level support for investigation and diagnosis.
GUIDANCE & TIPS: An incident may be
escalated to different levels of technical support
groups until the solution is found. The different
levels may be within the organization or
outsourced to suppliers. The escalation and
handling of each incident must be defined in an
Operational Level Agreement (OLA) and
Underpinning Contract (UC) with internal and
external groups.
19. Incident manager should track progress and
keep users informed during the incident
resolution process.
20. Incident manager should also ensure that the
incident record is updated with the full incident
history.
Hierarchic Escalation
21. If the incidents are serious in nature, the
Incident manager must notify the appropriate
IT and business managers.
22. Incident manager should also notify the
appropriate IT managers if the investigation
and diagnosis steps are taking too long or
proving too difficult.

Investigate & Diagnose

24. Support groups should investigate and
diagnose each incident and identify a solution
or workaround as soon as possible.
GUIDANCE & TIPS: The investigation may
involve identifying the triggers, interfaces, impact,
people involved, and process issues.
25. Incident manager should ensure that support
groups maintain the full history of the entire
investigation and diagnose activities or any
actions taken to resolve the incidents.
26. Incident manager should ensure that users are
kept informed of the incident status until the
incident is resolved and closed.
27. If the incidents are critical in nature, the
appropriate IT managers and business owners
should be kept informed.
Resolution & Recovery
28. Technical/specialist groups should provide
more than one solution to resolve or recover
the incident within the SLA.
29. Solutions should be verified and validated
before they are deployed into the live
environment.
30. Incident records and the known error database
must be updated with all relevant details in
order to speed up the resolution process the
next time a similar incident occurs.
GUIDANCE & TIPS: If there is a change to a CI,
an RFC should be raised before resolving the
incident.
Closure
31. Once the solution has been deployed, the
technical group should transfer the incident
back to the service desk.
32. Incident manager or service desk agent should
contact the user and agree on the solution and
close the incident.

Confidential
Copyright 2013 by IT Quality Management Solutions (PVT) LTD. All rights reserved. No part of this publication may be reproduced, stored in any
retrieval system, or transmitted in any form or by any means, electronic or otherwise, without written permission.

LOGO

INCIDENT MANAGEMENT
PROCEDURE

GUIDANCE & TIPS: Some organizations provide

an automated user satisfaction survey before
closing an incident.
33. Incident manager should verify and modify the
initial incident details (if required). The
following details should be verified:
a.) Closure categorization: Check and
confirm that the initial incident
categorization was correct
b.) Incident record: Ensure that the
incident history is fully documented
c.) Root-cause resolved
34. Incident manager should ensure that the
complete details of the incident life cycle are
documented and maintained.
GUIDANCE & TIPS: Although users are asked
whether an incident can be closed, an auto closing
process should also be in place (for example, to
close an incident after 90 days).
35. Incident manager should also put in place a
mechanism receive and log user satisfaction
feedback before the incident is closed.

CODE: ICM_P1

Page: 7 / 7

number of users or customers affected, and/or

disruption to critical business processes/services.
41. Major incident management sub-processes
(recording, classification, escalation,
resolution, and closure) should be defined and
communicated to all stakeholders.
GUIDANCE & TIPS: Some organizations may
establish a major incident team to follow up on the
major incident resolution process and maintain
detailed records of the incident.
42. Major incidents should take priority over all
other incidents.
43. Incident manager should follow up on major
incidents status and keep the users, the
business, senior IT management, and
regulatory bodies informed.
44. Service desk agents should raise an RFC if
changes are needed to resolve the major
incident.

Reopening Incidents
36. If the incident recurs within a specified short
period, the incident should be reopened and its
status updated.
GUIDANCE & TIPS: Predefined rules should be
established regarding if and when an incident can
be reopened. If an incident does not recur within
the specified period, a new incident should be
raised.
Monitor, Measure, & Report
37. Incident manager should monitor, measure,
and improve the incident lifecycle.
38. The incident resolution rate should be
compared with a defined SLA target.
39. Incidents not resolved within the specified
SLA target should be analyzed and reported to
senior management.
Major Incident Guidelines
40. Incident manager should clearly define a major
incident.
GUIDANCE & TIPS: Incident definition can be
based on financial impact, reputational impact,
Confidential
Copyright 2013 by IT Quality Management Solutions (PVT) LTD. All rights reserved. No part of this publication may be reproduced, stored in any
retrieval system, or transmitted in any form or by any means, electronic or otherwise, without written permission.