Phase 8: Report and Document

This phase's objective is to consolidate all findings, actions taken, and decisions made during the phishing incident investigation and response. This documentation serves as a historical record, a communication tool, and a foundation for continuous improvement in the organization's cybersecurity posture.

Well-documented phishing cases enable:

• Better incident response consistency

• Improved SOC performance metrics

• Reuse of IOCs in future detection/hunting

• Compliance with audit, legal, or regulatory requirements

• Sharable insights for training and awareness

Key Principles for Documentation

Accuracy: Stick to the facts. Avoid assumptions.
Completeness: Cover the entire incident lifecycle.
Clarity: Use professional, concise language for technical and non-technical readers.
Standardization: Use your organization’s incident reporting templates or forms.

Below is a breakdown of the incident report sections and associated content.

1. Incident Summary: What happened, who was affected

   • It should be brief, focus on the highlights, and be curated for non-technical staff and users.

   • Items that should be included:

     • Title - A short summary (e.g., “Phishing Email Impersonating IT Helpdesk”)

     • Incident ID - Ticket or case number from the ticket or case management system.

     • Reported date and time - When the incident was first reported

     • Detection method - How it was discovered (e.g., user report, SIEM alert, email filter)

     • Analyst name(s) - Who worked on the case

     • Verdict - Malicious, Suspicious, Benign

2. Phishing Message Details: Sender, content, links, attachments

   • Document all relevant artifacts and attributes of the phishing email or message. This will include:

     • Sender name

     • From Address

     • Reply-To / Return Path

     • Subject

     • Date/Time Sent

     • Target(s)

     • Message-ID

     • Body Excerpt

     • Attachments / Links

3. Technical Analysis Summary: Summarize evidence from phases 2–6

   • Header & Sender verification:

     • SPF/DKIM/DMARC result

     • Header anomalies

     • IP origin and reputation

   • Content Analysis:

     • Social engineering tactics

     • Attachment details and file hash

     • Suspicious URLs/domains

   • Threat Intelligence:

     • Reputation scores from VirusTotal, Talos, AbuseIPDB, etc.

     • Malware family (if applicable)

     • Campaign/actor association

4. Containment and Response Actions: Containment, user, and system remediation

   • Record everything done to mitigate the incident:

     • Quarantine, e.g., “Email removed from 87 inboxes using Microsoft Defender Explorer”

     • IOC Blocking, e.g., “Blocked domain via proxy and added to DNS deny list”

     • Credential Resets, e.g., “Reset credentials for 5 users who clicked the phishing link”

     • Device Isolation, e.g., “Endpoint isolated by CrowdStrike EDR”

     • User Notification, e.g., “Affected users were alerted and instructed to reset passwords”

     • SIEM/EDR Correlation, e.g., “Searched for lateral movement or reuse of IOC across logs”

5. Impact Assessment: Users/devices affected, data access

   • Explain what the phishing attempt affected and what damage was avoided or occurred.

     • Scope - “Phishing email reached 87 users across 3 departments”

     • User Interaction - “5 users clicked; 2 submitted credentials”

     • System Impact - “1 endpoint infected; contained with no lateral movement”

     • Data Accessed - “No sensitive data exfiltrated” (or specify otherwise)

6. Indicators of Compromise: Structured list for future reference

   • Provide a structured list of all collected IOCs.

   • Example format:

7. Lessons Learned: Insights for Improvement

1. • Analysts should answer the questions to improve future identification, containment, and remediation steps.

     • Was this a repeat attack or a new campaign?

     • Could this have been detected earlier?

     • Did any gaps in our tools or processes delay the response?

     • What could be automated or improved?

8. Recommendations

1. • The analyst preparing the report must propose short- and long-term improvements:

     • Add a detection rule to the SIEM for the subject line

     • Increase user awareness training on social engineering

     • Monitor the domain/IP for re-use

     • Review allowlists or filtering gaps in the email gateway

9. Appendices (Optional) 

1. • Screenshots of the phishing message

   • Links to sandbox reports or URL scans

   • Logs or playbook execution summaries

   • Related case IDs or threat intel references

Common Mistakes to Avoid

• Failing to record when and how actions were taken

• Not saving the original phishing email (including headers)

• Omitting the IOCs, which could help block future attacks

• Writing vague conclusions (e.g., “some users affected” instead of actual counts)

TIP: UUse a standardized phishing incident report template and create a reporting checklist. This reduces mistakes and ensures no key information is missed.