Incident Report Template | Major Incident Management
Incident Report in ITIL Incident Management
Incident reporting is one of most important phase in Major Incident Management. Incident report is an 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 a Incident Report ?
An incident report provides accurate and consolidated summary on an incident to the requester and higher-level management and to help the management, to make quick and wise decisions with the reports provided. Also, to record the information regarding the incident and lessons learnt. 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 ITSM tool/ Service Desk tool
- Major incident label should mention the values “Yes/ No”, referring if the incident is major incident or not.
- SLA Breached label should mention the values “Yes/ No”, referring if the incident breached the SLA or not.
- Need for exculpation label should mention the values “Yes/ No”, referring if the incident ticket has a valid reason for exculpation.
- Reason for 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 if the incident needed a bridge call to resolve the issue or not.
- Stakeholders involved in bridge call label should mention the details of the stakeholders 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 label 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
- 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
- Executive summary label should mention the brief overview of the incident in one line or few words
- Description of the incident label should mention the detailed description of the incident
- Timeline label should have the precise time details like incident inception, notification, recording in 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 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.
- 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 needs to happen
- Recommendation for corrective actions section should capture details of the corrective action description and the action owner
- 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
- Incident manager 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 the what went good and bad, after the incident report is reviewed.