Incident Report

Table of Contents

1. Project Overview
2. Learning Objectives
3. Understanding Incident Response
4. Incident Report Framework
5. The Incident Response Lifecycle
6. Incident Classification
7. Evidence Collection & Chain of Custody
8. Timeline Creation
9. Technical Analysis Section
10. Business Impact Analysis
11. Root Cause Analysis
12. Recommendations & Remediation
13. Sample Incident Report
14. Incident Report Templates
15. Common Mistakes to Avoid
16. Deliverables Checklist

Project Overview

In this project, you will learn how to write a professional cybersecurity incident report. You'll analyze a simulated security incident, document findings, create a timeline, assess impact, and provide remediation recommendations. Incident reporting is a critical skill for any security professional.

Scenario

The Incident: On June 15, 2026, at approximately 2:30 PM, the BrightPath Education IT team detected unusual network activity. Investigation revealed that an employee's credentials were compromised through a phishing email, leading to unauthorized access to the student database containing 5,000+ records.

Your task is to write a comprehensive incident report documenting this incident.

💡 Free Lab Setup: Incident reporting requires no special software — just documentation tools you already have:

• Google Docs / LibreOffice — Report writing (free)
• Google Sheets / LibreOffice Calc — Evidence logs, timelines (free)
• draw.io — Network/attack flow diagrams (free)
• All templates and checklists are included in this tutorial — just copy and fill in!
• No paid tools required.

📋 Your Step-by-Step Task:

1. Read the incident scenario — BrightPath Education data breach (below)
2. Study the incident response lifecycle framework
3. Review the chain of custody and evidence collection procedures
4. Create an incident timeline using the template provided
5. Write a technical analysis of the phishing attack
6. Perform a "5 Whys" root cause analysis
7. Calculate business impact using the cost estimate template
8. Write an executive summary (1 page, plain language)
9. Complete the full incident report using the sample as a guide
10. Complete the deliverables checklist and take the quiz

Learning Objectives

After completing this project, you will be able to:

• Structure a professional incident report
• Document evidence following chain of custody procedures
• Create accurate incident timelines
• Perform root cause analysis
• Assess business impact of security incidents
• Write clear, actionable remediation recommendations
• Communicate technical findings to non-technical stakeholders

Understanding Incident Response

What is Incident Response?

Incident Response (IR) is the systematic approach to managing and responding to security incidents. The goal is to handle the situation in a way that limits damage, reduces recovery time and costs, and helps prevent future incidents.

Why Incident Reports Matter

PURPOSE OF INCIDENT REPORTS:
  1. Documentation: Record what happened for legal and compliance
  2. Analysis: Understand how and why the incident occurred
  3. Improvement: Identify gaps and improve defenses
  4. Communication: Inform stakeholders at all levels
  5. Compliance: Meet regulatory reporting requirements
  6. Lessons Learned: Share knowledge to prevent recurrence
  7. Legal Protection: Demonstrate due diligence

Regulatory Requirements

Incident Report Framework

Standard Incident Report Structure

1. EXECUTIVE SUMMARY
   └─ Brief overview for management (1 page maximum)

2. INCIDENT DETAILS
   └─ Classification, severity, status, timeline

3. CHRONOLOGY / TIMELINE
   └─ What happened, when, and in what order

4. TECHNICAL ANALYSIS
   └─ Detailed technical findings

5. BUSINESS IMPACT
   └─ Data, financial, operational, reputational impact

6. ROOT CAUSE ANALYSIS
   └─ Why the incident happened

7. EVIDENCE COLLECTED
   └─ Chain of custody, evidence types

8. RECOMMENDATIONS
   └─ Short-term and long-term remediation

9. LESSONS LEARNED
   └─ What went well, what could improve

10. APPENDICES
    └─ Logs, screenshots, raw data, references

Writing Principles

The Incident Response Lifecycle

