Incident Report Template Word | Major Incident Management Report | Sample IT Incident Management Report

An incident report template provides a snapshot of the incident that has occurred. An incident report can be brief or detailed, depending on the nature of the incident. A short report is good if the incident is minor and does not have a huge impact. But if the incident is significant, then all the details need to be captured; hence we need a detailed major incident management report. 

Access This Template With Our ITSM Bundle

Why Do You Need An Incident Report?

Incident reporting is one of the most important phases in Major Incident Management. An incident report is authentic and authorized information written in Incident Report Template, explaining the complete details of an incident like what is the incident about, when did the incident occur, where did the incident occur etc. 

It also documents what is the time taken to resolve the incident, who resolved the incident, who all have handled the incident (how many functional and horizontal escalations have happened), what troubleshooting steps were taken to resolve the issue, and what customer satisfaction score was received on resolving the incident.

An incident report template provides an accurate and consolidated summary of an incident to the requester and higher-level management and to helps the management, to make quick and wise decisions with the reports provided.  Also, to record the information regarding the incident and lessons learned. This incident report template information will be useful for bringing awareness to the management and it improves (effectiveness & efficiency) the IT incident management operations.

How To Write An Effective Incident Report ?

Writing an incident report is like writing an investigation summary. Anyone writing a report will need to interview people involved in the incident, read through the emails, understand the impact, and finally get to the incident's root cause. Having an Incident Management Process is critical to ensuring there is a consistent approach to managing incidents. 

1. Understand The Incident: As a first step, understand the details about the incident like start time, end time, users impacted, what systems were down, etc. 
2. Review The Artifacts And Communications: In this step, review the service desk tickets, emails sent, outage comms, and any other relevant processes. 
3. Conduct Incident Reviews: Meet with the incident management team, stakeholders, and impacted staff to understand firsthand observations.
4. Conduct Root Cause Analysis( RCA) - You need to understand the exact root cause of the issue which caused the incident. It could be human error, mechanical failure, or a system glitch. 
5. Publish Your Incident Report: The final report must contain all the information gathered during the analysis and published to all the key stakeholders. 

Access This Template With Our ITSM Bundle

How To Use The Incident Report Template ?

• Report By label should have the details of the person/ persons who prepared the report.
• Report Date label should mention when the report was created.
• Incident Number label should mention the unique ID assigned by the ITSM tool/ Service Desk tool.
• The Major Incident label should mention the values “Yes/ No”, referring if the incident is a major incident or not.
• SLA Breached label should mention the values “Yes/ No”, referring to if the incident breached the SLA or not.
• The Need For Exculpation label should mention the values “Yes/ No”, referring to if the incident ticket has a valid reason for exculpation.
• The Reason For The Exculpation label should describe the detailed reason explaining why the incident ticket should be exculpated.
• Bridge Call Initiated label should mention the values “Yes/ No”, referring to if the incident needed a bridge call to resolve the issue or not.
• Stakeholders Involved In The Bridge Call should mention the details of the stakeholder’s SME, Position, Contact number, and contact email.
• Incident Start Time label should mention the time when the incident started.
• Incident End Time label should mention the time when the incident ended.
• Business Services Impacted label should mention the impacted business services.
• Affected Configuration Items label should have the details of the CI’s that have got affected.
• Caller Details label should be populated with caller/user details like user or employee name and number
• Date And Time When The Incident Was Reported By The User should be populated with date & time when the incident was reported by the user.
• Location label should mention the sites and locations which were affected by the incident
• Category And Subcategory labels should mention the category and subcategory of the incident as segregated in the process and tool.
• Problem Number label should be mentioned with problem ticket number associated with the incident.
• Change Number label should be mentioned with change ticket number associated with the incident.
• The Priority Of The Incident should be mentioned with the overall priority, which is generally calculated on the basis of impact and urgency
• Impact label should mention the assigned impact.
• Urgency label should mention the assigned urgency.
• The Executive Summary label should mention a brief overview of the incident in one line or a few words.
• Description Of The Incident label should mention the detailed description of the incident.
• The Timeline label should have precise time details like incident inception, notification, recording in the tool, etc.
• Number Of Hours label should mention the total number of hours and minutes it took to service restoration.
• Chronological Analysis label should mention the chronology of events/ errors that lead to an incident.
• Service Providers Involved label should mention the different vendors involved in resolving the incident.
• Technical Details label should mention the technical details of the incident like logs, errors, event numbers, Knowledge base article numbers used for resolving the issue, details of troubleshooting.
• The Post-Incident Analysis should mention the analysis that is conducted after the incident resolution and closure. It should capture the details like: primary, secondary, and contributing causes using 5 why analysis, Ishikawa diagrams, etc.
• Recommendation For Corrective Actions section should capture details of the corrective action description and the action owner
• The Incident Report Approval section should capture the details of the service provider name, incident manager name, service delivery manager name. 

