ITIL Incident Management Workflow - Process Guide

Incident Management
INCIDENT MANAGEMENT
(IM)
Process guide
Author Name
[E-Mail-Adresse]
2017
text

Incident Management
Table of Content
TABLE OF CONTENT.................................................................................................................3
1. INTRODUCTION.................................................................................................................5
2. KEY DEFINITIONS .............................................................................................................6
3. PURPOSE AND OBJECTIVES.............................................................................................10
4. SCOPE..............................................................................................................................11
5. POLICIES.........................................................................................................................12
6. TRIGGERS, INPUTS, OUTPUTS.........................................................................................16
7. PROCESS FLOW ...............................................................................................................18
8. ROLES AND RESPONSIBILITIES......................................................................................33
9. RACI MATRIX ..................................................................................................................38
10. CSF AND KPI ..................................................................................................................41
11. ROLE ASSIGNMENT........................................................................................................46
This document is a partial preview. Full document download can be found on Flevy:
http://flevy.com/browse/document/itil-incident-management-workflow-process-guide-3020

Incident Management
1. Introduction
Incident is any unplanned event which disrupts, or which could disrupt, a service.
Incident management process is responsible for managing the lifecycle of all incidents and restoring the
normal service as quickly as possible thus minimizing the adverse impact of incidents on business
operations.
Incidents are categorized to identify who should work on them and for trend analysis, and they are
prioritized according to urgency and business impact. If an incident cannot be resolved quickly, it is
escalated. Functional escalation passes the incident to a technical support team with appropriate skills;
hierarchical escalation engages appropriate levels of management. Once the incident has been resolved
from a technical perspective, the service desk ensures that the user is satisfied and working as ‘normal’
before the incident is closed.
This document together with related documents introduces the Incident Management process
framework; document the workflow, roles, procedures, and policies needed to implement a high quality
process and ensure that the processes is effective in supporting the business.
This document is a living document and should be analyzed and assessed on a regular basis.

Incident Management
Key definitions
Major Incident
An incident with a high impact, or potentially high impact, which
requires a response that is above and beyond that given to
normal incidents. Typically, these incidents require cross-
company coordination, management escalation, the mobilization
of additional resources, and increased communications.
Service Request
Requests for new or altered service. The types of service
requests vary between organizations, but common ones include
requests for change (RFC), requests for information (RFI),
procurement requests, and service extensions.
Service Desk
A function that provides the vital day-to-day contact point
between customers, users, IT services, and third-party
organizations. The service desk not only coordinates the
incident management process, but also provides an interface
into many other IT processes.
1st
line support
The team that provides the very first line of support for
processing incidents and service requests. The initial support
staff is responsible for trying to resolve incidents at first
contact—by identifying known workarounds, using diagnostic

Incident Management
Key definitions
• Between the service desk and a support group to
provide incident resolution in agreed times.
Problem The undiagnosed root cause of one or more incidents.
Service Level
Agreement (SLA)
An agreement between an IT service provider and a customer.
A service level agreement describes the IT service, documents
service level targets, and specifies the responsibilities of the IT
service provider and the customer. A single agreement may
cover multiple IT services or multiple customers. See also
operational level agreement.
Solution
Also known as a permanent fix. An identified means of resolving
an incident or problem that provides a resolution of the
underlying cause.
Workaround
An identified means of resolving a particular incident, which
allows normal service to be resumed, but does not actually
resolve the underlying cause that led to the incident in the first
place.

Incident Management
4.Scope
Incident Management includes lifecycle management of any event which disrupts, or which could
disrupt, a service.
This includes:
• events communicated directly by users, either through the Service Desk or through an interface
• events from Event Management tools to Incident Management tools or functions.
• events reported and/or logged by technical staff.
Out of scope:
Incidents and service requests/change proposals are different. Service requests and Change proposals
do not represent a disruption to agreed service, but are a way of meeting the customer’s needs and may
be addressing an agreed target in an SLA.