NIST Framework

                ┌─────────────────────────────────┐
                │         PREPARATION              │
                │  (Policies, tools, training)     │
                └───────────────┬─────────────────┘
                                │
                ┌───────────────▼─────────────────┐
                │     DETECTION & ANALYSIS         │
                │  (Monitor, detect, triage)       │
                └───────────────┬─────────────────┘
                                │
                ┌───────────────▼─────────────────┐
                │      CONTAINMENT, ERADICATION    │
                │        & RECOVERY                │
                └───────────────┬─────────────────┘
                                │
                ┌───────────────▼─────────────────┐
                │       POST-INCIDENT ACTIVITY     │
                │  (Lessons learned, reporting)    │
                └─────────────────────────────────┘

Phase Details

1. PREPARATION
   - IR policy and procedures
   - IR team roles defined
   - Tools and technologies in place
   - Communication plans established
   - Training conducted

2. DETECTION & ANALYSIS
   - Alert triggered / incident reported
   - Initial triage and assessment
   - Evidence collection begins
   - Scope determination
   - Severity classification

3. CONTAINMENT, ERADICATION & RECOVERY
   - Short-term containment (isolate affected systems)
   - Long-term containment (apply patches, change passwords)
   - Eradication (remove malware, close backdoors)
   - Recovery (restore from backups, return to production)

4. POST-INCIDENT
   - Investigation complete
   - Report written
   - Lessons learned meeting
   - Remediation plan implemented
   - Report filed for compliance

Incident Classification

Severity Levels

Incident Types

Incident Classification Table

Incident: BrightPath Education Data Breach
Classification: Data Breach / Unauthorized Access
Severity: HIGH (Level 1)
Status: Contained / Under Investigation
Confidentiality: CONFIDENTIAL — DO NOT DISTRIBUTE

Evidence Collection & Chain of Custody

Chain of Custody Form

═══════════════════════════════════════════
CHAIN OF CUSTODY FORM
═══════════════════════════════════════════

Case Number: IR-2026-001
Incident: Student Database Unauthorized Access

ITEM #1
────────
Description: Export of authentication logs (auth.log)
Source System: DC01.domain.local (Domain Controller)
Date/Time Collected: 2026-06-15 16:45 EDT
Collected By: Jordan Chen (Security Analyst)
Collection Method: Secure copy via winrm — sha256 verified
Hash (SHA256): a1b2c3d4e5f6...
Storage Location: \\forensic\cases\IR-2026-001\evidence\
Media Type: Network share (encrypted volume)

Transfer History:
┌──────────────┬─────────────────┬────────────────────────┐
│ Date/Time    │ From            │ To                     │
├──────────────┼─────────────────┼────────────────────────┤
│ 2026-06-15   │ Jordan Chen     │ Evidence Locker        │
│ 16:45        │ (Collector)     │ (Encrypted Share)      │
├──────────────┼─────────────────┼────────────────────────┤
│ 2026-06-16   │ Evidence Locker │ Dr. Sarah Williams     │
│ 09:30        │                 │ (Lead Investigator)    │
└──────────────┴─────────────────┴────────────────────────┘

Purpose: Analysis of login events during incident timeframe
Intact upon receipt? Yes ☐ / No ☐ (If no, explain)

Types of Evidence

DIGITAL EVIDENCE:
  • System logs (Windows Event Log, syslog)
  • Network logs (firewall, proxy, DNS)
  • Email headers and content
  • File system artifacts
  • Memory dumps
  • Disk images (forensic copies)
  • Database transaction logs
  • Application logs
  • SIEM alerts and correlation data
  • Packet captures (PCAP)

PHYSICAL EVIDENCE:
  • Hardware (if seized)
  • Written notes and documentation
  • Photographs of physical configuration

DOCUMENTARY EVIDENCE:
  • Access control lists
  • User account information
  • Policy documents
  • Previous security assessments
  • Employee records

Evidence Handling Rules

DO'S:
  ✓ Work from copies, never originals
  ✓ Document every action taken
  ✓ Use write blockers when acquiring drives
  ✓ Verify integrity with hashes (SHA256)
  ✓ Store evidence in secure, access-controlled location
  ✓ Maintain detailed chain of custody

DON'TS:
  ✗ Don't modify original evidence
  ✗ Don't use the suspect system for analysis
  ✗ Don't discuss case details unnecessarily
  ✗ Don't store evidence on unencrypted media
  ✗ Don't let evidence leave custody unattended

Timeline Creation

