Incident Report Template
Summary, timeline, evidence, findings, impact, actions, and interview notes.
Free editable starter kit
Write the work so someone else can use it.
Incident reports, vulnerability summaries, evidence notes, portfolio planning, and résumé formulas for turning cyber practice into clear proof.
Download separately
Starter kit files.
Download the complete kit above, or open only the editable template you need.
Produces: incident report
Vulnerability Report Template
Scope, evidence, impact, remediation, validation, and retest notes.
Evidence Skills Checklist
Question, source, scope, capture date, meaning, limitations, and next step.
1. Incident report template
A useful incident report is clear, supported by evidence, and actionable.
Incident title: Date/time discovered: Analyst: Severity: Low / Medium / High / Critical Executive summary: What happened, what evidence supports it, impact, and recommended next step.
Timeline
| Time | Event | Evidence |
|---|---|---|
Evidence reviewed
- Alert name or ID
- Log source
- Source IP, user, hostname, or affected asset
- Screenshots, exports, or ticket references
- Analyst notes and assumptions
Findings
- What happened
- What is confirmed
- What is suspected
- What remains unknown
2. Vulnerability report template
Finding: Affected asset: Severity: Evidence: Recommendation:
Explain the finding for technical and non-technical readers. Do not paste scanner output and call it analysis.
Better summary
The affected system is missing a security update that could allow unauthorized access if exploited. Validate, patch, and retest the finding based on asset criticality.
3. Evidence checklist
- Question, alert, finding, or objective
- System or scope
- Screenshot, export, or log sample
- Date captured
- What the evidence proves
- What remains unknown or assumed
- Recommended next step
- Portfolio or interview story note
4. Evidence answer framework
- Direct answer: what you found or concluded
- Scope: where the answer applies
- Evidence: what supports the answer
- Limitations: what is not proven
- Next step: what should be validated, fixed, or documented
Stronger answer
The login pattern was suspicious because five failed attempts were followed by a successful login from the same source. The events are supported by authentication timestamps and account data. Source ownership and user recognition still require validation.
5. Résumé bullet formula
Investigated [event/finding] using [tool/log source], documented [evidence/report], and recommended [action/outcome].
Example: Investigated SSH brute-force activity using SIEM alerts and authentication logs, documented a timeline and source-IP summary, and produced an incident report with recommended access-control actions.