Importance Of Having A Incident Management Guide

One thing about incidents is that they can happen at the worst of times. The key is to have a step by step plan in incident management when dealing with incidents.

• The incident management guide tells the team what needs to happen and when.
• The guide shows the detailed steps that the teams need after a specific time.
• The guide suggests when the team should send the first response.
• The guide also indicates when the team should start sending regular updates.
• There are helpful hints on the guide throughout the process.
• Also, it highlights the steps like closing the ticket and PIR, which get forgotten. 

Access This Template With Our ITSM Bundle

Managing Communications During An Incident

One of the toughest challenges when managing incidents is to communicate with the stakeholders. For any communication to be successful, it is essential to maintain consistency.

Using pre-defined email templates for communications takes a lot of stress away as the incident manager needs to focus on filling in the already defined information. That is why using a pre-defined template is time-saving and valuable. Our Major Incident Management Notification Template contains four different sections. The first section contains key details like incident number, incident manager, bridge details, priority, start and end time, etc.

The incident details section has a piece of additional information about the incident. An incident manager or resolution manager can write technical details and provide any information on the root cause if available. 

The business impact section lists all the impacted business systems and users. It can also mention the severity of the impact and any significant issues or data breaches. 

The incident timeline should contain the events for the incident. It is best to have a time and a brief description of the event. This information is useful when documenting the incident report.

 Access This Template With Our ITSM Bundle

Best Practices For Incident Reporting

• Every incident report should be identified with a unique registration number.
• Incident reports should be generated for all major and new (that have never occurred before) incidents.
• Create the incident report for every major incident for every new incident, for incidents that have breached/ escalated/ filed complaint by the customer.
• Don’t fill the report based on assumptions
• Include only relevant details
• The incident managers should not be engaged only as an escalation point or for escalations.
• It is a very common bad practice in organizations that incident managers are only used as escalation points, for managing escalations, or for doing follow-ups.
• Incident managers should also be involved in diagnosis and resolution which will enable the team to provide quicker solutions.
• Management should conduct meetings to discuss what went well and bad after the incident report is reviewed.

Categorizing And Prioritizing Incidents

• One of the key focus areas for incident management is categorizing and prioritizing incidents.
• The incident priority template helps to define how soon this incident should be triaged and resolved.
• Different companies have different terminologies and thresholds for how they categorize incidents. But almost all the time, the terms are interchangeable.
• For example, Po/Critical might mean the incident is the highest priority as it essentially is a show stopper. P1/High/Medium might mean it has an impact, but still, some people can use the system. P2/Low means the incident is of low impact. 
• Incident Urgency is the degree of importance or significance that we attach to an event. It can be described as the sense of how much time and effort we should put into doing something about a situation.
• A significant incident is outlined as any event which can cause severe disruption to the conventional running of the organization. The subsequent square measure indicates that an active warrant is being treated as a serious incident: impact on workers and the way they are doing their work, impact on customers, service users, or business partners, the potential of severe consequences, and potential media impact on name and operations.

Access This Template With Our ITSM Bundle