Incident Timeline Template

═══════════════════════════════════════════════════════════
INCIDENT TIMELINE — IR-2026-001
═══════════════════════════════════════════════════════════

Date: June 15, 2026

TIME (EDT)   | EVENT                                        | SOURCE
─────────────┼──────────────────────────────────────────────┼─────────────
08:45        │ Phishing email sent to employee jdoe@...    │ Email logs
09:12        │ Employee clicked link in phishing email      │ Proxy logs
09:13        │ Credentials phished via fake login page      │ Web logs
09:15        │ Attacker authenticated as jdoe (first login) │ AD logs
09:15        │ GeoIP: Login from unusual location (RU)      │ GeoIP alert
09:30-11:45  │ Attacker enumerated AD, mapped network       │ Event logs
11:50        │ Attacker accessed student database (SELECT)  │ DB logs
11:50-12:30  │ Data exfiltration: 5,000+ records exported  │ FW logs (outbound)
12:35        │ Attacker established persistence (scheduled task)│ Sysmon
13:00        │ Employee reported suspicious email to IT     │ Email
13:15        │ IT security team starts investigation        │ Log
14:30        │ Alert triggered: Unusual outbound traffic    │ SIEM
14:35        │ Incident declared (Level 1 - High)           │ IR team
15:00        │ Affected account disabled                    │ AD logs
15:15        │ Database server isolated from network        │ Network team
15:30        │ Containment verified                         │ Security team
16:00        │ Executive notified                           │ Email
16:30        │ Evidence collection begins                   │ Forensics
─────────────────────────────────────────────────────────────────────────

Timeline Best Practices

1. Use a SINGLE timezone throughout (EDT/EST or UTC)
2. Include "unknown period" notations where gaps exist
3. Source each event (how do you know this happened)
4. Note confidence level (Confirmed / Likely / Possible)
5. Include both attacker and defender actions
6. Add time between events (dwell time, response time)
7. Reference evidence items in brackets [E-001, E-002]
8. Keep updating as investigation progresses

Technical Analysis Section

Analysis Areas

1. EMAIL ANALYSIS
   - Original phishing email headers and body
   - Sender domain analysis (SPF, DKIM, DMARC)
   - Link destinations (URL analysis)
   - Attachment analysis (if any)

2. NETWORK ANALYSIS
   - Source IPs and geolocation
   - C2 server communications
   - Data exfiltration patterns
   - Protocols and ports used
   - DNS queries made

3. ENDPOINT ANALYSIS
   - Compromised user account activity
   - Processes executed
   - Files created/modified
   - Registry changes
   - Scheduled tasks/jobs

4. DATABASE ANALYSIS
   - Queries executed
   - Data accessed
   - Export operations
   - Authentication attempts

Sample Technical Analysis

TECHNICAL ANALYSIS REPORT
─────────────────────────────────────────

1. PHISHING EMAIL ANALYSIS
   ───────────────────────
   Original email received: jdoe@brightpath.edu
   From: "IT Support" <support@brightpath-verify.com>
   Subject: "Action Required: Verify Your Account"
   SPF: Fail (sending IP not authorized)
   DKIM: Not signed
   DMARC: No policy (p=none)
   Sending IP: 203.0.113.45 (hosted in Bulgaria)
   Link: https://brightpath-verify.com/login (Typosquatting)
   Link domain registered: June 10, 2026 (5 days before attack)
   Link domain registrar: GoDaddy (anonymous WHOIS)
   
2. ATTACKER ACCESS ANALYSIS
   ─────────────────────────
   Initial access: 2026-06-15 09:15 via VPN (203.0.113.50)
   VPN IP geolocation: Russia (Moscow)
   Protocols used: RDP via jump host
   Accounts used: jdoe (compromised), then escalated to svc_admin
   Lateral movement: 3 systems accessed between 09:30-11:45
   
3. DATA ACCESS
   ────────────
   Database: StudentRecords (SQL Server)
   Queries: SELECT * FROM Students WHERE GraduationYear >= 2024
   Records accessed: 5,247 student records
   Data exfiltrated: Confirmed via outbound traffic analysis
   Exfiltration method: HTTPS POST to 203.0.113.60
   Data size: ~45 MB
   
