QUICK ANSWER
What should an incident report template include?
An incident report template should capture a stable ID, factual summary, observed and reported times, location or system, people or services affected, measured impact, an ordered timeline, sanitized evidence, actions already taken, notifications, open questions, and the next handoff. Keep response commands, legal determinations, root causes, corrective actions, and recovery approval in separately owned records.
A useful incident report preserves what was observed, when and where it happened, the measured impact, evidence, actions already taken, notifications, and the next accountable handoff. It gives reviewers one factual record without turning early observations into causes or response commands.
This downloadable pack includes an editable Markdown worksheet, a valid JSON starter, a closed JSON Schema, a fictional completed example, and a dependency-free validator with deterministic tests. It is an internal record template, not an emergency procedure, regulator or insurer report, incident response plan, root-cause analysis, medical record, legal opinion, or proof that recovery is complete.
Capture the event without outrunning the evidence
Start with immediate safety and reporting obligations, then preserve a neutral event record. Separate observations from interpretations, keep evidence access controlled, and hand unresolved decisions to named owners.
Stop for emergency, safety, and reporting duties first
If anyone may be in immediate danger, follow the local emergency process before filling out a template. Assign a qualified owner to determine workplace, privacy, security, contractual, insurer, and regulator duties for the applicable jurisdiction. The ordinary record can note that a handoff occurred, but it must not decide whether a legal threshold was met.
Sources: [incident-report-pack], [osha-recordkeeping], [osha-severe-injury]
Open one stable record and write a neutral summary
Give the event an immutable incident ID, revision, record status, reporter role, observed time, detected time, reported time, location or affected system, and a short statement of what was seen. Use UTC timestamps in the machine-readable record and distinguish unknown from not applicable rather than inventing detail.
Sources: [incident-report-pack], [nist-800-61r3]
Build an ordered timeline from attributable observations
Record each observed event with a sequence number, time, observer role, fact statement, and evidence IDs. Label a time as exact or estimated. Preserve contradictory observations as separate entries instead of silently resolving them, and keep a cause hypothesis out of the factual timeline.
Sources: [incident-report-pack], [nist-800-61r3]
Record impact and sanitize the evidence inventory
State only measured or directly reported impact, affected scope, duration known so far, and current uncertainty. Give each file, log, image, statement, or external reference a stable ID, capture time, access level, safe reference, hash, redaction confirmation, and retention owner. Do not place credentials, sensitive personal data, health details, or unnecessary customer records in a general download or tracker.
Sources: [incident-report-pack], [owasp-logging], [rfc-2606]
Separate completed actions from future response instructions
Record an action only as a factual statement of what already occurred, who performed it, when, why it was taken, its observed result, and its evidence. Put proposed containment, investigation, communications, escalation, recovery, and exercise procedures in the incident response plan or controlled runbook owned by qualified responders.
Sources: [incident-report-pack], [cisa-irp-basics], [nist-800-61r3]
Validate references, preserve open questions, and hand off
Use the closed schema and validator to reject unknown keys, invalid chronology, duplicate IDs, broken evidence references, unsafe fictional URLs, and contradictory handoff states. Name the next owner role, purpose, handoff time, accepted state, and referenced evidence. Structural validity makes the record reviewable; it does not accept a root cause, approve remediation, or declare recovery.
Sources: [incident-report-pack], [json-schema-2020-12]
The factual incident-record boundary
Use this template to preserve one bounded event and its accountable handoff. Link adjacent plans and analyses by stable ID, but keep their decisions outside this record.
Included
- Stable incident ID, revision, record status, reporter role, observed, detected, and reported timestamps
- Location or affected system, neutral factual summary, incident category, and known confidentiality level
- Observed impact, affected people, services, assets, or operations, measured scope, duration, and uncertainty
- Ordered observations with exact or estimated times, observer roles, factual notes, and resolving evidence IDs
- Sanitized evidence inventory with type, capture time, access level, safe reference, SHA-256, redaction state, and owner role
- Actions already taken as historical facts, notifications and handoffs, open questions, and final record-handoff state
Not included
- Emergency instructions, hazard control, medical assessment, public safety advice, or a substitute for calling local emergency services
- A regulator, police, insurer, employment, privacy, security-disclosure, or legally sufficient workplace report
- An incident response plan, command structure, containment playbook, communications approval, recovery runbook, or exercise
- A root-cause conclusion, blame assignment, contributing-factor finding, corrective or preventive action, or postmortem decision
- Severity command authority, remediation approval, budget, schedule, contractual notice, legal privilege, or compliance certification
- Proof that evidence is authentic or complete, everyone affected was identified, response was adequate, recovery succeeded, or recurrence is prevented
DOWNLOADABLE RESOURCE
Download the incident report template pack
Start with the Markdown worksheet for a human review or the valid JSON starter for automation. Compare the fictional completed record, inspect the closed JSON Schema, then run the included validator and tests without installing dependencies.
Factual incident report template pack
A fictional incident record that connects one bounded service disruption to an ordered timeline, observed impact, sanitized evidence, completed actions, notifications, open questions, and an accepted factual handoff without asserting cause or recovery.
Format: Markdown, JSON, JSON Schema, and dependency-free Node.js validator/tests in one ZIP
Locally reproduced August 1, 2026. SHA-256: 1910d58bc126c2a7c55658159c51ede2bfdbbafcef7a6a35ed01b79524cca498
Included
- Editable Markdown worksheet and a valid fictional JSON starter
- Completed fictional JSON example for one bounded operational incident and accepted record handoff
- Draft 2020-12 closed JSON Schema with exact root and nested record shapes
- Dependency-free Node.js validator covering chronology, IDs, references, URLs, hashes, redaction, access, and handoff states
- Deterministic contract tests for valid records and rejected unsafe or contradictory states
- README, package commands, fixed source timestamps, exact file allowlist, and reproducible ZIP bytes
Verification boundary
Rebuilt twice with fixed source timestamps and stripped ZIP metadata. Verified the exact file allowlist, source-to-public-to-archive byte parity, clean extraction, validator tests, starter and example validation, closed schema, exact object keys, UTC timestamps, ordered observations, actions and handoffs, evidence references and hashes, reserved fictional URLs, redaction and access fields, chronology, open questions, accepted record handoff, and all-false ownership boundaries.
Three incident-report patterns
The factual record stays stable while the event domain changes. Each pattern documents what was observed and where the next decision belongs.
Customer-facing service disruption
Use when: A website, application, integration, or internal service behaves differently from its expected operating state and several teams need the same factual timeline.
Record the detection signal, affected service and region, measured request impact, observed start and end times, sanitized monitoring references, completed actions, customer-communication handoff, and unresolved scope questions. Leave containment commands and recovery approval with the response owners.
Structure
- One incident ID connects every timeline observation, action, evidence item, notification, and handoff
- Measured affected requests and duration stay separate from estimated customer or revenue impact
- The record can close its handoff while the response, recovery, and root-cause records remain open
Watch for: A factual service timeline does not prove provider responsibility, security impact, contractual breach, full recovery, root cause, or future reliability.
Sources: [incident-report-pack], [nist-800-61r3], [cisa-irp-basics]
Workplace equipment or safety event
Use when: A workplace event needs an internal factual record after immediate danger has been addressed by the organization’s qualified safety process.
Record the location, time, observer roles, equipment identifier, factual observations, access-controlled evidence, actions already taken, safety-owner notification, and open questions. Keep medical details minimal and restricted, and send reportability decisions to the qualified jurisdiction owner.
Structure
- Emergency response and local reporting happen before the ordinary template workflow
- The timeline distinguishes direct observations from later statements and estimated times
- The handoff identifies the safety or legal owner without deciding whether a regulatory threshold applies
Watch for: This general pack is not an OSHA form, medical record, workers’ compensation record, police report, insurer notice, investigation finding, or jurisdiction-specific legal advice.
Sources: [incident-report-pack], [osha-recordkeeping], [osha-severe-injury]
Operational process breakdown
Use when: A fulfillment, approval, data, vendor, or handoff process fails and reviewers need one neutral event record before deciding what to change.
Capture the expected checkpoint only as context, then record the observed deviation, affected records or orders, timeline, evidence, completed mitigation, stakeholders notified, and the owner receiving the next investigation. Keep causal claims and corrective actions pending until separately reviewed.
Structure
- Observed counts and affected identifiers use bounded fictional or safely redacted references
- Completed mitigation is historical fact, not proof that the process is recovered or safe
- Open questions become an explicit handoff rather than unsupported conclusions in the report
Watch for: A process incident report does not assign blame, calculate contractual liability, approve compensation, establish fraud, prove data integrity, or authorize a corrective-action plan.
Sources: [incident-report-pack], [owasp-logging], [json-schema-2020-12]
Decide whether the record is ready for handoff
A valid file is a documentation gate, not an incident decision. A qualified human still owns safety, notification, response, investigation, recovery, and corrective action.
A person may be in immediate danger, a serious workplace event may be reportable, or a security or privacy exposure may still be active.
Choose: Stop the ordinary template workflow and use the organization’s emergency, safety, security, privacy, legal, insurer, and regulator escalation paths.
Tradeoff: The general record may remain incomplete, but urgent protection and time-bound reporting stay ahead of documentation convenience.
The summary contains assumptions, blame, causes, or proposed remediation that are not direct observations.
Choose: Move each interpretation to an open question or a separately owned investigation record and keep the incident report factual.
Tradeoff: The early report sounds less conclusive, but reviewers can distinguish evidence from a hypothesis and update conclusions without rewriting history.
An evidence reference contains credentials, sensitive personal or health data, a private production URL, or unrelated customer records.
Choose: Restrict access, remove or minimize exposed material where possible, document the evidence owner, and follow the qualified privacy or security process.
Tradeoff: The general tracker holds less raw detail, but access, retention, disclosure, and notification remain with accountable owners.
The record is marked handoff complete without an accepted receiving role, handoff time, purpose, and resolvable evidence references.
Choose: Keep the record open, repair the missing or contradictory references, and obtain explicit acceptance from the receiving role.
Tradeoff: Administrative closure waits, but the next investigation or response owner receives an attributable evidence trail instead of an orphaned summary.
START WITH THE FACTS
Download the incident report and validate the handoff
Open the Markdown or JSON starter, compare the fictional completed example, inspect the closed schema, and run the included validator before adapting the record to one bounded event.
Download the incident report template packThe ZIP is reproduced locally. Public availability, local reporting duties, adapted evidence safety, and real report accuracy require separate verification.
Keep response authority in the incident response planUse this page for one factual event record. Use the response-plan owner for roles, activation, authority, communications, exercises, and recovery criteria.
What an incident report cannot prove
A structured record makes omissions and contradictions easier to review. Its quality is still limited by access, observation, memory, evidence collection, timing, local duties, and the decisions made outside it.
- A precise timeline does not prove causation, intent, negligence, responsibility, liability, fraud, or blame.
- A report can omit people, systems, assets, symptoms, downstream effects, or evidence that were unknown or inaccessible at the time.
- A copied severity label does not replace a qualified incident commander, safety owner, privacy owner, security owner, insurer, regulator, or legal reviewer.
- Sanitized files and hashes improve reviewability but do not independently prove authenticity, completeness, chain of custody, or admissibility.
- Recording an action already taken does not establish that it was correct, authorized, effective, safe, sufficient, or compliant.
- An accepted handoff closes only the factual record stage; it does not prove containment, recovery, notification, root cause, remediation, or recurrence prevention.
- The pack does not replace a response plan, runbook, workplace form, medical record, regulator report, root-cause analysis, corrective-action plan, or professional advice.
- This ordinary informational article does not grant AI signup credits. The linked product page follows its own current eligibility rules.
Sources and verification record
The same-release artifact directly supports the fictional record and validator claims. Current primary guidance supports incident-risk management, response-plan separation, workplace reporting boundaries, safe evidence handling, closed schemas, and reserved fictional domains without certifying this pack.
[incident-report-pack] Playcode:Factual incident report fictional example
Checked August 1, 2026. Supports: The locally reviewed fictional record, ordered timeline, observed impact, sanitized evidence, completed actions, notifications, open questions, accepted handoff, validator behavior, tests, and reproducible archive. Public availability remains unverified until deployment.
[nist-800-61r3] National Institute of Standards and Technology:NIST SP 800-61 Rev. 3
Checked August 1, 2026. Supports: The April 2025 current NIST publication’s integration of cybersecurity incident response across preparation, detection, response, recovery, and risk management. It does not prescribe this general record or certify an adapted process.
[cisa-irp-basics] Cybersecurity and Infrastructure Security Agency:Incident Response Plan Basics
Checked August 1, 2026. Supports: CISA’s current overview that an incident response plan is implemented before, during, and after a cybersecurity incident. It supports keeping response planning separate from this factual record and does not verify any response outcome.
[osha-recordkeeping] Occupational Safety and Health Administration:OSHA recording and reporting requirements
Checked August 1, 2026. Supports: Current federal OSHA guidance that covered workplace recording, severe-event reporting, and annual electronic submission are separate obligations with applicability rules. It does not make this general pack an OSHA record.
[osha-severe-injury] Occupational Safety and Health Administration:Report a Fatality or Severe Injury
Checked August 1, 2026. Supports: Current federal OSHA timing and information requirements for specified work-related fatalities and severe injuries, plus the warning that state requirements can vary. It supports the emergency and qualified-reporting gate, not legal advice for any event.
[owasp-logging] OWASP Cheat Sheet Series:Logging Cheat Sheet
Checked August 1, 2026. Supports: Current guidance on useful event context and excluding, masking, sanitizing, hashing, or encrypting passwords, tokens, sensitive personal data, connection strings, and other secrets. A checked field alone does not make evidence safe.
[json-schema-2020-12] JSON Schema:JSON Schema specification
Checked August 1, 2026. Supports: The current released JSON Schema version, Draft 2020-12, declared by the bundled closed schema. The dependency-free validator separately enforces chronology, cross-record references, and workflow rules.
[rfc-2606] RFC Editor:Reserved Top Level DNS Names
Checked August 1, 2026. Supports: The reservation of .test for testing examples, which is why bundled fictional references avoid real customer, internal, or production domains. A reserved hostname does not make an adapted record private or secure.
Incident report template questions
What is the purpose of an incident report?
An incident report preserves a reviewable factual record of one bounded event: what was observed, when and where, who or what was affected, evidence, actions already taken, notifications, open questions, and the next handoff. It should reduce memory loss and contradictory retelling without deciding root cause, liability, blame, remediation, or recovery.
What is the difference between an incident report and an incident response plan?
The report records one event and the facts available at the time. The response plan defines roles, authority, activation, communications, evidence governance, response, recovery, exercises, and review before incidents occur. Link the report ID to the active response record, but do not place future commands or plan approval inside the factual report.
Is an incident report the same as a root cause analysis?
No. The incident report preserves observations, impact, evidence, completed actions, and handoffs. Root-cause analysis evaluates competing hypotheses, causal and contributing factors, corrective actions, owners, verification, and follow-up after enough evidence exists. An early report may list an open question, but it should not promote a suspected cause into fact.
Should an incident report include photos, logs, or witness statements?
Include only evidence needed for the qualified review. Record a stable ID, type, capture time, owner, access level, safe reference, hash, redaction state, and factual note. Restrict or omit credentials, private URLs, health details, personal data, customer records, and unrelated content. Follow local preservation, consent, retention, and disclosure rules.
When is an incident report complete?
The factual record can be marked handoff complete when required fields and references validate, contradictions are preserved or resolved transparently, open questions are explicit, and a named receiving role accepts the evidence trail and purpose. That state does not mean response, notification, recovery, investigation, remediation, or regulatory work is complete.
Can Playcode turn this template into an incident-record workflow?
Playcode can help build a bounded workflow around reviewed report, timeline, impact, evidence, action, notification, question, and handoff records. Before operational use, verify access, restricted data, attachments, retention, audit, notifications, concurrent edits, integrations, export, monitoring, backup, recovery, emergency routing, and release ownership with the people responsible for the real process.
BUILD THE REVIEWED RECORD WORKFLOW
Turn the accepted incident record into a bounded app
Give Playcode the reviewed fields, roles, states, evidence rules, and ownership boundaries. Verify restricted access, attachments, retention, audit, notifications, emergency routing, integrations, monitoring, backup, recovery, and release control before operational use.
Build and verify the incident workflowThis informational article does not grant AI signup credits. No report accuracy, evidence authenticity, response quality, recovery, safety, security, privacy, compliance, legal sufficiency, or business outcome is guaranteed.