Incident Management
Policies Incident Management Process
Policy 3
Incidents and their
status must be
timely and
effectively
communicated.
• Service Desk function is in place to
coordinate communication about incidents
to those impacted by them as well as those
working to resolve them.
• Communication about incidents is
appropriate for the respective audience
receiving communications (e.g. business,
technical..)
Policy 4
Incidents must be
resolved within
timeframes
acceptable to the
business
• agreed service levels, operational level and
underpinning contracts (UCs) are in place
• quick access is available to incident, known
error and configuration information
• adequate access to needed technologies
and resources
Policy 5
Customer
satisfaction must
be maintained at all
times.
• Closure of incidents is dependent on
validating with the user that the incident
has been resolved and service is restored
• Adequate customer-oriented staff are
effectively utilized at all stages of the
process.
Policy 6
Incident processing
and handling
should be aligned
with overall service
levels and
objectives.
• Incident management activities support
service levels and objectives by prioritizing
those activities based on actual business
need.
• Required service levels and objectives are
already understood and agreed to by the
business.
Policy 7
All incidents should
be stored and
managed in a single
• Status and detailed information on the
incident is recorded and updated on a
timely basis in incident records.

Incident Management
Policies Incident Management Process
escalating incidents
should be in place
wherever possible.
individuals within the IT support
organization.
• criteria for prioritizing and escalating
incidents are established in advance, well
communicated, and agreed to by both IT
and the business.

Incident Management
Triggers, Inputs, Outputs
• Customer feedback on success of incident resolution activities and
overall quality of incident management activities
Outputs
• Resolved incidents and actions taken to achieve their resolution
• Updated incident management records with accurate incident detail
and history
• Updated classification of incidents to be used to support proactive
problem management activities
• Raising of problem records for incidents where an underlying cause has
not been identified
• Validation that incidents have not recurred for problems that have
been resolved
• Feedback on incidents related to changes and releases
• Identification of Configuration Items (CIs) associated with or impacted
by incidents
• Satisfaction feedback from customers who have experienced incidents
• Feedback on level and quality of monitoring technologies and event
management activities
• Communications about incident and resolution history detail to assist
with identification of overall service quality.

Incident Management
Incident Management
User/ Customer Service Desk / 1st
line support
2nd
, 3rd
and 4th
line
support
Other
Processes
Situation
Manager
yes
Change Proposal
Start
3. Incident
Categorization
4. Incident
Prioritization
9. Incident closure
Escalation needed?
Resolved ?
8. Resolution and
Recovery
Major Incident
?
6. Functional
Escalation
7. Investigation
and Diagnosis
yes
no
5. Initial Diagnosis
Resolution
identified?
1. Incident
identification
Is this an
Incident?
no
Major Incident
procedure
2.Incident Logging
ServiceRequest
ServiceRequest or
Change Proposal?
Functional or
HierarchicEscalation
needed?
hierarchic
functional
Hierarchic
Escalation
Change
Management
Problem
Management
yes no
ServicePortfolio
Management
Request Fulfilment
yes
no
End
yes
no
Monitoring
Start

Incident Management
NR. STEP DESCRIPTION ACTIVITIES IN DETAIL
resolution of the
incident.
For user Incident
status inquires,
giving status
updates and
updating Incident
records.
• Validate or replicate: Take steps to
validate or replicate the Incident. Gather
any data about the incident (screenshots,
descriptions). Associate to any concurrent
incident (e.g. major outage) if appropriate.
• Capture and Document Incident
Details: Complete the short and long
description, ensuring they are clear and can
be understood by others. Collect incident
symptoms.
• Update Incident Activity Log &
Communicate Status: If User is inquiring
about status of an existing incident, provide
the User with status as available in the
incident record, update the record indicating
that the caller was inquiring and update with
additional details if available.
3. Incident
Categorization
Recording the
exact type of
incident and
allocating
suitable incident
categorization
coding.
• Identify Incident Type: Capture the
incident type based on the customer-
reported symptoms.
• Associate Configuration Item(s):
o If a Configuration Management System
(CMS) is present, associate the incident
to the Configuration Item(s) (CI)
diagnosed to have failed and are
causing the incident. Note, IT
Business and Provider Services may be
captured as CI’s, if implemented.
o If there is no CMS present, capture the
device name or ID, and based on the
primary failed device, capture the
component categorization.
• Complete Incident Categorization:
o Capture IT Business Service
categorization, as defined by the
customer.

