About Incident Management

Incident Management includes any event which disrupts, or which could disrupt a service. This includes events communicated directly by users through the Service Desk or an interface from Event Management to Incident Management tools.

Goal

The primary goal of the Incident Management process is to restore normal service operation as quickly as possible and minimize the adverse impact on business operations, thus ensuring that the best possible levels of service quality and availability are maintained. ‘Normal service operation’ is defined here as service operation within SLA limits.

Objectives

The objectives of incident management are:

Provide a consistent process to track incidents that ensures:
Incidents are properly logged
Incidents are properly routed
Incident status is accurately reported
Queue of unresolved incidents is visible and reported
Incidents are properly prioritized and handled in the appropriate sequence
Resolution provided meets the requirements of the SLA for the customer

Definitions

Field Description
Input Value

Impact is determined by how many personnel or functions are affected.

There are three grades of impact:

3 - Low – One or two personnel. Service is degraded but still operating within SLA specifications.

2 - Medium – Multiple personnel in one physical location. Service is degraded and still functional but not operating within SLA specifications. It appears the cause of the incident falls across multiple service provider groups.

1 - High – All users of a specific service. Personnel from multiple agencies are affected. Public-facing service is unavailable.

The impact of an incident will be used in determining the priority for resolution.

Incident

An incident is an unplanned interruption to an IT Service or reduction in the Quality of an IT Service. Failure of any Item, software or hardware, used in the support of a system that has not yet affected service is also an Incident. For example, the failure of one component of a redundant high-availability configuration is an incident even though it does not interrupt the service.

An incident occurs when the operational status of a production item changes from working to failing or about to fail, resulting in a condition in which the item is not functioning as it was designed or implemented. The resolution for an incident involves implementing a repair to restore the item to its original state.

A design flaw does not create an incident. If the product is working as designed, even though the design is not correct, the correction needs to be in the form of a service request to modify the design. The service request may be expedited based on the need, but it is still a modification, not a repair.

Incident Repository

The Incident Repository is a database containing relevant information about all Incidents whether they have been resolved or not. General status information along with notes related to activity should also be maintained in a format that supports standardized reporting.

Priority

Priority is determined by combining the incident’s impact and severity. For a full explanation of the determination of priority, refer to the paragraph titled Priority Determination.

Response

Time elapsed between the time the incident is reported and the time it is assigned to an individual for resolution.

Resolution

Service is restored to a point where the customer can perform their job. In some cases, this may only be a work around solution until the root cause of the incident is identified and corrected.

Service Agreement

A Service Agreement is a general agreement outlining services to be provided, as well as costs of services and how they are to be billed. A service agreement may be initiated between Virima Inc and another agency. A service agreement is distinguished from a Service Level Agreement in that there are no ongoing service level targets identified in a Service Agreement

Service Level Agreement

Often referred to as the SLA, the Service Level Agreement is the agreement between Virima Inc and the customer outlining services to be provided, and operational support levels as well as costs of services and how they are to be billed.

Service Level Target

Service Level Target is a commitment documented in a Service Level Agreement. Service Level Targets are based on Service Level Requirements. They are needed to ensure that the IT Service and meets the original Service Level Requirements.

Severity

Severity is determined by how much the user is restricted from performing their work.

There are three grades of severity:

3 - Low - The issue prevents a user from performing some of their duties.

2 - Medium - The issue prevents the user from performing critical time-sensitive functions.

1 - High - A service, or a major portion of a service, is unavailable. The severity of an incident will be used in determining the priority for resolution.

 

Related Topics

Categorization, Priority Determination and Target Times
Dashboard
Incident Policy
Incidents
Process Flow