Free Cyber Incident Report Form and Incident Log Template

These forms are how [Company Name] (the "company") records a suspected cybersecurity incident from the first report to closure, so that facts, decisions, and evidence are written down once, in one place, and in the same way every time. They support the company's incident response plan, where adopted, and use its severity levels and roles. If they conflict, the stricter requirement applies, and legal counsel resolves any question about notification.

When to use them. Start an Initial Incident Report for any suspected incident, even if you are not sure it is real: a suspicious link that was clicked, a ransom note, an unexpected change to payment details, a lost or stolen device, information sent to the wrong person, or an alert from the managed IT provider. A report that turns out to be harmless is closed in minutes. A report that was never written cannot be rebuilt later.

How to report. Report to the Incident Response Lead through a phone call to the reporting number, the 24/7 reporting line, telling a manager or the reporting contact in person, or an urgent ticket with the IT help desk. Call first for anything urgent and write the form afterward. Report even if you made the mistake yourself. No one will face retaliation for a good-faith report.

Writing rules. Write facts, not guesses, blame, or legal conclusions. For each entry, say how you know it: what you saw, a screenshot, a log, or a phone call. Record every date and time in Eastern Time, and note when a time comes from a device whose clock may be wrong. Never erase or overwrite an entry: strike it through with one line, then initial and date the correction.

Framework. The forms are designed to support the documentation practices in NIST Special Publication 800-61 Revision 3, which recommends recording the facts discovered and actions taken during an incident and protecting those records, and the chain of custody practices in NIST Special Publication 800-86. They are a starting point, not legal advice.

Security incident

An event that actually or potentially harms the confidentiality, integrity, or availability of company systems or information, or that violates security policy. Suspected incidents are handled as incidents until ruled out.

Discovery

The time an incident is first known, or by exercising reasonable diligence would have been known, to any employee, officer or agent of the company other than the person who caused it. Breach counsel confirms how each law defines discovery.

Incident Response Lead

The person who runs the response, classifies severity, keeps the incident log, and decides when the incident is closed, as named in the incident response plan.

Evidence

Any record that shows what happened, such as emails with full headers, screenshots, photos of a screen, logs, disk or memory images, bank records, and phone records. Collected incident data is treated as evidence even when no one expects a prosecution.

Chain of custody

A written record of every person who held an item of evidence, what they did with it, and when, from the moment it was collected. It shows the item was not altered.

Hash value

A short digital fingerprint calculated from a file or disk image. If the fingerprint of a copy matches the original, the copy is unchanged.

Out-of-band communication

A way to communicate that does not depend on possibly compromised company systems, such as phone calls or a separate messaging account.

Restricted access. Completed forms can describe security weaknesses, the people whose information was involved, and mistakes made by staff. Completed forms are kept in a restricted folder that only the response team, the executive decision-maker, and legal counsel can open. Access to the folder is reviewed when the incident closes. Forms are never posted in shared channels or sent to people outside the response team without the approval of the Incident Response Lead. This does not limit the Protected Reports section.

If company systems may be compromised. Do not store forms in a mailbox, chat, or file share the attacker may be able to read. Start on paper or in an account that does not depend on company systems, and move the forms to their normal location only after the technical team confirms that location is clean. Discuss the incident by phone until then.

Counsel instructions. When outside breach counsel is directing the investigation, follow counsel's instructions on how forms are labeled, who receives copies, and whether drafts are kept. Counsel, not the response team, decides whether any legal protection applies to them.

Retention. Completed forms and the evidence they describe are kept for at least 3 years after the incident is closed. Notification records are kept for the period set in the Data Breach Notification Procedure, where adopted, or for the period in this paragraph, whichever is longer. Destroy them only under the company's records retention policy.

Legal holds. When outside breach counsel issues a legal hold, every related form, log, and item of evidence is kept until counsel releases the hold, whatever the retention period says.

Blank copies. A printed set of blank forms is kept with each offline copy of the incident response plan, and the Incident Response Lead replaces them whenever this document is revised.

Nothing in this document prohibits or restricts anyone from reporting a possible violation of law to, filing a charge or complaint with, communicating with, or taking part in an investigation by any government agency, including law enforcement, the U.S. Department of Health and Human Services, the Securities and Exchange Commission, the National Labor Relations Board, or a state attorney general, or from making any other disclosure protected by law. No approval is needed for these reports, and no one will be disciplined for making one in good faith.

Call the Incident Response Lead first, then complete as much of this form as you can within 1 hour of noticing the problem. Leave a field blank rather than guess. Record times in Eastern Time.

