<Logo> <Company Name> Normal

Incident Management Process

Organization: Document No:
Department: Revision: 0.1
Section: Sheet: 1 of 13

Table of Contents

1. Process Overview..............................................................................................................................................4
1.1 Objectives................................................................................................................................................................ 4
1.2 Scope......................................................................................................................................................................... 4
1.3 Interface with other Processes......................................................................................................................6
2. Incident Management Process......................................................................................................................7
2.1 Incident Management Process flow.............................................................................................................7
2.2 Process Description of Incident Management........................................................................................8
2.3 Process Flow – P1 / P2 (Critical Incident Management).................................................................11
2.4 Process Description of Critical Incident Management (P1)...........................................................12
2.5 Key Contacts and Escalations......................................................................................................................13

Document No:
Sheet: 1 of 13
Revision No:
Issue Date: xx-xxx-xx
 Incident Management Process

Document Control
Document Version History
This table shows a record of significant changes to the document.

Version Date Author Description of Change

Approvals
This table shows the approvals on this document for circulation, use and withdrawal

Version Date Approver Title/Authority Approval Remarks

1.0

1.1

Document No: Sheet: 2 of 13

Revision No: Issue Date: xx-xxx-xx
 Incident Management Process

Glossary

Term Description
Governance The structure and management processes of managing the end to end delivery
of <customer> services.
IM Incident Management
Incident An unplanned interruption to an IT service or a reduction in the availability of
an IT Service.
Problem A cause of one or more Incidents where root cause if not known.
KEDB Known Error Database
RCA Root Cause Analysis. Problem solving methods aimed at identifying the root
causes of problems or events
Third Party A 3rd Party, for the purpose of this document relates to resolvers that may be
required which fall outside the scope of an L2 vendor’s domain.
SLA Service Level Agreement
UC Underpinning Contracts

Document No: Sheet: 3 of 13

Revision No: Issue Date: xx-xxx-xx
 Incident Management Process

1. Process Overview

1.1 Objectives
An 'Incident' is any event which is not part of the standard operation of the Service and which
causes, or may cause, an interruption or a reduction of the quality of the Service.

The objective of Incident Management is to restore normal operations as quickly as possible with
the least possible impact on either the business or the user, at a cost-effective price.

1.2 Scope
Scope of Incident Management activities can be defined as:

 Incident detection
 Registration
 Categorization
 Assignment
 Diagnosis
 Resolution
 Closure
 Incident ownership, monitoring, tracking and communication

Document No: Sheet: 4 of 13

Revision No: Issue Date: xx-xxx-xx
 Incident Management Process

Event Email /
Management Chat /
Tools Phone

Registration

Incident Ownership, Monitoring, tracking and communication

Categorization

Assignment

Diagnosis

Resolution

Closure

Document No: Sheet: 5 of 13

Revision No: Issue Date: xx-xxx-xx
 Incident Management Process

1.3 Interface with other Processes

Problem Configuration
Management Management

Related Problems and - Use of Configuration Records

Known Errors - Configuration Anomalies
- Potential flagging of services
e.g. as ‘failed’ or equivalent

Incident
Management

Change Service Level

Management Management

Details of probable changes to Incident management

resolve particular Incidents information regarding
and Problems breaches of services

The Incident management process interfaces with various other Service management processes as shown
in the diagram above. This diagram depicts how Incident Management is operated and the interfaces
associated with it.

Document No: Sheet: 6 of 13

Revision No: Issue Date: xx-xxx-xx
 Incident Management Process

2. Incident Management Process

2.1 Incident Management Process flow

In practical IT environment, incident management operations would generally be executed as per
the below diagram:

Yes
Raise Ticket Is it an Prioritize &
Start Categorize Incident
Incident?
No

Yes
Follow Service Assign it to Vendor
Service Desk

Request Process vendor related?

No
Close
Follow Major Yes Incident
Incident Is it P1
Process or P2 ?

No

Assign it to Verify
L2 Resolution