4. PERSISTENCE
   ────────────
   Method: Scheduled task created (TaskName: "SystemUpdate")
   Runs as: SYSTEM
   Interval: Daily at 3:00 AM
   Action: PowerShell reverse shell
   Artifact: C:\Windows\Tasks\SystemUpdate.ps1 (deleted on containment)

Business Impact Analysis

Impact Categories

📊 Educational example — The dollar figures below are scenario-based estimates for practicing impact assessment. No real costs involved.

Cost Calculation

💡 Educational example only — These are industry-average breach costs used to practice impact assessment. No actual spending is involved.

BREACH COST ESTIMATE
─────────────────────────────────────
Direct Costs:
  Incident response team (200 hours @ $150/hr)   $30,000
  Forensic investigation (external)               $25,000
  Legal counsel                                    $20,000
  Notification costs (5,247 recipients)            $15,000
  Credit monitoring (12 months)                    $40,000
  Public relations support                         $15,000
  System restoration and hardening                 $20,000
  ─────────────────────────────────────────────────
  Total Direct Costs                              $165,000

Indirect Costs:
  Productivity loss                                 $25,000
  Increased insurance premiums                       $10,000
  Potential regulatory fines                         $50,000+
  ─────────────────────────────────────────────────
  Total Indirect Costs                              $85,000+

TOTAL ESTIMATED COST: $250,000+
─────────────────────────────────────

Data Sensitivity Classification

AFFECTED DATA:
  ┌──────────────────────┬────────┬──────────┐
  │ Data Field           │ Type   │ Sensitivity │
  ├──────────────────────┼────────┼──────────┤
  │ Student Name         │ PII    │ High     │
  │ Date of Birth        │ PII    │ High     │
  │ Social Security #    │ PII    │ Critical │
  │ Home Address         │ PII    │ High     │
  │ Parent/Guardian Name │ PII    │ High     │
  │ Grade Level          │ Educational │ Low │
  │ Enrollment Status    │ Educational │ Low │
  │ Medical Info         │ PHI    │ Critical │
  └──────────────────────┴────────┴──────────┘

Root Cause Analysis

"5 Whys" Analysis

PROBLEM: Student database accessed by unauthorized attacker