Incident Management
with the management structure to
coordinate a cross- functional team to
address the situation if needed and where
the underlying issue is unclear.
• Trigger and execute communications
as required until Incident Resolved:
Ensure that the communication is planned
and executed according to internal
procedures and triggers. At a minimum
communication is to be shared at the
beginning and end of a Major Incident and
perhaps at specific intervals throughout the
resolution process. This communication
can be to either internal IT stakeholders or
Customers or a combination of both.
• Prepare Major Incident
documentation as defined & Perform
Post Resolution Review Upon
resolution of a Major Incident,
documentation must be prepared that
summarizes the issue, actions taken and
resolution details. It should also trigger
root case analysis if required and allow for
improvements that can be made to avoid
the situation in the future.
5. Initial
diagnosis
Service Desk/1st
line support
carries out initial
diagnosis
• Perform Initial Diagnosis: Try to
discover full symptoms of the incident and
determine what has gone wrong and how
to correct it. Document all trouble-shooting
steps within the incident record (use
diagnostic scripts if available).
• Incident matching; Search Knowledge
Base, Known Error Database and
Change Schedule: Use initial diagnosis
details to search the knowledge base for
relevant knowledge. Also check the known
error database to see if a workaround exists
and the change schedule to see if this is
issue could be related to a recently

Incident Management
been exceeded – whichever comes first),
the incident must be immediately escalated
for further support.
• Hierarchic escalation needed:
o If incidents are of a serious nature (for
example, high-priority incidents) the
appropriate IT managers must be
notified, for informational purposes at
least.
o if the ‘investigation and diagnosis’ and
‘resolution and recovery’ steps are
taking too long or proving too difficult.
o If there is contention about who the
incident is allocated to.
o Hierarchic escalation can, of
course, be initiated by the affected
users or customer management,
as they see fit
Hierarchic
escalation
Hierarchic
escalation of
Incident.
• Hierarchic escalation should continue up the
management chain so that senior managers
are aware and can be prepared and take
any necessary action, such as allocating
additional resources or involving
suppliers/maintainers
6. Functional
escalation
Functional
escalation of
incident.
• Internal Provider or external
provider? If functional escalation is
necessary, determine if the functional
group that is equipped to resolve the
incident is an internal support group or an
established external partner that has a
support agreement and process established
for incident resolution.
o (Internal) Assign Incident to
internal functional Group:
Determine the proper group for
assignment and assign it to the Group.

Incident Management
Vendor, the Functional Group is additional
to Service Desk responsible to work with
the external partners and maintain
oversight of the incident record.
• Perform investigation: This investigation
is likely to include such actions as:
o Establishing exactly what has gone
wrong or is being sought by the user
o Understanding the chronological order
of events
o Confirming the full impact of the
incident, including the number and
range of users affected
o Identifying any events that could have
triggered the incident (e.g. a recent
change, some user action?)
o Detailed knowledge searches looking for
previous occurrences by searching
incident/ problem records and/or known
error databases (KEDBs) or
manufacturers’/suppliers’ error logs or
knowledge databases. (These matches
may not have been obvious during initial
diagnosis.)
7. Investigation
and diagnosis
Performing
deeper
investigation and
diagnosis of
incident.
• Perform Initial Review & Diagnosis:
Perform initial review to determine if the
incident has been properly assigned.
• If improperly assigned, Update
Incident and Assign to Service Desk
for Re-diagnosis and Re-assignment:
If the incident was improperly assigned, the
Functional Group assigns it back to the
Service Desk for further diagnosis and
assignment.
• If further user information needed,
Contact Requestor for Additional
Information: If assignment is proper,
accept the incident (work in progress) and
determine if further information is required

Incident Management
resolutions to
Incidents.
• Work to Resolve Incident Updating
Incident with Necessary Details: If no
workaround exists, begin resolution activities
making sure to update the incident record
with all details related to resolution
activities. When a potential resolution has
been found, this should be sufficiently
tested. If resolution requires that a change
is introduced, a Request for Change must be
submitted and flow through the Change
Management Process.
• Update Incident Resolution Details and
Assign to Service Desk: Once the
incident has been resolved it is good practice
to review the solution and determine if
knowledge could be authored for future
occurrences, or if there is a systemic issue
that needs to be addressed through the
Problem Management Process. Upon
resolution, the incident is updated with the
proper resolution information and coding,
and is assigned to the Service Desk for final
closure activities.
• Service Desk Analyst Contact
Functional Group or Vendor for
Additional Resolution Details if
Required: In preparation for closure
activities, review the incident details to
ensure it is completed properly and has the
appropriate resolution details.
Resolved? Is incident
resolved?
9. Incident
closure
Solution is
validated with
user and Incident
record is closed
by Service desk.
• Validate/update closure categorization:
Check and confirm that the initial incident
categorization was correct or, where the
categorization subsequently turned out to be
incorrect, update the record so that a correct
closure categorization is recorded for the