Yes
Review & Investigate & Resolved Update the
Update Diagnose ? Ticket
L2 Support

No

Update the Yes

L3 Support No
Ticket as
Required?
pending
L3 Support

Investigate & Resolution

Diagnose Provided

Incident Management Process

Document No: Sheet: 7 of 13

Revision No: Issue Date: xx-xxx-xx
 Incident Management Process

2.2 Process Description of Incident Management

This process starts with the initial detection of incidents and then raising a respective ticket.

Each incident is recorded so that it could be tracked, monitored, and updated throughout its life
cycle.

Owner: Incident Requester / Service

Act No: 1 Act Name: Raise ticket on ITSM
Desk Agent

Description: Once an Incident gets detected, the details are logged in ITSM to raise an
incident ticket. Service Desk will refer KEDB to check whether it is a known error/ issue or
not.

Decision
Act Name: Is it an Incident? Owner: Service Desk
Box

Description: The Service Desk determines if the ticket is an Incident or a Service Request
(Service Request process will have those definitions). Service Requests are small repeatable
requests for work such as password reset, access requests or requests for information.
If the ticket is a Service Request follow the Service Request process.

Output: Service Request or Incident

Act Name: Categorize and Prioritize

Act No: 2 Owner: Service Desk
Incident
Description: Categorize and Prioritize the Incident in ITSM tool.
Categorization is assigning the Category, Type and Item (CTI), to allow the correct assignment
of the ticket. Some of the incidents are related to the 3rd party and they are not assigned to the
L2 teams. Service Desk will raise these categories of the ticket and assign those tickets directly
to the 3rd party vendor.
Prioritization of Incident would be done based on impact and urgency of issue. Incidents are
prioritized into P1, P2, P3 or P4 based on company’s prioritisation. While prioritizing the
Incident, it gets treated based on the criticality.
Output: Categorized and Prioritized Incident

Decision Owner: Service Desk/Incident

Act Name: Is this P1 Incident?
Box Manager
Description: If it’s a critical incident (P1), then it triggers the critical/ major incident handling
process.
Output: Prioritize as Critical/ Major Incident or continue as the normal incident

Act No: 3 Act Name: Assign to L2 Resolver Group Owner: Service Desk

Description: Assign the Incident to the appropriate resolution group. Assignment is based on
the categorization of the Incident.

Output: Resolver group identified

Document No: Sheet: 8 of 13

Revision No: Issue Date: xx-xxx-xx
 Incident Management Process

Act No: 4 Act Name: Review and Update Incident Owner: L2 Team
Description: Upon receipt of an Incident, review and updating is done to the ticket.
Ensure the following has been captured correctly:
 Priority
 Assignment
 Categorization
If any additional information is required to understand the issue, contact the customer who
raised the ticket on Service Desk directly.
Output: Reviewed and updated incident

Act Name: Investigate and diagnose

Act No: 5 Owner: L2 Team
Incident
Description: Carry out investigation and diagnosis activities to identify a workaround or
resolution for the issue. Update ITSM Incident with any investigation and diagnosis activities.
Output: Resolution identified

Act No: 6 Act Name: Resolution Provided Owner: L2 Team

Description: Resolution provided to the Incident. Update the ticket with resolution activities.
Output: Resolved Incident

Decision
Act Name: L3 Support required? Owner: L2 Team
Box

Description:
If L2 is able to resolve the ticket resolution, it is updated in the ticket.
Else if L2 Team is unable to resolve the Incident, functionally escalate the Incident with
respective L3 vendor.

Output: L3 Support required or not

Act No: 7 Act Name: Engage respective L3 Vendor Owner: L2 Team

Description: If the L2 resolver group could not find the resolution and detemines that L3
support is required, the incident is assigned to respective L3 Vendor. Any communication with
L3 vendor is recorded and updated.

Output: L3 Vendor Engaged

Act Name: Update status of Ticket as

Act No: 8 Owner: L2 Team
‘Pending’
Description: Update ITSM to reflect that issue is raised to Vendor and set status of ticket to
“Pending” to stop SLA clock.
Output: Ticket status set to “Pending”

