How to Report an IT Incident: A Practical Guide
An IT incident report form turns a chaotic event, a server crash, a malware alert, a suspected data breach, into a structured record that can be managed, investigated, and learned from. When something breaks or looks compromised, the instinct is to fix it fast. The form doesn’t slow that down; it makes sure the fix is informed and the facts are captured before they evaporate. This guide explains how to use the IT Incident Report Form properly.
When to Use This
Use the form for any unplanned event that affects IT services or security: system outages, hardware failures, malware detections, suspected unauthorised access, lost or stolen devices, phishing reports, and data incidents. The threshold is deliberately low. It’s far cheaper to file a report on something that turned out to be minor than to discover later that a serious incident was handled by chat message and memory.
Time matters most at the start. The person who discovers the incident should complete the initial sections immediately, within the hour, even if some details are unknown. Facts decay quickly: exact times, error messages, and who was affected are much harder to reconstruct the next day. The form can be updated as the investigation progresses; the first version doesn’t need to be complete.
How to Fill It Out
Section 1: Incident identification. Assign a reference number and record the date and time the incident was detected, when it actually started (if different), and who reported it with their contact details. Also record how it was detected, user report, automated monitoring, security alert, or discovered during routine work. Detection method is diagnostic: if most incidents come from user reports, your monitoring has gaps.
Section 2: Description of the incident. Describe what happened in factual, neutral language: what systems or data are involved, what symptoms were observed, and the exact error messages or alert text. Avoid conclusions at this stage, “the server was hacked” is a conclusion; “unauthorised login attempts from an unknown IP address were logged at 02:14, followed by an unexpected service restart” is a description. Conclusions belong in the investigation section, after evidence has been gathered.
Section 3: Impact assessment. Which services are affected, how many users, and what business functions are disrupted. Rate the severity using your organisation’s scale (critical, high, medium, low), and define that scale somewhere your team can find it, so severity ratings are consistent. Include whether customer or employee personal data may be involved; if it might be, flag it prominently, because data incidents carry their own reporting obligations.
Section 4: Immediate actions taken. What was done to contain the incident: systems isolated, services restarted, accounts disabled, users notified. Record the time of each action and who took it. Also record what was not done and why, for example, “did not wipe the machine; preserved for forensic review.” In the heat of the moment, containment steps that destroy evidence are a common regret.
Section 5: Investigation and root cause. Who investigated, what they found, and the root cause once determined. Be honest here: “root cause unknown, under review” is acceptable as an interim state; a guessed cause presented as fact is dangerous. Link to supporting evidence, log excerpts, screenshots, vendor case numbers.
Section 6: Resolution and follow-up. How the incident was resolved, the date and time service was restored, and the preventive actions agreed: patching, configuration changes, process updates, training. Each follow-up action needs an owner and a deadline, or it won’t happen. Close the incident only when the follow-up actions are done, not when the symptoms disappear.
Common Mistakes
1. Waiting to file. The report gets written two days later “when things calm down,” by which time the timeline is guesswork. File the first version immediately and update it. An imperfect early record beats a polished late reconstruction.
2. Mixing facts and speculation. Writing “caused by a phishing email” before anyone has checked is how wrong lessons get institutionalised. Keep a clear line between observed facts and working theories, and correct the record when evidence comes in.
3. Destroying evidence during containment. Reimaging an infected machine before capturing logs, or deleting a compromised account before reviewing its activity. Contain first, but preserve evidence before remediation wherever the incident may need investigation.
4. No follow-up actions. The incident is fixed, the ticket is closed, and the underlying cause, the unpatched system, the missing backup, the user who never got security training, waits to cause the next incident. The report isn’t complete until preventive actions have owners and deadlines.
Who Needs to Sign Off
The person who reported the incident and the IT staff member who managed it both sign the factual sections. For high-severity incidents, especially any involving potential data compromise, IT management (or the business owner) signs off on the resolution and the follow-up plan. If personal data may be affected, involve whoever is responsible for data protection decisions, since external reporting obligations may apply.
How Often to Review and Update
Keep individual incident reports for at least 12–24 months; they form the evidence base for audits and trend analysis. Review the incident register quarterly: look for repeat causes, systems that keep appearing, and follow-up actions that slipped. Review the template annually to make sure the severity scale, escalation contacts, and reporting obligations still reflect your organisation and current regulations.
Download the free IT Incident Report Form template.
Disclaimer: incidents involving personal data may trigger notification obligations under data protection law, which varies by jurisdiction and can carry strict deadlines. This guide is general information, not legal advice. Check your local regulations and involve your data protection contact promptly when personal data may be affected.