IT Incident Report Template (Free Word + Excel Log)

An IT incident report template is a ready-made form for recording what happened when an IT service broke or a security event hit: when it was detected, how severe it was, which systems, devices and people were affected, what was done to contain and fix it, the root cause, and who signed it off. This one is for IT and security incidents, such as outages, software and hardware failures, access problems, data mistakes and security events. It is not for workplace injuries or HR complaints.

You get a Word report with a fillable form, a blameless post-incident review, a short security incident addendum and a filled-in technical incident report for a fictional outage; the same report as a PDF; and an Excel incident log that works out the time to acknowledge and resolve each incident, flags missed targets, missing postmortems and recurring problems, and sums it all up on a dashboard.

Download the template (Word, Excel + PDF)

What Is an IT Incident Report?

An IT incident is an unplanned interruption to an IT service, a drop in its quality, or a security event that harms or could harm your systems or data. The incident report is the written record of one incident. It answers five questions: what happened, how bad was it, what did we do, why did it happen, and what will we change.

Three documents often get mixed up:

In ITIL 4 terms, getting the service back belongs to the incident management practice, and finding and removing the underlying cause belongs to problem management. NIST SP 800-61 Rev. 3, the US guidance on cybersecurity incident response revised in April 2025, draws a similar line: incident reports are triaged, incidents are categorized and prioritized, the root cause is analyzed, and lessons learned feed back into improvement.

What to Include in an IT Incident Report

The template's report form has seven parts. Each one matches a question someone will ask later, whether that is your manager, a customer or an auditor:

Write the description for someone who wasn't there: a new team member reading it in a year should understand what broke, why, and what changed. Leave out blame and jargon, and mark guesses as guesses until they are confirmed.

Incident Severity Levels: SEV1 to SEV4

Severity decides who gets called and how fast. Many teams use four levels, named SEV1 to SEV4 or P1 to P4. The template's levels and targets are examples, so set your own and agree them with the business:

Two habits keep severity useful. Decide it on impact, not on how hard the fix looks. And change it when you learn more: a lost laptop logged as SEV3 because it was encrypted becomes SEV2 if it turns out it wasn't. The Excel log reads the targets from its Settings tab and flags every incident that missed its acknowledge or resolve target, including open ones that are running late.

Incident Categories

Categories show patterns over time: is it mostly outages, access problems or security events? Six cover most IT teams:

Some incidents fit two categories. Ransomware that takes the file server down is both a security incident and an outage. Pick the one that drives the response and mention the other in the description. A software incident report or a system outage report uses the same form; the security addendum is for anything with an attacker or exposed data in it.

How to Write an Incident Report, Step by Step

The report is written during the incident, not afterwards from memory. These steps follow the form:

1. Open it straight away. Give the incident an ID and a row in the log as soon as someone declares it. The report grows as the response goes on.
2. Name one incident owner. One person leads and keeps the record, while others work on the fix.
3. Keep the timeline. Write down every event and action with its time, copied from logs, tickets and chat. NIST SP 800-61 Rev. 3 asks that actions during an investigation are recorded and that incident data is kept with its integrity and provenance.
4. Set the category and severity, and change them when the facts change.
5. Record scope and impact: the systems, devices and users affected, and what it meant for the business.
6. Write down containment and resolution, each with a time, and who confirmed the service works again.
7. Work out the time measures from the timeline.
8. Record every notification: staff, management, customers, partners, regulators, insurers.
9. Close with actions and sign-off. Each action gets one owner and a due date, and the approver signs when the report is complete.

Time to detect runs from the start of the problem to when someone noticed it. Time to acknowledge runs from detection to someone owning the incident, and time to resolve from detection to the service working again. Averaged over many incidents they become MTTD, MTTA and MTTR. MTTR is used for repair, recovery and resolve, so the template says which one it measures: resolve, counted from detection.

Technical Incident Report Example

Here is the filled-in example from the download, for Example Co (fictional), a made-up 250-person distributor. A planned firewall change on a Monday morning cut remote staff off the VPN:

The full example in the Word file and the PDF adds the timeline with a source for every entry, the postmortem summary, five whys and four actions with owners and dates. Note what it leaves out: no names in the root cause, no "human error" as the answer. The cause is a missing test step and three copies of the rule set, which are things the team can fix. Because the cause was a change, the actions also go into the IT change management template.

Post-Incident Review: Blameless Postmortem Template

The incident report records what happened. The post-incident review, also called a postmortem, a retrospective or an incident response report, asks what to change. The template suggests one for every SEV1 and SEV2, held within about five working days while memories are fresh. It follows four rules:

• Blameless: describe what the system and the process allowed, not who to blame. People act on the information they had at the time.
• Facts first: build the timeline from logs, tickets and chat before anyone gives an opinion.
• Every finding ends in an action with one owner and a due date, and the actions go into the incident log's Action Items tab.
• Hold it within [5 working days] of resolution for SEV1 and SEV2, while memories are fresh.

The review form covers the summary, impact, how the incident was found and how fast, what went well, what didn't, where you got lucky and the contributing factors. The root cause comes from five whys. In the example:

1. Why couldn't remote staff connect? The firewall had no rule allowing VPN traffic.
2. Why was the rule missing? The change replaced the whole outside rule set with a copy that was three months old.
3. Why was an old copy used? The current rule set is not kept in one agreed place, so the network lead used the last saved file.
4. Why wasn't it caught before staff noticed? The change plan had no test step for remote access and no check after the change.
5. Why was there no test step? The change template has no section for testing services that depend on the system being changed.

NIST SP 800-61 Rev. 3 treats this as part of improvement: lessons from incident response are identified, analyzed and used to update plans and controls. In practice, that means every finding ends in an action. The log's Action Items tab flags overdue actions, and the Incident Log flags any incident whose severity needs a postmortem when none is marked done within the days you set.

Security Incident Reports: What Changes

A security incident report uses the same form, plus a one-page addendum with the questions that decide what happens next:

• Data: was personal or confidential data involved, which categories, how many people or records, and was it encrypted?
• Containment of accounts and devices: which accounts were disabled and which passwords and sessions reset; which devices were locked, wiped or taken off the network.
• Evidence log: each item, its source, who collected it and when, where it is stored and a hash or ID. Collect before you change or wipe a system where you can, and record each hand-over. ISO/IEC 27001:2022 covers this as Annex A 5.28, collection of evidence.
• Notification decision: whether the authority, the people affected or customers must be told, by when, decided with counsel.

When personal data may be involved, the incident report is where the facts start, and the data breach response plan takes over: it is the playbook for containment, assessment and notification, while this report is the form you fill in along the way. Deadlines are strict. Under NIS2 Article 23, essential and important entities send an early warning within 24 hours of becoming aware of a significant incident, an incident notification within 72 hours and a final report within one month; the breach plan sets out these and the GDPR deadlines. Our data breach notification policy template covers who to tell and when, and what to do after a company data breach walks through the first days. Check every notification decision with counsel.

IT Incident Log and Tracking Template (Excel)

A report covers one incident; the log shows the pattern. Together they are the incident management template most small IT teams need. The Excel workbook has seven tabs:

• Incident Log: ID, opened, category, severity, system, owner, status, and the detected, acknowledged and resolved times. It works out the time to acknowledge (minutes) and the time to resolve (hours), looks up the targets for the severity, and flags Ack SLA missed, Resolve SLA missed, Postmortem due or overdue, Open too long and Recurring system (three or more incidents on the same system in 90 days, by default).
• Action Items: every action with its owner and due date, flagged Overdue, No owner or Not in log.
• Settings: the severity targets, which severities need a postmortem, and the thresholds for the flags.
• Example, Dashboard and Sources: a filled-in log for the made-up company, headline numbers with incidents by severity (with MTTA and MTTR), by category and by month, and the framework references.
• Start Here explains each column. Formulas only, no macros.

