Incident Report Template | Major Incident Management
Incident Report in ITIL Incident Management
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, 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.
Why do you need an Incident Report?
An incident report 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 information will be useful for bringing awareness to the management and it improves (effectiveness & efficiency) the IT incident management operations.
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 label should mention the details of the stakeholder’s SME name, 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 label should be populated with date and 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 label should be mention with the overall priority of the incident, 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 label 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.
- what additional actions or research need to happen
- 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
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.