Incident Management
End
Ownership,
Monitoring,
Tracking,
Escalation &
Communicati
on
The ownership of every service Incident
belongs to the service desk regardless of
where that Incident is passed for resolution.
Communication takes place between the
service desk and the user/customer as well as
IT personnel when needed and indicated
according to policies and procedures. Using
the tools available, all incidents are:
• Monitored to make sure they are
moving along the process path in a
timely manner
• Tracked to ensure that all actions are
logged at an appropriate level of detail
so that it is possible to account for what
has transpired in the life of the incident
Own, Monitor & Track (Continuous)(Service
Desk)
• Scan Status of Incident Records
• Review Progress
• Identify Records of Interest
• Record & Perform Actions (where
required)
• Notify Affected Parties Concerning
Actions (where required)
• Obtain/Receive Status Updates
• Associate Update with Record (Update
Record)
Communicate/Report (Servicer Desk):
• Analyse Incident Information (Report
Requirements, Problems, Continual
Service Improvement initiatives)
• Define & Build Reports (if not standard)
• Generate & Communicate Report

Incident Management
8.Roles and responsibilities
The following roles have been identified within the Incident Management Process:
Roles and responsibilities
Incident Management
Process Manager
Responsibility for every day execution of the Incident
Management process in the organization and all process outputs.
• Oversee day to day process execution
• Drive the efficiency and effectiveness of the Incident
Management process.
• Produce management information.
• Monitor the effectiveness of IM and make
recommendations for improvement.
• Develop and maintain the IM systems.
• Managing the work of incident support staff (first- and
second-line)
• Manages major incidents until the appropriate situation
manager is identified
• Developing and maintaining the incident management
process and procedures.

Incident Management
• Manages the service desk function, including staffing
management activities
• Provides guidance to Service Desk Analysts
• Run scheduled and ad hoc incident management reporting
1st line support
analyst / Service Desk
Analyst
• Triage - Routes non-Incidents to appropriate processes
• Keeping user informed
• Logs incidents
• Categorizes and prioritizes incidents
• Provides initial diagnosis
• Resolve incidents at first point of contact if possible
• Escalates incidents
• Owns non-major incidents
• Record the incident
• Provide initial support
• Determine and provide ownership, monitoring, tracking,
and communication.
• Resolve and recover incidents not assigned to Tier 2
• Monitor incident details, including the configuration items
(CIs) affected.
• Investigate and diagnose incidents. Include resolution
when possible.
• Detect possible problems and assign them to the Problem
Management team for them to raise problem records.
• Resolve and recover assigned incidents.
• Close incidents

Incident Management
• After restoration, responsible for a review and assembling
recommendations to prevent reoccurrence in coordination
with Incident and Problem Management.
4th line support
Analyst / External
Partner Analyst
• Receive incident records as per contract
• Provide incident solution
• Update incident records
• Communicate with IT incident requester

Incident Management
RACI Matrix
1st line support 2nd, 3rd and 4th line
support
User/
Incident
request
or
Service
Desk
Analyst /
1st line
support
Incident
Manager
2nd, 3rd
and 4th
line
support/
Function
al group
Analyst
2nd, 3rd
and 4th
line
Manager/
Function
al group
Manager
Major
Incident
Manager/
Situation
Manager
Incident
Manage
ment
process
owner
1. Incident
identification
C R A
Is this an
incident
R A
Service
Request or
Change
proposal?
R A
2. Incident
logging
C R A
3. Incident
Categorizatio
n
R A
4. Incident
prioritization
C R A
Major
incident?
R A, C C C
Major
Incident
procedure
I I R R A,R
5. Initial
diagnosis
R A
Escalation
needed?
R A, C
Functional or
hierarchic
escalation
needed?
R A, C
Hierarchic
escalation
R A

