The Incident Report Template for a Cybersecurity Portfolio
Write up your SOC-style projects the way real analysts document incidents — not like a school assignment.
Why a real incident report format matters
A README tells someone what you built. An incident report tells someone how you’d actually think during a real investigation — and for SOC, GRC, and blue-team roles, that’s often the more important signal. Interviewers ask “walk me through how you’d handle X” constantly. A portfolio project written up like a real incident report gives you a rehearsed, credible answer instead of an improvised one.
Most beginner write-ups skip this entirely and just describe what they clicked. This template fixes that by using the same structure real SOC teams use to document incidents — severity, timeline, indicators of compromise, and remediation — scaled down to portfolio size.
Where to use this: Pair it with a SOC-style project — the Phishing Investigation, Splunk, or Sentinel projects are the natural fit. Use the README Template for the project overview, and this template for the investigation write-up itself.
The eight-section structure to use
This mirrors the shape of a real SOC incident report, scaled for a portfolio project rather than a live production incident.
Incident summary
Two or three sentences: what happened, in plain English, before any technical detail.
Severity & classification
Rate it and say why — this alone signals you understand triage, a core SOC skill.
Timeline
A chronological log of detection, investigation, and containment — with timestamps.
Indicators of Compromise (IOCs)
The specific artifacts — IPs, hashes, domains, sender addresses — tied to the incident.
Investigation steps
What you actually checked, and in what order — this is where your reasoning shows.
Impact assessment
What was affected, or would have been, if this were a real environment.
Remediation & recommendations
What you did (or would do) to contain it, and what to change to prevent a repeat.
Lessons learned
Same spirit as a README’s “what I’d do differently” — honest, specific reflection.
Understanding severity levels
Real SOC teams triage by severity first. Using this language correctly — even on a practice project — signals you already think the way a working analyst does.
Active compromise, data loss, or system-wide impact in progress.
Confirmed malicious activity with real but contained impact.
Suspicious activity, unconfirmed, needs investigation.
Policy violation or low-risk anomaly, informational.
The free copy-paste template
Copy this directly into your project’s repo or documentation as incident-report.md.
# Incident Report: [Short Title] ## Summary [2-3 plain-English sentences: what happened] ## Severity [Critical / High / Medium / Low] — [one sentence justifying the rating] ## Timeline - [HH:MM] — [Detection event] - [HH:MM] — [Investigation step] - [HH:MM] — [Containment action] ## Indicators of Compromise - IP: [x.x.x.x] - Sender/Domain: [example] - Hash/File: [if applicable] ## Investigation Steps 1. [What you checked first, and why] 2. [What you checked next] 3. [How you confirmed your conclusion] ## Impact Assessment [What was or would have been affected] ## Remediation & Recommendations [What you did, or would recommend, to contain and prevent recurrence] ## Lessons Learned Be honest here — this section is what shows judgment, not just execution.
Filled example
Incident Report: Credential-Harvesting Phishing Email
Summary: A phishing email impersonating an IT helpdesk requested password reset via a spoofed login page. Investigated headers, URL, and payload; confirmed malicious and no credentials were compromised in this simulation.
Severity: Medium — credential-harvesting attempt, no confirmed compromise, isolated to a single simulated inbox.
Timeline: 09:14 — Email received and flagged. 09:22 — Header and sender analysis completed. 09:41 — Malicious URL confirmed via sandboxed analysis.
Indicators of Compromise: Sender domain: [redacted-example.com], spoofed login URL, mismatched Reply-To header.
Investigation Steps: Checked SPF/DKIM/DMARC alignment on the sender domain, examined the URL in a sandboxed browser, cross-referenced the domain against a threat intelligence lookup.
Impact Assessment: None in this simulation — investigation stopped before credential submission.
Remediation: Block sender domain at the mail gateway, add URL to blocklist, recommend user awareness training on spoofed helpdesk emails.
Lessons Learned: Header analysis alone wasn’t conclusive — the sandboxed URL check was what actually confirmed malicious intent. I’d check the URL earlier in the process next time.
Incident report vs README — which do you need?
Use the README to introduce the project overall — what it is, what tools you used, and the high-level outcome. Use the Incident Report for the investigation itself when the project simulates a security incident (phishing, intrusion, malware). A GRC or compliance-style project (like a gap assessment) doesn’t need an incident report at all — it needs a findings/assessment write-up instead, which the README template already covers well.
Common mistakes
Skip severity entirely or call everything “critical”
Rate it honestly and justify the rating — this is the triage skill interviewers actually test for
Write the timeline as one paragraph with no timestamps
Use a real chronological list — it’s what makes it read like an actual case file
List IOCs without explaining what they mean
Briefly note why each IOC mattered to the investigation
Frequently asked questions
Do I need real IOCs, or can I use fake ones?
Use realistic but clearly fictional or redacted values (like [redacted-example.com]) — never real malicious infrastructure. The format matters more than the specific values for portfolio purposes.
Should GRC-track readers skip this template?
Mostly yes — see the scope section above. GRC projects are better served by the README template’s findings section, since compliance work follows a different documentation format than incident response.
Can I bring this to an interview?
Yes — this is exactly the kind of artifact worth having ready when an interviewer asks “walk me through an investigation.” Having a real written example beats describing it from memory.
Get the Full Template Pack
Everything above, plus the enhanced fillable versions:
- Fillable Notion template (duplicate and edit directly)
- Clean PDF version for offline reference
- Markdown file with guidance comments removed, ready to paste
- The README Template, bundled free
Ready to build the project this template documents?
The Phishing Investigation project is the fastest way to put this exact template to use.
Build the Phishing Investigation Project →