Home » IT Incident Management

IT Incident Management

Who Uses IT Incident Management?

Incident management is widely used by IT help desks around the world. Typically, the Help Desk is a single point of contact for end users to report problems to the IT Infrastructure Management department.

IT Incident Management Life Cycle

The incident management process includes the following steps:

Stage 1: Incident registration.
Stage 2 : Classification of the incident.
Step 3 : Assign priority to the incident.
Step 4: Incident Assignment.
Stage 5: Create and manage tasks.
Stage 6: SLA management and escalation.
Step 7: Providing a solution to the incident.
Stage 8: Closing the incident.

Incident Management Life Cycle

Depending on the type of incident, these processes can be simple or complex; in addition to the main process above, they can also include multiple workflows and tasks.

Incident registration
You can use phone, email, SMS, web forms published on the Self-Service Portal, and live chats to register an incident.

Incident classification

Depending on which area of ​​IT or business the incident affects, such as network, hardware, and so on, the incident can be assigned a category and a corresponding subcategory.

Assign priority to an incident
The priority of an incident can be determined using a priority matrix (degree of impact and urgency). Business Impact Degree refers to the extent to which the problem will cause damage to the user or organization. The urgency of an incident indicates the time frame within which the incident must be resolved. An incident can be assigned the following priority:

  • Critical
  • High
  • Average
  • Short
  • Incident routing and evaluation

Once an incident is categorized and prioritized, it is automatically forwarded to the appropriate technician with the required knowledge and skills.

Create and manage tasks

Depending on the complexity of the incident, the process of its elimination can be divided into several actions or tasks. Tasks are usually created when it is necessary to involve several specialists from different departments to develop a solution to an incident.

SLA management and escalation

When handling an incident, the technician needs to ensure that the SLA requirements are met. The SLA is the acceptable time within which an incident response (Response SLA) or resolution (Resolution SLA) is required. SLAs can be assigned to incidents based on parameters such as incident category, ticketer, impact, urgency, and so on. In the event that SLA requirements may be violated or have already been violated, the incident can be escalated to another specialist or to another level to ensure its prompt removal.

Providing an Incident Solution

An incident is considered resolved when a technician has provided a temporary workaround or a permanent solution to the problem.

Incident closure
After the incident is resolved and the user confirms that the solution worked and that they are satisfied with the result, the incident can be closed.

Overview of the consequences of the incident

After an incident is closed, it is a good idea to document all findings from the incident. This helps to prepare specialists for similar incidents in the future and organize a more effective incident management process. The incident impact review process can be divided into several steps, as described below. This is especially useful when dealing with major incidents.

Incident identification

  • Who discovered the incident and how did it happen?
  • How quickly was the incident discovered after it occurred?
  • Could the incident have been identified earlier?
  • Could any tools or technologies have been used to promptly or proactively detect the incident?
  • Transfer of information and communication
  • How quickly were stakeholders informed about the incident?
  • What channel was used to send notifications?
  • Were relevant stakeholders promptly informed of the current status of the incident?
  • How easy was it to contact end users to gather information and keep them informed about the status of the application?

Structure

  • What was the original structure of the incident response team?
  • Has this framework been followed throughout the incident management lifecycle? If not, why not? What changes
  • have been made to the structure?
  • Can the incident response team be organized more effectively? If so, how?

Resource usage

  • What resources were deployed to resolve the incident?
  • Have these resources been used optimally according to their capabilities?
  • How quickly were resources mobilized to address the incident?
  • Can resource use be improved in the future?