Incident Management
10. CSF and KPI
Each organization should develop KPIs that are appropriate for its level of maturity, its CSFs and its
particular circumstances. Achievement against KPIs should be monitored and used to identify
opportunities for improvement, which should be logged for evaluation and possible implementation.
Sample KPIs for Incident Management to start with could be:
Sample: Initial KPIs for Incident Management
KPI Nr. KPI KPI use
IM – KPI -1 Total number of incidents
recorded (open and closed),
open < closed
Gives an indication of the
overall workload of the
Information Services staff.
IM – KPI -2 Number of incidents
recorded per category (open
and closed)
Useful to identify areas that
could require detailed
analysis to remove common
problems.
IM – KPI -3 Percentage and number of
incidents responded within
service level times
An important measure that
indicates the level of service
that is being provided to the
clients of Information
Services.
IM – KPI -4 Percentage and number of
incidents resolved within
service level times
An important measure that
indicates the level of service
that is being provided to the

Incident Management
Critical Success Factors (CSF) & Key Performance Indicators (KPI)
• Number and percentage of incidents resolved
remotely, without the need for a visit
• Number of incidents resolved without impact to the
business (e.g. incident was raised by event
management and resolved before it could impact the
business)
Maintain quality of IT
services
• Total numbers of incidents (as a control measure)
• Size of current incident backlog for each IT service
• Number and percentage of major incidents for each
IT service
Maintain user satisfaction
with IT services
• Average user/customer survey score (total and by
question category)
• Percentage of satisfaction surveys answered versus
total number of satisfaction surveys sent
Increase visibility and
communication of
incidents to business and
IT support staff
• Average number of service desk calls or other
contacts from business users for incidents already
reported
• Number of business user complaints or issues about
the content and quality of incident communications
Align incident
management activities and
priorities with those of the
business
• Percentage of incidents handled within agreed
response time (incident response- time targets may
be specified in SLAs, for example, by impact and
urgency codes)
• Average cost per incident CSF
Ensure that standardized
methods and procedures
are used for efficient and
prompt response, analysis,
documentation, ongoing
management and
reporting of incidents to
maintain business
• Number and percentage of incidents incorrectly
assigned
• Number and percentage of incidents incorrectly
categorized
• Number and percentage of incidents processed per
service desk agent
• Number and percentage of incidents related to
changes and releases.

Incident Management
Specific procedures
INCIDENT MANAGEMENT
(IM)
Process guide

Incident Management
Incident Management - Role Assignments
2nd or 3rd line support
Analyst / Functional
Group Analyst
Situation Manager / Major
Incident Manager
4th line support Analyst /
External Partner Analyst e.g. Vendor solution group specialist

Incident Management
Incident progress status codes
CLOSED Incident is formally closed by Service Desk. The Ticket is now
considered inactive and there is no further consideration of it beyond
analytical purposes. Unsolved Incidents may be recorded as Problem
Tickets by Problem Management.
PENDING The definition of pending, in general terms, must be: “delay by some
reason”.
• PENDING – USER RESPONSE: Waiting for some user action to
continue (e.g. information, decision, testing, ...). In this case
timer for incident can be stopped till user is successfully
contacted. Maximum time for this status to be opened is 10
business days.
• PENDING – USER SOLUTION VERIFICATION: Possible
solution/workaround is provided. Waiting for user verification. In
this case timer for incident can be stopped till user verifies (or in
case where there is no verification Incident is closed without
verification after appropriate time)..
• PENDING – PARTNER SUPPORT: Waiting for external supplier´s
action. Incident has been sent to external Partner to provide
solution/patch.
• PENDING – RELEASE OR UPGRADE: Waiting for new
release/upgrade.
• PENDING – OPENED PROBLEM: Problem has been raised and
Problem Management analysis is performed
• PENDING – RFC: Request for Change (RFC) has been raised and
waiting for Change Management approval.
• PENDING – SCHEDULED: Resolution is planned on a known date-
time. This could be used when a resource (or user) will be
available on a known date and resolution can’t be done before
that. This should eventually be changed to resolved.
• PENDING – OTHER: All other reasons.

Incident Management
4. Use the categories for a short trial period (long enough for several hundred incidents to fall into
each category, but not too long that an analysis will take too long to perform).
5. Perform an analysis of the incidents logged during the trial period. The number of incidents
logged in each higher-level category will confirm whether the categories are worth having – and
a more detailed analysis of the ‘other’ category should allow identification of any additional
higher-level categories that will be needed.
6. A breakdown analysis of the incidents within each higher-level category should be used to decide
the lower-level categories that will be required.
7. Review and repeat these activities after a further period of one to three months and again review
regularly to ensure that they remain relevant.
Note: Be aware that any significant changes to categorization may cause some difficulties for
incident trending or management reporting, so they should be stabilized unless changes are
genuinely required.

