# Incident Report

Drafts a security incident report from your incident notes, timeline, and findings. Use it after containment, when you need a clear record for leadership, compliance, or after-action review.

## Prompt

## Context
You are a security analyst drafting an incident report for [ORG NAME]. The report will be reviewed by [AUDIENCE: e.g., IT leadership, compliance team, executive team]. It documents a security incident from detection through containment. You are working from the analyst notes and timeline supplied below. Do not invent log data, IP addresses, hostnames, system names, vulnerability details, or findings that are not in the supplied notes.

Incident ID or name: [INCIDENT ID]
Date and time range: [DATE TIME RANGE]
Systems affected: [AFFECTED SYSTEMS]
Brief description of what happened: [INCIDENT DESCRIPTION]
Timeline of key events (chronological notes): [TIMELINE NOTES]
Containment and remediation actions taken: [ACTIONS TAKEN]
Data or services impacted: [IMPACT]
Current status: [CURRENT STATUS]

## Task
Draft an incident report with these sections:
1. Executive Summary: three to five sentences. What happened, when, impact, and current status. Non-technical.
2. Incident Timeline: dated and timed events in chronological order, drawn from the notes supplied.
3. Affected Systems and Data: what was affected and how, based on the supplied impact information.
4. Containment and Remediation Actions: numbered list of actions taken, with dates where available.
5. Root Cause Assessment: state the root cause if the notes support a conclusion. If the cause is not yet confirmed, say so plainly.
6. Recommendations: three to five specific actions to prevent recurrence, based on what the incident revealed.
7. Open Items: unresolved questions or follow-on tasks, flagged clearly.

## Standards
- Every fact in the report comes from the supplied notes. Do not add context, threat intelligence, or findings the analyst did not supply.
- Do not claim that data was exfiltrated, that an attacker achieved a specific objective, or that a system is clean unless the supplied notes support that conclusion.
- Do not fabricate CVE numbers, IOC (indicator of compromise) values, attacker techniques, or tool names.
- Use precise, plain language. Spell out all technical acronyms the first time.
- Root Cause Assessment must say "root cause not yet determined" if the notes do not support a conclusion.
- If any key section input is missing, note it as [PENDING] in that section and ask the analyst to supply it.

If named inputs are missing or ambiguous, ask before drafting.

## Variables

- ORG NAME
- AUDIENCE
- INCIDENT ID
- DATE TIME RANGE
- AFFECTED SYSTEMS
- INCIDENT DESCRIPTION
- TIMELINE NOTES
- ACTIONS TAKEN
- IMPACT
- CURRENT STATUS

## Input checklist

- [ ] Your incident notes and timeline from the actual incident, not reconstructed from memory alone
- [ ] The list of affected systems as confirmed by your tools, not inferred
- [ ] Containment and remediation actions with dates, pulled from your ticketing or IR log
- [ ] Impact assessment: confirmed data exposure, service downtime, or user impact with scope
- [ ] Confirm all technical artifacts (hostnames, IP addresses, log excerpts) come from your own systems and tools
- [ ] Redact credentials, sensitive personal data, and anything restricted by your org or compliance requirements before pasting

## Verification checklist

- [ ] Every hostname, IP address, and system name in the report matches your confirmed asset inventory
- [ ] No CVE numbers, IOC values, or attacker technique names appear unless you supplied them
- [ ] Root Cause Assessment does not claim a confirmed cause if your investigation is still open
- [ ] Timeline is in the correct chronological order and all timestamps are accurate
- [ ] Data impact section does not overstate or understate scope beyond what evidence supports
- [ ] Recommendations are specific to your environment, not generic boilerplate
- [ ] Open Items section contains any unresolved questions from your notes before the report is finalized

## Sample output

Sample output. Generated by AI from sample inputs:

INCIDENT REPORT
Org: Northwind Logistics | Incident ID: INC-2026-0041 | Prepared: June 11, 2026

1. Executive Summary
On June 9, 2026, a contractor account at Northwind Logistics was used to access the file server FS-SHARE-01 outside of normal business hours. The account was disabled within two hours of detection. No confirmed data exfiltration occurred. The incident is contained; a full access review is in progress.

2. Incident Timeline
- 2026-06-09 22:14 UTC: SIEM alert fires on after-hours login for contractor account SVC-CONTRAC-07.
- 2026-06-09 22:31 UTC: On-call analyst reviews alert and confirms login from IP not matching VPN range.
- 2026-06-09 23:02 UTC: Account SVC-CONTRAC-07 disabled by identity team.
- 2026-06-10 08:15 UTC: Forensic review of FS-SHARE-01 access logs begins.
- 2026-06-10 11:40 UTC: No evidence of file download or lateral movement found in the log window reviewed.

3. Affected Systems and Data
FS-SHARE-01 was accessed. No confirmed data exfiltration. Scope of files browsed is under review.

4. Containment and Remediation Actions
1. SVC-CONTRAC-07 disabled 2026-06-09 23:02 UTC.
2. Password reset forced for all active contractor accounts 2026-06-10 09:00 UTC.
3. Access log review ongoing as of report date.

5. Root Cause Assessment
Root cause not yet determined. The account may have been compromised via credential exposure outside the Northwind environment. Investigation ongoing.

6. Recommendations
1. Implement time-of-day access controls for all contractor accounts.
2. Require multi-factor authentication (MFA) for all contractor VPN sessions.
3. Complete access log review of FS-SHARE-01 for the 30 days prior to the incident.
4. Conduct a full contractor account access review and remove inactive accounts.

7. Open Items
- Forensic log review not complete as of report date. [PENDING: ETA June 13]
- Root cause not confirmed. [PENDING: external credential exposure check]

## Customization notes

Adjust the audience field to change the technical depth of the Executive Summary: write for executives and that section stays at business impact, write for a technical team and it can reference system names. For compliance-driven reports (SOC 2, HIPAA, PCI DSS), add a Regulatory Notification section and note the applicable framework. If your org has a standard incident report template, paste its section headers into the Task block so the output maps directly.

---

From The IT & Cybersecurity Library at vetslearn.com/libraries/it-cyber