Incident management

Incident management

Incident Management

An incident is an unplanned interruption to an IT service or a reduction in its quality. The failure of a configuration item that has not yet affected any service is also an incident (see also event management).

Process objective

Incident management deals with all incidents that impair, currently disrupt or could soon disrupt the agreed quality of an IT service and therefore its business benefit. Its primary objective is to restore the agreed service quality as quickly as possible.

Subject matter and scope of application

Incident management deals with all impending or actual impairments of an IT service from the perspective of its users.

The incident management process is triggered by events from the operational monitoring of the IT infrastructure and applications (see event management) or by fault reports from the users of an IT service to the IT service desk.

Not every user contact with the IT service desk necessarily involves a fault report; the user can also request information or place service orders. In the latter case, the request fulfilment process is triggered.

Finding and eliminating the cause of a malfunction is not one of the tasks of incident management. Its job is done as soon as the service is available to the user again in the promised quality. Problem Management is responsible for analysing and eliminating the causes of frequently occurring malfunctions.

Benefits for the university

The university's business processes are impaired as little as possible and for as short a time as possible by irregularities in its IT support.

Concepts and principles

Response time:

Response time is the time from receipt and recording of an incident to the first contact between the processor (incident handler) and the user. It is defined in the service agreement. An escalation takes place after the response time has expired.

Resolution time:

Resolution time is the period of time from the start of processing until the service is restored in accordance with the service level agreement (SLA, attribute 9). If the resolution time is not adhered to, an escalation takes place.

Roles:

Roles are used within ITIL V3 to define responsibilities. In particular, they are used to determine process owners for the various ITIL V3 processes; they also illustrate responsibilities for individual activities within workflows.

1st level support role:

The1st-level support agent registers and categorises incoming incident reports and immediately attempts to find a solution to restore the defined operating status of a service as quickly as possible.
If they are unable to restore the service, they forward the fault report to the specific processing group in2nd level support.

2nd level support role:

The processor in2nd levelsupport takes over fault reports from 1st level support that the latter was unable to resolve independently. If necessary, they will request support from manufacturers (3rd level support). Their aim is also to restore the defined operating status of a service as quickly as possible. If it is not possible to rectify the cause of the fault, the fault is passed on to Problem Management for further processing.

Role of3rd level support:

The processor in3rd-level support is typically based at a manufacturer of hardware or software products; they are involved by2nd-level support if this is necessary to rectify faults. The aim is to restore the defined operating status of a service as quickly as possible.

Incident manager role:

The Incident Manager is responsible for the effective implementation of the "Incident Management" process and the corresponding reporting system. They are the first escalation level for incidents that cannot be resolved within the agreed service level.

Activities and methods

Recording:

Formal recording of the fault report by the service desk. The trigger for a fault report is either an event from operational monitoring (see Event management) or a notification from a user by email or telephone.

Categorisation:

Is there a service disruption (violation of the SLA) or is it a service request? Is there an SLA violation that is being processed by the first or second level or is there a major incident?

Service request:

Request for a system change or a configuration change (example: setting up a user ID, setting up a group drive, setting up a web page). Depending on the type of request, it is sent to the relevant support unit for processing.

First-level support:

Simple SLA violations are processed in first-level support. The employee at the service desk can rectify such a fault without further assistance on the basis of the information and tools available to them.

Second-level support:

Second-level support deals with faults that cannot be resolved by first-level support. Second-level employees are specialists in certain technical topics and systems. They decide whether additional external support needs to be called in, whether a problem exists and whether the cause of the fault can only be rectified by a fundamental change (via a request for change).

Major incident:

A major incident occurs when a large number of users are affected by an SLA violation and the organisation's work is disrupted as a result.

Process key figures

Like every process, incident management is continuously evaluated and improved based on its process KPIs. IT services are currently orientated towards these key figures:

Resolution time:

Average time from receipt of an incident report to restoration of the disrupted service.

Resolution quality:

Rate of faults resolved within the time specified in the service agreement.

Resolution rate1st level:

Rate of incidents that were resolved in1st level support.

(Changed: 11 Feb 2026)  Kurz-URL:Shortlink: https://uol.de/p8646en
Zum Seitananfang scrollen Scroll to the top of the page

This page contains automatically translated content.