Draft an Incident Report and Executive Brief from Structured Facts

Tier: Foundation · Workflow area: Incident response, DFIR & CTI

The catch is that a model asked to "write an incident report" will invent the facts it does not have. This playbook keeps generation strictly downstream of verified facts, so the writing is AI's job and the facts remain yours.

When to reach for this

• •
  An incident is resolved (or contained) and you have a verified timeline and findings to write up.
• •
  You need the same facts rendered for two audiences: responders/auditors and leadership.
• •
  You want consistent report structure without hand-formatting every section.

Do not use this to investigate — only to write up an investigation that is already done. If you do not have the facts, the model will supply fake ones.

The workflow

1. 1.

   Assemble the verified facts first. Pull together the confirmed timeline (from pb-10), impact, root cause, and remediation as bullet points. This is the input; the model may not go beyond it.

2. 2.

   Prompt with a strict no-invention constraint.

   Copy

   Write an incident report from ONLY the facts below (sample data). Structure:
   Summary, Timeline, Impact, Root Cause, Remediation, Follow-ups.
   Rules:
   - Use only facts I provide. If a section has no supporting facts, write
     "Not determined" — do NOT infer or fill it in.
   - Do not add severity ratings, attribution, or dollar figures I did not give.
   - Keep it factual and blameless.
   
   Then write a separate 4-6 sentence EXECUTIVE BRIEF of the same incident for
   non-technical leadership: what happened, business impact, what we did, what
   is left. No jargon.
   
   FACTS:
   ...
   

   Expected output: a structured report plus a short executive brief, with "Not determined" wherever you left a gap — the gaps are honest, not hidden.

3. 3.

   Diff the draft against your fact list. Read every sentence and confirm it traces to a fact you provided. Any claim without a source — a severity you did not assign, an attribution you did not make — is an invention to cut.

4. 4.

   Check the executive brief for silent editorializing. Models tend to soften or dramatize for leadership. Confirm the business-impact sentence matches the actual impact facts, neither inflated nor minimized.

5. 5.

   Have a second responder review before it ships. An incident report is a durable record; a peer read catches both fabrications you missed and tone problems.

Verify before you trust it

• Fact-tracing check: every claim in the report must map to a provided fact. This is a citation check against your own input — anything unsourced is fabricated and comes out.
• Number check: scrutinize every figure — record counts, durations, costs, user totals. Models round, invent, and transpose numbers freely, and a wrong number in an exec brief is what leadership remembers.
• False-positive catch (attribution): confirm the report does not assert attribution ("nation-state actor") or a root cause you never established. Unsupported attribution in a written record causes real damage.

Pitfalls

• Invented root cause. Asked for a Root Cause section with thin facts, the model writes a plausible one. "Not determined" is the correct output when you have not determined it.
• Number drift. "Approximately 12,000 records" becomes "12,000" becomes "over 15,000" across drafts. Pin every number to a fact and re-check after each edit.
• Tone laundering in the exec brief. The model may downplay ("a minor issue") or overstate to sound decisive. The brief must match the facts' actual severity.
• Blame creep. Models sometimes name individuals or teams as at fault. Keep it blameless and system-focused; edit out personal attribution.

Tools

• Open LLM run locally (Ollama): drafts the report and brief without sending incident details to a third party.
• LLM plus a house report template: the model fills your organization's standard structure, keeping reports consistent and auditor-friendly.
• DFIR toolkit output: the verified timeline and findings that become the fact list — the only thing the model is allowed to build on.

Client-safe variant

An incident report about a client is confidential and may carry legal weight, so drafting stays inside the client boundary. Run the generation on a local Ollama model or the client's approved endpoint, and feed it facts already redacted of personal data — the report structure does not need real names or IPs, and placeholders keep PII out of the model. Because incident reports can become discoverable or breach-notification records (relevant under India's DPDP and CERT-In reporting timelines), the client's IR lead owns the final wording; the AI produces a draft their responders verify, correct, and sign. Never let a personal AI account touch a client's incident narrative.