Document No: Sheet: 9 of 13

Revision No: Issue Date: xx-xxx-xx
 Incident Management Process
Act Name: Investigate and Diagnose
Act No: 9 Owner: L3 Vendor
Incident
Description: Carry out investigation and diagnosis activities to identify a workaround or
resolution for the issue. Update Incident with any investigation and diagnosis activities.
L2 continue to update based on updates provided by the L3 vendor.
Output: Resolution identified

Act No:
Act Name: Resolution provided Owner: L3 Vendor
10
Description: Apply resolution to resolve the Incident identified during the investigation and
diagnosis and inform L2 team about the resolution. If L3 Team doesn’t have access to the
respective system, L2 will apply the resolution provided by L3 Team.
Output: Resolution implemented

Act No:
Act Name: Verify Resolution Owner: Service Desk
11
Description: Verify resolution by contacting customer who raised the Incident, checking
alarm or other tests. L2 support might be involved at this stage if required. Tickets will be
transferred back to respective L2 team if user is not satisfied with the resolution.
Output: Resolution verified

Act No:
Act Name: Close Ticket Owner: Service Desk
12
Description: Incident Requester will close the Incident once issue resolution is verified to be
correct and customer is satisfied. The process also checks that the Incident record is fully
updated and assigns a closure category.

Output: Ticket closed

Document No: Sheet: 10 of 13

Revision No: Issue Date: xx-xxx-xx
 Incident Management Process

2.3 Process Flow – P1 / P2 (Critical Incident Management)

Start
Service Desk

Engage Update Outage Update Outage

Incident Board Board
Manager

Agree on update
Setup frequency (say Send Executive
Bridge 30 min or 1Hr.) Communication
Call L3 Support No
Required?
Update
Management Issue
Yes
Incident Manager

(also at agreed Resolved

frequency
Engage L3

Breached
SLA?
Response Yes No
Satisfactory? Yes

No Update SLA
Report
Escalate as per
escalation
matrix End

Document No: Sheet: 11 of 13

Revision No: Issue Date: xx-xxx-xx
 Incident Management Process

2.4 Process Description of Critical Incident Management (P1)

Responsible
Step Event Action
Group

Engage Incident Service Desk receives the P1 issue and

1 Service Desk
Manager informs Incident Manager about the Issue.

Incident Setup Technical Setup Bridge call to discuss the Issue and
2
Manager Bridge work out a plan

Update Outage Update the Outage Board with Issue

3 Service Desk
Board description and Business.

Incident Manager sends multiple

communications during the incident as per
Incident Agree on update
4 agreed frequency (It can be every 30 mins,
Manager Frequency
1 hour etc.) or when there is a change in
status that is worth updating.
Incident manager determines if L3 support
Incident is required?
45 L3 support required
Manager If yes, L3 support from OEM/ Third party
companies are involved.
If the response is satisfactory, information
is passed to (customer and service
Incident Response provider’s) service delivery manager
56
Manager satisfactory
Escalate as per the escalation matrix if the
response is not satisfactory
Incident If the SLA has breached, incident is
67 SLA breached
Manager updated in the SLA report

Incident If the issue is resolved, communication is

78 Issue resolved
Manager sent to the stakeholders

Incident Once the issue is resolved, the information

89 Update outage board
Manager is updated in the outage board

Incident Manager raises a problem ticket

Incident Raise a problem
910 for all critical incidents to do the RCA and
manager ticket
to identify the perm fix.

Document No: Sheet: 12 of 13

Revision No: Issue Date: xx-xxx-xx
 Incident Management Process

2.5 Key Contacts and Escalations

Phone Number/ Phone Number/

No. Key Contacts Title/ Department Escalate to Title/ Department
Email Id. Email Id.
1 <Name> <Name>

2 <Name> <Name>

Document No: Sheet: 13 of 13

Revision No: Issue Date: xx-xxx-xx