WHY 1: Why was the attacker able to access the database?
       → Because the attacker had valid credentials (jdoe's account).

WHY 2: Why did the attacker have jdoe's credentials?
       → Because jdoe entered them on a fake login page.

WHY 3: Why did jdoe fall for the phishing page?
       → Because the email looked legitimate and bypassed spam filter.

WHY 4: Why did the email bypass the spam filter?
       → Because SPF/DMARC wasn't properly configured to reject spoofed emails.

WHY 5: Why wasn't SPF/DMARC properly configured?
       → Because email security configuration wasn't prioritized 
         during the last infrastructure review.

ROOT CAUSE: Inadequate email security controls (SPF/DMARC) 
and lack of MFA allowed a successful phishing attack to 
compromise credentials and lead to data breach.

Contributing Factors

SECURITY GAPS IDENTIFIED:
  1. No MFA on user accounts (allows credential-only access)
  2. SPF/DMARC not configured for email domain
  3. Database accessible from user workstations (no network segmentation)
  4. No data exfiltration detection (outbound data monitoring)
  5. Insufficient user security awareness (fall victim to sophisticated phishing)
  6. No privileged access management (PAM) for database access
  7. No alert for unusual geo-location logins
  8. Delayed detection (dwell time: ~5 hours before alert)

Recommendations & Remediation

Short-Term Remediation (0-30 Days)

Medium-Term Remediation (30-90 Days)

Long-Term Remediation (90+ Days)

Sample Incident Report

Executive Summary

═══════════════════════════════════════════════════════════
INCIDENT RESPONSE REPORT — IR-2026-001
═══════════════════════════════════════════════════════════

CLASSIFICATION: CONFIDENTIAL — PRIVILEGED

TO:          Board of Directors, BrightPath Education
FROM:        Security Incident Response Team
DATE:        June 22, 2026
SUBJECT:     Student Database Unauthorized Access Incident

───────────────────────────────────────────────────────────
EXECUTIVE SUMMARY
───────────────────────────────────────────────────────────

On June 15, 2026, BrightPath Education experienced a security
incident involving unauthorized access to the student database.
The incident was the result of a successful phishing attack that
compromised an employee's credentials.

TIMELINE OVERVIEW:
  • 08:45 — Phishing email sent
  • 09:15 — Credentials compromised, attacker gains access
  • 14:30 — Anomalous activity detected by SIEM
  • 14:35 — Incident declared
  • 15:30 — Containment achieved

IMPACT:
  • 5,247 student records accessed (PII including SSN)
  • Estimated financial impact: $250,000+
  • No evidence of lateral movement to other systems
  • No ransomware or malware deployed

ROOT CAUSE:
  • Inadequate email security (SPF/DMARC not configured)
  • No multi-factor authentication (MFA)
  • Lack of network segmentation (database accessible from user LAN)

STATUS: CONTAINED — All active threats neutralized

REMEDIATION (COMPLETED):
  ✓ All passwords forcibly reset
  ✓ Compromised account disabled
  ✓ Database server isolated and secured
  ✓ Backup verified and clean
  ✓ IOCs shared with threat intelligence partners

RECOMMENDATIONS (PRIORITY):
  1. Enable MFA for all accounts — IMMEDIATE
  2. Implement network segmentation — 30 DAYS
  3. Deploy DLP solution — 60 DAYS
  4. Conduct security awareness training — 30 DAYS

Full Report Structure Reference

[COMPLETE REPORT — TABLE OF CONTENTS]

1. Executive Summary ................................... 1
2. Incident Classification ............................ 2
3. Detailed Timeline .................................. 3
4. Technical Analysis ................................. 5
   4.1 Phishing Email Analysis
   4.2 Network Traffic Analysis
   4.3 Endpoint Analysis
   4.4 Database Access Analysis
5. Evidence Inventory ................................. 9
6. Chain of Custody .................................. 10
7. Business Impact Assessment ........................ 12
8. Root Cause Analysis ............................... 14
9. Containment Actions ............................... 15
10. Remediation Plan .................................. 16
11. Lessons Learned ................................... 18
12. Recommendations ................................... 19
13. Appendices ........................................ 20
    A. Raw Log Data
    B. Phishing Email (Full Headers)
    C. IOC List (Indicators of Compromise)
    D. Regulatory Notification Requirements
    E. Communications Log

Incident Report Templates

Quick Incident Template (1-Pager)

# INCIDENT REPORT — QUICK REFERENCE

**Case ID**: IR-YYYY-###
**Date Reported**: 
**Reported By**: 
**Incident Type**: 
**Severity**: Critical / High / Medium / Low

**SUMMARY**:
[2-3 sentences describing the incident]

**AFFECTED SYSTEMS**:
- System 1 (IP, Role)
- System 2 (IP, Role)

**IMPACT**:
- Data: 
- Systems: 
- Users: 

**TIMELINE**:
- Detection: 
- Containment: 
- Eradication: 
- Recovery: 

**ROOT CAUSE**:
[Brief explanation]

**ACTIONS TAKEN**:
- [ ] Action 1
- [ ] Action 2
- [ ] Action 3

**NEXT STEPS**:
- [ ] Step 1
- [ ] Step 2

Evidence Log Template

## EVIDENCE LOG

| Item # | Description | Source | Collector | Date/Time | Hash (SHA256) | Location |
|--------|-------------|--------|-----------|-----------|---------------|----------|
| E-001 | | | | | | |
| E-002 | | | | | | |
| E-003 | | | | | | |

Common Mistakes to Avoid

Deliverables Checklist

Before marking this project complete:

• Executive summary — 1-page overview for management
• Incident timeline — Chronological event list with timezone
• Technical analysis — Detailed findings with evidence
• Evidence log — Chain of custody documentation
• Business impact assessment — Financial, data, operational impact
• Root cause analysis — "5 Whys" or equivalent
• Containment actions — What was done to stop the incident
• Remediation plan — Short, medium, long-term actions
• Lessons learned — What went well, what to improve
• IOC list — Indicators of compromise for sharing