About you and the report

How was it noticed? (mark all that apply)

• [ ] A suspicious email, text message, or phone call
• [ ] I clicked a link, opened an attachment, or entered my password
• [ ] A ransom note, files that will not open, or strange file names
• [ ] Multi-factor authentication prompts I did not request
• [ ] A payment request or a change to bank details that seemed wrong
• [ ] A device was lost or stolen
• [ ] Information was sent to the wrong person or posted where it should not be
• [ ] A customer, supplier, or bank told us about a message or payment
• [ ] An alert from security software or from IT
• [ ] Other (describe below)

What happened

Information that may be involved (mark all that apply)

• [ ] Personal information
• [ ] Customer, supplier, or other confidential business information
• [ ] None that I know of
• [ ] Not sure

Do not. Unless the response team tells you to:

• Do not turn off, restart, or wipe a device you think is affected. For a computer or laptop, unplug its network cable and turn off Wi-Fi if you can, but leave it powered on.
• Do not delete suspicious emails, messages, or files, and do not forward them to coworkers.
• Do not reply to, pay, or contact the attacker or the sender.
• Do not run your own cleanup or antivirus tools.
• Do not discuss the incident with anyone outside the company or on social media, except as allowed under the Protected Reports section.
• If money was sent, tell Finance and the response team immediately. A bank recall works best in the first hours.

The Incident Response Lead completes this form as soon as a report arrives and updates it as facts change. The first step is a quick review to confirm whether an incident has occurred and to estimate its severity and urgency. Record every change in severity, with the time and reason, in the running incident log.

Severity level (mark one, and when in doubt choose the higher level)

Incident type (mark all that apply)

• [ ] Business email compromise or payment fraud
• [ ] Ransomware or extortion
• [ ] Account compromise (stolen password, session, or MFA approval)
• [ ] Lost or stolen device
• [ ] Malware on one or more devices
• [ ] Data exposure or information sent to the wrong place
• [ ] Incident at a vendor or service provider that affects the company
• [ ] Other (describe)

Scope estimate

Initial containment decision

Escalation and notification triggers

Mark each trigger that may apply. A marked trigger starts a conversation with outside breach counsel, not a notice: counsel decides whether any notice is legally required. Before the company notifies anyone or hires outside firms, confirm with your breach counsel and your cyber insurer (this does not limit the Protected Reports section).

The Incident Response Lead, or a note-taker they name, keeps this log from triage until the incident is closed, writing entries as things happen rather than afterward. A paper log is acceptable and is often safer while company systems may be compromised. Number every page with the incident number and page number.

Record. Every action taken and who took it; what was observed and where it came from; every call, email, or meeting with an outside party, with the person's name and any reference or case number; every change of severity; and the times systems were disconnected, restored, or returned to normal use. For ransomware, also record the details the FBI asks for in a complaint: the ransomware name if known, the file extension of encrypted files, the cryptocurrency type and address, the email address and websites the attackers gave, the amount demanded, and whether anything was paid.

The managed IT provider collects technical evidence and completes this register. If possible, one person is named evidence custodian for the incident, with sole responsibility for labeling, logging, and storing each item. If it is unclear whether something needs to be preserved, preserve it. Employees do not copy or move evidence themselves, apart from photos or screenshots the response team asks for.

Typical evidence. Photos or screenshots of ransom notes and fraudulent messages; suspicious emails saved with full headers; sign-in, mailbox, and cloud audit logs; firewall and remote access logs; memory and disk images; copies of malware, handled only by the technical team; bank, wire, and payment records; phone records; and chat transcripts.

Chain of custody. Record every person who holds an item, what they did with it, and when. Store items securely when they are not in use, examine copies rather than originals, and check that the original and each copy still match. The FBI does not accept evidence with an online complaint, so keep originals in a secure location in case an investigating agency asks for them.

Hash values. Where possible, the technical team calculates a hash value for each file or image when it is collected, records the method used (for example, SHA-256), and calculates it again whenever the item is copied or handed over. Matching values show the item has not changed.

Evidence items

Custody transfers

Every response decision trades something off, such as restoring operations quickly against preserving evidence or watching an attacker. Record each significant decision here, with the options that were considered and why one was chosen, so the company can later show what it knew and why it acted as it did.

Decisions reserved to specific people

