Free Cybersecurity Incident Report Template

A cybersecurity incident report is a written record of an event that threatened the security of your systems or your data. It documents what the team detected, which systems and accounts it touched, how people responded, and what remains open.

Unlike a physical accident, a digital event rarely has one visible moment. So the record has to rebuild a timeline from logs, alerts, and human observations rather than from a scene anyone can photograph.

Build the record during the response, not afterward. Details like a session ID or an alert timestamp rotate out of retention within days, and nobody can recover them later.

Open a cybersecurity incident report as soon as you suspect a problem, not once somebody confirms one. Waiting for certainty is how the useful evidence expires.

Start a record for events like these:

• A phishing email reaches staff, and somebody clicks or replies.
• Ransomware encrypts files, or a ransom note appears on a screen.
• An account logs in from an unexpected country, or at an odd hour.
• A laptop, a phone, or a backup drive goes missing.
• Cloud storage or a database sits open to the internet.
• A vendor tells you they suffered a breach touching your data.
• Someone emails sensitive records to the wrong recipient.
• Malware alerts fire on a server holding customer records.

Also open one for a contained event you handled in five minutes. Small, well-documented events reveal the weak control before a large one exploits it.

Tip: Log what you did during the response as you go, including the steps that failed. Response actions change the evidence, and an investigator needs to tell your activity apart from the attacker’s.

A cybersecurity incident report should let someone who was not in the room reconstruct both the event and your response. Cover these fields, and write unknown where you have no answer yet.

Detection and Reporter

Record who or what caught it: a monitoring alert, a staff report, a customer complaint, or a vendor notice. Then name the tool and the person.

Incident Type and Severity

Classify the event using whatever scale your team already uses. Consistency here is what makes trends readable six months out.

Affected Systems and Accounts

List the hosts, applications, mailboxes, and accounts involved, with identifiers rather than nicknames.

Data Involved

Describe the categories of data touched, roughly how many records, and whether any of it left your environment. Also note whether encryption applied.

Attack Vector and Indicators

Record how access happened, plus the indicators you gathered: sender addresses, domains, IP addresses, file hashes, or process names.

Timeline of Events

Enter each checkpoint with a date, a time, a time zone, and the source that establishes it.

Containment and Eradication Steps

Log every action taken, with timestamps and the person who took it. Include the steps that did not work, since they narrow the cause too.

Business Impact

Describe downtime, disrupted orders, affected users, and any workaround the business ran during the outage.

Third Parties Involved

Name any vendor, managed provider, insurer, forensics firm, or law enforcement contact brought in, and when.

Evidence Preserved

List log exports, disk images, and memory captures, plus where they sit and who has handled them.

Open Questions

Record what you still do not know. However, an honest gap is far more useful to a reviewer than a confident guess.

Reviewers read the timeline first, so build it deliberately. Therefore, every entry needs a date, a time, a time zone, and a source you can point to.

1. First activity you can attribute to the event, even if nobody spotted it then.
2. Detection — the alert, the report, or the moment someone noticed.
3. Escalation — who heard about it, and when.
4. Containment — isolating a host, disabling an account, or blocking a sender.
5. Eradication — removing access, resetting credentials, or rebuilding a system.
6. Recovery — restoring service, then confirming it stayed clean.
7. Closure — when you declared the event over.

Mark the gap between when something happened and when you learned about it. That interval, often called dwell time, is one of the most useful numbers this whole exercise produces.

Notification duties depend on the data involved, your industry, and where the affected people live. So treat notification as a decision to research during the response, never one to assume from a previous event.

Record these in the report rather than settling them alone:

• Which categories of personal data the event touched.
• Roughly how many people it affected, and where they are.
• Whether the data left your environment or stayed inside it.
• Any encryption or other control that left the data unreadable.
• Which contracts and insurance policies carry notice clauses.

Check your state’s official website, read your contractual notice obligations, and confirm expectations with your insurer. Notification windows can be short and they differ widely, so bring in an attorney early whenever personal data falls in scope.

Close out with a review that produces changes, rather than just a summary. Schedule it while the response is still fresh in everyone’s memory.

• What worked — the controls, alerts, and decisions that helped.
• Where you lost time — missing access, unclear ownership, or absent logs.
• Root cause — the control gap, not the person who clicked.
• Fixes — each with an owner and a due date.
• Detection gaps — the alert you wish had fired.

Then update your response plan and run a short tabletop exercise against the same scenario. Teams that rehearse an event they already lived through move faster the next time.

A cybersecurity incident report also builds institutional memory. Because memory fades, it answers questions your team can no longer answer six months on.