ITIL Incident Management Process Template

Incident management is one of the most crucial aspects of ITIL.

When a service is disrupted or fails to deliver the promised performance during normal service hours, it is essential to restore the service to normal operation as quickly as possible.

Thankfully, there is a clear, optimized process to handle service disruptions that enable IT teams to communicate effectively and resolve almost any incident without unnecessary delays.

In this Process Street checklist, we have adapted the standard process flow to fit our super-powered checklists format.

What this means is you can complete and review the entire process in real-time, approve tasks as needs be, store and link to important data such as incident tickets, and focus only on what needs to be done in your specific situation thanks to our conditional logic feature which will customize the checklist depending on the severity of the incident.

Its the simplest, most effective way to resolve incidents and maintain data integrity.

Let's get started.

A little info about Process Street

Process Street is superpowered checklists. By using our software to document your processes, you are instantly creating an actionable workflow in which tasks can be assigned to team members, automated, and monitored in real-time to ensure they are being executed as intended, each and every time.

The point is to minimize human error, increase accountability, and provide employees with all of the tools and information necessary to complete their tasks as effectively as possible.

Once they've approved the document, it's then time to do what you do best: Supply great services to paying customers!

Ensure the incident has been logged as an "Incident Record" within your ITIL system.

This way the incident's status can be tracked, and a complete historical record maintained. 

The ticket should include information such as the user's name and contact information, incident description, and the date and time of the incident report

If possible, incidents should be matched to other Incidents, Problems, and Known Errors to keep data well organized.  

Categorizing and prioritizing the incident is critical to determining how the incident will be handled. 

Categorization allows the service desk to efficiently sort incidents based on their categories and subcategories, and can also trigger automatic prioritization. This is particularly important if it is a major incident that requires an urgent response.

Note-down the category of the incident below as well as in your ITIL system. 

Next, prioritize the incident. 

This is determined by two key factors:

1. Incident urgency
2. Impact on users

In short, urgency is how quickly a resolution is required, and impact is the extent of the potential damage the incident may cause as long as it stays unresolved. 

Enter the levels of priority in the form fields below.

Depending on your system, you can either determine a single level of priority by weighing up both factors or you can use the priority matrix (displayed below). 

Now its time to make an initial diagnosis of the incident and hopefully resolve the issue without having to seek support escalation and delay the resolution of the incident. 

The first thing to do is run through standard troubleshooting questions to see if there is a simple, known solution that can be applied. 

So it's been identified that this is not a simple, previously experienced incident. 

Therefore, a thorough investigation needs to be conducted to understand what's going on.

Once you have completed the investigation, it will be clear whether or not support escalation is required to resolve the incident.  

Use the text field below to enter notes from the investigation

What is causing this incident?

What needs to be done in order to resolve the incident as soon as possible?

Write down the initial hypothesis below.

Now, determine whether or not the incident needs to be escalated to the next tier of support staff. The required support may be functional, hierarchical, or both. 

Most incidents should be resolved by the first tier of support staff and should not make it to the escalation step. 

Contact the relevant personnel to receive support as soon as possible. 

A typical example of functional support is sending an on-site technician or seeking assistance from certified support staff. 

Contact the relevant personnel needed to receive hierarchical support. 

A typical example of defined escalation levels in terms of hierarchy is:

• 1st level support
• Incident manager
• Manager of data processing center
• CIO

Test the initial hypothesis to confirm whether or not it is correct. 

Initial hypothesis: {{form.Initial_hypothesis_following_investigation}}

Determine the final diagnosis so that staff can apply a solution whether it be changing software settings, applying a software patch, ordering new hardware, or whatever else may be required to fix the issue.

At this stage, the incident should be resolved and the service desk confirms that the user's service has been restored to the required SLA level. 

Before closing the ticket, its important to make sure that the initial classification details are accurate for future reference and reporting. 

Maintaining data integrity must not be overlooked once the incident has been resolved. Details still need to be checked to make sure the closed ticket is completely accurate. 

Link to incident ticket: {{form.Link_to_incident_ticket}}

Good work! Now that the incident has been resolved and data integrity has been verified, you can go ahead and close the ticket. 

• Anthony Orr - The Essential Guide to ITIL Incident Management
• Lucidchart - How to Implement a Succesful ITIL Incident Management Process
• ITSM Solutions - How to Classify Incidents
• BMC - ITIL Incident Management: An Introduction
• Wik Process Maps - Incident Management
• Wiki Process Maps - Checklist Incident Priority
• ManageEngine - The Definitive Guide to ITIL Incident Management

• ITIL Problem Management Process Template
• ITIL Change Management Process Template
• ITIL Request for Change (RFC) Template
• ITIL Release Planning Template
• ITIL Post Implementation Review Template
• ITIL Access Management Process Template
• ITIL Continual Service Improvement Template
• IT Service SLA Management Checklist Template
• Cloud Service SLA Management Checklist Template
• IT Service SLA Metrics Tracking Process Template
• Cloud Service SLA Metrics Tracking Process Template
• Inventory Management Process
• Network Security Management
• Client Data Backup Best Practices
• Computer Maintenance Guide
• Ubuntu Server Setup Process
• Virtual Private Server Setup
• IT Support Process
• Helpdesk Management
• Server Maintenance
• Server Security
• Information Security Incident Response
• SQL Server Audit Checklist