Law enforcement requests to delay notice. If a law enforcement agency asks the company to delay notifying affected people, record the request in this log at once: the date and time, the officer's name, the agency, and how the request was made. North Carolina law (N.C.G.S. 75-65) allows notice to be delayed when an agency says notification may impede a criminal investigation or jeopardize national or homeland security, provided the request is made in writing or the business documents it at the time in writing, including the officer's name and agency. Give the record to outside breach counsel.

Use this tracker to make sure every possible notice is considered, decided, and documented. It does not decide who must be told. Breach counsel determines whether notice is legally required. The executive decision-maker approves sending each notice, its content and its method on that advice, and never overrides a determination that notice is required. Before the company notifies anyone or hires outside firms, confirm with your breach counsel and your cyber insurer (this does not limit the Protected Reports section). Notification laws differ by state and industry, so this tracker is a starting point and not a complete list of obligations.

Discovery date. Many deadlines run from discovery, not from the end of the investigation. Use the discovery date and time recorded on the triage form, and have counsel confirm which date each law or contract uses.

Keep proof. For every notice, keep a copy of exactly what was sent, to whom, how, and when, with any confirmation or reference number. When filing a complaint at ic3.gov, save or print a copy before leaving the page: IC3 does not email a copy afterward and does not accept attachments, so keep the original evidence yourself.

Finance keeps this tracker with the Incident Response Lead from the first hour. Recording the dates and times people worked on the incident, including the time needed to recover systems, helps calculate what the incident cost. Check the cyber policy for which costs are covered and whether the insurer must approve a vendor or expense before it is incurred, and record that approval below.

Staff time

Outside vendors and expenses

Business impact

The Incident Response Lead completes this summary when the incident is closed. It is the after-action report: what happened, how the company responded and recovered, and what it learned. Hold a blameless lessons-learned meeting with everyone involved before the summary is signed, and track every corrective action to completion.

Closure checklist

• [ ] Containment and eradication confirmed by the managed IT provider
• [ ] Systems restored, checked, and confirmed clean before returning to normal use
• [ ] Passwords and other credentials the attacker may have seen have been reset
• [ ] Every notice decision made and recorded on the notification tracker
• [ ] Evidence stored, and legal hold status confirmed with counsel
• [ ] Costs and staff time recorded on the costs and time tracker
• [ ] Insurance claim filed or a decision not to claim recorded
• [ ] Lessons-learned meeting held with everyone involved

Summary

Lessons learned

Sign-off. Signed by the Incident Response Lead and the Chief Executive Officer, and reviewed by outside breach counsel where counsel was involved.

Approval. Sign below to approve this document for adoption by [Company Name] after it has been reviewed by your legal counsel. Until it is signed, it is a draft and is not in effect.

Revision history. Record every change to this form below. Increase the document version and obtain approval again each time the form is revised.

This document was generated from a starter template provided by Preferred Data Corporation. It is general information only. It is not legal advice and it is not a substitute for advice from a licensed attorney. Using the template does not create an attorney-client, consulting, or other professional relationship.

Preferred Data Corporation is not a law firm or an insurer. It makes no representation that this document is complete, current, or suitable for any particular organization, industry, jurisdiction, or regulatory requirement. To the fullest extent permitted by law, it is not responsible or liable for any loss or damage arising from the use of this template or of any policy created from it. You are solely responsible for how you adapt, adopt, and enforce it.

Laws, regulations, insurance requirements, and contracts that apply to your organization may require different or additional terms. The facts, deadlines, and legal references in this template were checked against their sources on the date shown as "Template content last reviewed" in Document Control, not on the effective date, and may have changed since. Before you adopt, publish, or rely on this document, and in every case where you have a legal, regulatory, or contractual obligation, have it reviewed by qualified legal counsel.

In an actual security incident or data breach, contact your attorney, your cyber insurer, and law enforcement where appropriate. Do not rely on this template alone to decide whether, when, or how to notify anyone.

If Preferred Data Corporation prepared this document for you as part of its services, your service agreement governs those services. The content of this document is still general information and should be reviewed by your own counsel before you adopt it.

This template is provided "as is", without warranties of any kind, including accuracy, completeness, or fitness for a particular purpose. Links to laws, agencies, and other websites are provided for convenience and may change. Use of this template is also subject to the Website and Free Resources Disclaimer and the Terms of Service at preferreddata.com/legal/disclaimer and preferreddata.com/legal/terms-of-service.

To report an error, contact Preferred Data Corporation at preferreddata.com/contact or (336) 886-3282 and include the Document ID shown in Document Control. Corrections are listed in the template changelog on the template's page at preferreddata.com/policy-templates.