The Example tab shows why the log is worth keeping. Of 12 incidents, 5 missed a target, 1 SEV2 has no postmortem past the deadline, and 2 incidents are flagged as recurring: the ERP system had three incidents in under a month, which is a problem record waiting to be opened. Mean time to acknowledge is 59 minutes and mean time to resolve 10.3 hours, and 2 actions are overdue.

Incident Reporting in NIST, ISO 27001, SOC 2 and ITIL

Every major framework expects incidents to be reported, assessed, handled and learned from, with records to show it. The template's mapping table (section 5) points each part of the report to these references:

Auditors usually ask for the incident procedure, a sample of incident reports with timelines and sign-off, postmortems with their actions closed, and the log. The mapping is a general guide; your auditor decides what counts for your scope.

What's in the Download

• Word report (IT-Incident-Report-trio.so.docx): the incident report form with severity levels, categories, a timeline, follow-up actions and sign-off; a blameless post-incident review with five whys; a security incident addendum with an evidence log; a filled-in technical incident report; and a framework mapping. Fillable fields throughout.
• PDF (IT-Incident-Report-trio.so.pdf): the same form, review, addendum and example, ready to print.
• Excel incident log (IT-Incident-Log-trio.so.xlsx): incident log with time to acknowledge and resolve and its flags, action items, settings, a filled-in example, a dashboard and sources. Formulas only, no macros.

Get the report, example and incident log

Where trio.so Fits

trio.so does not detect incidents or watch your network for attacks, and the incident report stays your team's record. What trio.so adds is evidence and context from the device side: which devices were involved, what state they were in, what was done on them, and the actions that contain a lost or compromised device. For that device side, trio.so gives you:

• A device inventory with each device's owner, serial number, operating system, installed apps and encryption status, to fill in the affected devices section.
• Per-device policy status that shows whether each policy applied, failed or is still pending, to record a device's state at the time of the incident.
• Patch findings with CVSS severity, EPSS and CISA KEV for each CVE, to note which known vulnerabilities an affected device carried.
• An audit trail of console activity (who did what, when and with what outcome) that you can filter and export, and an activity history on each device, as sources for the timeline.
• The Microsoft Defender for Endpoint integration, which brings Defender's devices and their open alerts into trio.so, listed per device.
• Remote lock of company-owned Macs, iPhones, iPads and Android devices, and remote wipe of company-owned devices, to contain a lost or compromised device.
• User sync from Entra ID and Google Workspace with SCIM 2.0 deprovisioning, and console roles, to cut off an account that was compromised.
• Remote desktop and terminal in every plan, to look at an affected device or help its user while the incident is open.

It covers Windows, macOS, Linux, iOS/iPadOS and Android from one console. Plans start at $5 per device.

Start free trial Book a demo

14-day free trial. No credit card required.

Related Templates

• Data breach response plan template: the playbook for containment, assessment and notification when personal data is involved.
• Data breach notification policy template: who to notify, and when.
• IT contingency plan template: getting IT systems back after a disruption.
• IT change management template: for incidents caused by changes, and the fixes that follow.
• What to do after a company data breach: the first days after a breach.
• Data breach prevention: controls that stop incidents before they start.
• IT risk management: feeding incident patterns into your risk register.
• Patch management policy template: closing the vulnerabilities incidents expose.
• Access control policy template: who gets access, and how it is removed.
• IT service request form template: for everyday requests that are not incidents.
• Cybersecurity tabletop exercises: practicing the response before a real incident.

Sources. Last reviewed November 2026. Framework references are general pointers to NIST SP 800-61 Rev. 3, ISO/IEC 27001:2022, the AICPA Trust Services Criteria, the NIS2 Directive and ITIL 4; the wording of every section is ours. trio.so is not affiliated with or endorsed by NIST, ISO, the AICPA or PeopleCert.

• NIST SP 800-61 Rev. 3 (CSRC publication page)
• ISO/IEC 27001:2022 (ISO catalogue page)
• AICPA Trust Services Criteria
• Directive (EU) 2022/2555 (NIS2), EUR-Lex