ITIL® Foundation Certification Notes : Service Operation : Processes
6.5.1 Incident Management Process
An incident is defined as an unplanned interruption to an IT service, a reduction in the quality of an IT service, or a failure of a CI (configuration item) that has not yet impacted an IT service.
Incident Management is responsible for progress of all incidents from reporting to closing – usually the responsibility of service desk.
A) Purpose of Incident Management Process
The purpose of Incident Management is to recover normal (i.e. agreed) service operation, as quickly as possible, after an incident has been detected / recorded.
B) Objectives of Incident Management Process
1) Make sure that standardized procedures and methods are used for prompt and efficient response, documentation, analysis, reporting of incidents and ongoing management
2) Communication and visibility of incidents should be improved.
3) Improve business perception of IT with the help of a professional approach so that incidents will be resolved and reported quickly.
4) Align incident management activities and priorities with those of the business.
5) Maintain the user satisfaction without losing the quality of IT services.
C) Scope of Incident Management Process Handle all incidents (event which disrupts, or which could disrupt, a service), either by service desk reports or event management tool alerts. Incidents are reported and/or logged by technical staff.
D) Basic Concepts
1) Incident: An incident is defined as an unplanned interruption to an IT service, a reduction in the quality of an IT service, or a failure of a CI (configuration item) that has not yet impacted an IT service.
2) Timescales: Timescales must be agreed for all incident handling according to their priority; this includes response and resolution targets. All support groups should be made fully aware of these timescales. The tool should be used to automate timescales and escalate the incident as required based on predefined rules.
3) Incident Model: An incident model is a template that can be reused for recurrent incidents. It can be practical to predefine 'standard' incident models and apply them when incidents occur. They contribute to a faster entry and a more efficient treatment.
4) Major Incident: define what constitutes a major incident and follow pre-defined procedures, need to inform users on the progress.
5) Incident Status Tracking:
Incident status tracking field value examples:
1) New - an incident is submitted but is not assigned to a group or resource for resolution.
2) Assigned - an incident is assigned to a group or resource for resolution.
3) In process - the incident is in the process of being investigated for resolution.
4) Resolved - a resolution has been put in place.
5) Closed - the user has agreed that the incident has been resolved and that normal state operations have been restored
6) Expanded Incident Life cycle: Detailed stages in the lifecycle of an incident. The stages are detection, diagnosis, repair, recovery and restoration. The expanded incident lifecycle is used to help understand all contributions to the impact of incidents and to plan for how these could be controlled or reduced.
7) Impact: A measure of the effect of an incident, problem, or change on business processes. Impact is often based on how service levels will be affected. Impact and urgency are used to assign priority
8) Urgency – a measure of how long it will be until an incident, problem or change has a significant impact on the business.
9) Priority – a category used to identify the relative importance of an incident, problem or change, based on impact and urgency. High priority (Priority 1) is given for an incident with high impact and high urgency.
E) Incident Management Process Activities
Lifecycle of Incidents are as follows:
1) Incident Identification – realize an incident before the user notices / reports with event management (a reactive process)
2) Incident Logging – log ALL incidents for service-level management reporting and problem management. Information may include:
a) unique reference number
b) incident category
c) impact, urgency and priority
d) steps to resolution and known errors
e) time from logging to closure
f) Activities undertaken to resolve the incident and when these took place.
g) Resolution date and time
h) Closure category, date and time
3) Incident Categorization – use a simple categorization for effective implementation
4) Incident Prioritization – consider business impact and urgency, to be completed in a pre-agreed time depending on the priority, may change during the lifecycle
5) Initial Diagnosis – the service desk to diagnose the fault and try to resolve it with the known error database (by problem management), incident models or other tools (incident matching)
6) Incident Escalation – the incidents are owned by service desk (need to track till closure).
a) Functional escalation – service desk unable to solve the incident within a given time.
b) hierarchic escalation – inform management of major incidents / incidents not progressing based on SLA target time
7) Investigation and Diagnosis – try to find out what has happened and how to resolve
8) Resolution and Recovery – test potential resolutions to ensure the incident has been solved without causing adverse consequences
9) Incident Closure – contact user to verify and review categorization, finish documentation. Closed incidents may be re-opened if the incident re-surfaces again. Any appropriate function can close the incident.
Figure: Lifecycle of incidents
F) Incident Management Process- Interfaces with other stages of ITIL Service Lifecycle.
1) Interfaces with Service Design
a) Service Level Management: The ability to resolve incidents in a specified time is a key part of delivering an agreed level of service.
b) Information Security Management: Providing security-related incident information as needed to support service design activities and gain a full picture of the effectiveness of the security measures as a whole based on an insight into all security incidents.
c) Capacity Management: Incident management provides a trigger for performance monitoring where there appears to be a performance problem.
d) Availability Management: Availability management will use incident management data to determine the availability of IT services and look at where the incident lifecycle can be improved.
2) Interfaces with Service Transition:
a) Service asset and configuration management:
Provides data used to identify and progress incidents and to assess the impact of an incident; also contains information on which categories of incident to assign to which support group.
In turn, incident management can maintain the status of faulty CIs. It can also assist service asset and configuration management to audit the infrastructure when working to resolve an incident.
b) Change Management:
Where a change is needed to implement a workaround or resolution, it will be logged as an RFC and progressed through change management.
In turn, incident management is able to detect and resolve incidents that arise from failed changes.
3) Interfaces with Service Operation:
a) Problem management:
For some incidents, it will be appropriate for problem management to investigate and resolve the underlying cause to prevent or reduce the impact of recurrence.
Incident management provides reporting point for these.
Problem management can provide known errors for faster incident resolution through workarounds to restore service.
b) Access management:
Incidents should be raised when unauthorized access attempts and security breaches have been detected
A history of incidents should also be maintained to support forensic investigation activities, resolution of access breaches.
Disclaimer:TutorialsWeb.com is neither associated nor affiliated with CompTIA® or any other company. A+™, Network+™, Security+™, Server+™ are trademarks of CompTIA® organization and duly acknowledged. The Cram Notes material is a copyright of TutorialsWeb.com and the same is not approved or endorsed by respective certifying bodies.