Incident Management
Impact Matrix – Sample
Impact 1
(Extensive/Widspread)
Definition Major Business Impact: Outage with no workaround resulting
in complete loss of core business systems to customer.
Example Operating system unavailable.
Production system component failure resulting in loss of
system availability.
Telephone switch unavailable.
Inter- and intra-site communication links not functioning.
Critical applications and databases not functioning.
Critical network component (core router or switch supporting
enterprise services) not functioning.
Connectivity and/or component failure resulting in a loss of
access to Internet (i.e., firewall, Internet connection, proxy,
etc).
Impact 2
(Significant/Large)
Definition Significant Business Impact: Outage with no workaround
resulting in significant loss or degraded system services to
customer; however, operations can continue in a restricted
mode.
Example Production system components unavailable impacting batch
and online schedules
Failure or system degradation in any of the following areas:
cluster controller, hub, router, servers, data switch, server
application, data-link failure with an alternate route, video
services, voice mail system
Significantly degraded response from critical applications and
databases.

Incident Management
(High) Example User(s) can function in a limited capacity or a work-around is
available.
Urgency 3
(Medium)
Definition Restoration requirement is medium but time is less critical.
Example User(s) can function and perform their duties but in a degraded
state.
User(s) may request that the full restoration take place at a later
time.
System may require a Change that can wait until non-production
time.
Urgency 4
(Low)
Definition Restoration requirement is low or not required.
Example Single customers and job functionality is not impacted
Personal computer (PC), workstation, and terminal
Printer, plotter, scanner
Telephone
End-user software (e.g., LAN access, password resets, etc.)
Network services warnings.

Incident Management (IM)
1
4 Low 48 hours
5 Planning Planned

3
DOCUMENTED – SOLUTION NOT
APPROVED
Solution is known but it is not approved ( too costly, too
risky,)
DOCUMENTED – ABANDONED There is no solution and IT made a decision that the
Incident is acceptable.
DROPPED – NO RESPONSE Client didn’t provide enough information and is not
replying.
DROPPED – INVALID Case Invalid and was dropped (e.g. client doesn’t have
valid support and/or didn’t reply on warning (used if no
answer within 10 business days)).
INCIDENT CLOSURE CODE – USER VERIFICATION
Incident closure code User verification reflect user acknowledgement of Incident resolution.
Code Description
USER – VERIFIED Requestor verified the resolution.
USER – NOT ACCEPTED User gives feedback that Solution/Workaround is not
working or user is not accepting it as satisfactory.
USER – NO RESPONSE Automatically closed, no user verification. After agreed
period of time without user response it is assumed that
resolution worked and Incident is automatically closed.

5
17. Sample Major Incident
Procedure
Major incidents are those for which the degree of impact on the business/organisation is extreme.
A separate procedure, with shorter timescales and greater urgency, must be used for major incidents.
Major incident procedure includes the dynamic establishment of a separate Major Incident Team, under
the direct leadership of the Incident Manager, formulated to concentrate on this incident alone, and to
ensure that adequate resources and focus are provided for finding a fast resolution. If the Service Desk
Manager is also fulfilling the role of Incident Manager (which is the situation), a separate person may
need to be designated to lead the major incident investigation team –to avoid conflict of time or
priorities – but should ultimately report back to the Incident Manager.
A procedure for Major Incidents manages all aspects of a major incident, including resources and
communication. It describes how the business/organisation handles major incidents from receiving
notification of a potential major incident, through the investigation process itself and to the delivery of
a final report. A related procedure describing the process of reviewing the major incident policy and
procedure also needs to be in place. Areas covered in the major incident policy and procedure are:
Sample Major Incident Procedure - Guidelines
Purpose This procedure and related policies have been put in place to
document the business/organisation’s requirements and
arrangements for responding to and investigating major incidents.

7
Sample Major Incident Procedure - Guidelines
• to provide timely information about the causes of incidents
and any relevant findings from investigations
• to conduct a review of each major incident once service has
been restored and, in line with problem management, to look
at root cause and options for a permanent solution to
prevent the same major incident happening again
• to conduct reviews of major incident investigation policy and
procedure, independent of the major incident investigation,
and to report on them (any lessons to be learned from the
policy and procedure review will be considered, and
appropriate action taken to ensure any improvements to
existing arrangements are implemented within a specified
timescale)
Roles and
responsibilities
The following roles and responsibilities need to defined for managing
major incidents:
• The Incident Manager
• The Problem Manager
• If no Problem Manager exists, the role of Root Cause Analyst
• Major Incident Investigation Board „ Investigation
Team/investigation resources (technical staff)
• The service desk
• Service level managers/IT account managers
• Any other relevant groups who will act as part of the Major
Incident Team
Other considerations

9
Escalation
types
Typically you could specify an “on-call” pager for each major
technology group. The manager for each technology group is
responsible for creating an on-call schedule and ensuring that the on-
call pager is carried at all times. Further, each technology group must
designate a managerial (hierarchical) escalation path. Typically, the
line manager for the level 3+ group is the first manager in the
escalation path.
Hierarchic
escalation
To ensure that appropriate priority and resources are being allocated
to resolve an incident before resolution timeframes are exceeded,
hierarchical escalation involves management in the process.
Hierarchical escalation can occur at any support level.
Best practice is that escalation to management occurs automatically
according to a predetermined schedule based on severity of the
issue. When an escalation occurs, the targeted manager is expected
to actively manage resolution of the problem, and becomes the single
point of contact for status messages.
Cross group
escalations
A message to another on-call support group requesting assistance
may be sent via text pager and/or telephone call, but responsibility
for resolution of the problem is not transferred. The receiving support
group is expected to render assistance to the caller. A pre-established
audio-conference bridge is used to conduct the conference, which
may grow to multiple support groups throughout the course of the
incident.
War- room
escalation
The purpose of a war-room is to bring together key parties involved
in restoring service to establish a plan of action and ensure that an
appropriate cross-disciplinary response is being fielded.
A war-room notification is automatically sent when it is likely that a
high-severity incident will not be resolved within the target
timeframe. Also, war-rooms may be manually called by any manager
to whom incident responsibility has been transferred. The war-room
is usually a centrally located conference room with a speaker phone,
whiteboard, network connections and a pre-established, toll-free
audio-conference number.

11
Following is Sample - Functional escalation matrix:
FUNCTIONAL ESCALATION MATRIX – Sample
Priority
Priority 1 Priority 2 Priority 3 Priority 4
Tier Tier 1 10 Mins. 30 Mins. 2 Hrs. 12 Hrs.
Tier 2 1 Hr. 2 Hrs. 12 Hrs. 24 Hrs.
Tier 3 2 Hrs. As Needed As Needed As Needed
Following is Sample - Hierarchic escalation matrix:
HIERARCHIC ESCALATION MATRIX - Sample
Incident Priority 1 ( Major Incident) SLA = 4 hours
Timeframe Trigger Parties Notified
Start Incident Logged • All IT Staff
Every 1 hours Until Resolved
• Progress report to IT Manager
• Progress report to Team Leaders
Any Time
Status change to ‘Pending
Third Party’
• IT Manager,
• IT Team Leaders
• Relevant Support Group Staff
Resolved Status changes to ‘Resolved’ • All IT Staff
Incident Priority 2 SLA = 12 hours
Timeframe Trigger Parties Notified
Start Incident Logged • IT Team Leaders

1
Flevy (www.flevy.com) is the marketplace
for premium documents. These
documents can range from Business
Frameworks to Financial Models to
PowerPoint Templates.
Flevy was founded under the principle that
companies waste a lot of time and money
recreating the same foundational business
documents. Our vision is for Flevy to
become a comprehensive knowledge base
of business documents. All organizations,
from startups to large enterprises, can use
Flevy— whether it's to jumpstart projects, to
find reference or comparison materials, or
just to learn.
Contact Us
Please contact us with any questions you may have
about our company.
• General Inquiries
support@flevy.com
• Media/PR
press@flevy.com
• Billing
billing@flevy.com

ITIL Incident Management Workflow - Process Guide

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to ITIL Incident Management Workflow - Process Guide

Similar to ITIL Incident Management Workflow - Process Guide (20)

More from Flevy.com Best Practices

More from Flevy.com Best Practices (20)

Recently uploaded

Recently uploaded (20)

ITIL Incident Management Workflow - Process Guide