Blue Teaming

13 min read

A step-by-step guide to writing incident response reports (free template inside)

Discover how to write an incident response report, including an incident reporting template, and a step-by-step reporting process for analysts.

sebh24,
Mar 22
2024

What is an incident response report?

In cybersecurity, the question isn't whether a security incident will transpire, but rather when it will occur. This is why we require incident response reports to act as a conduit between the identification and remediation of threats.

It serves to archive past incidents, providing an invaluable source of lessons learned from previous mistakes. The learnings can be seamlessly integrated into a broader strategy for preempting and mitigating future threats.

Essentially, an incident response report encompasses the process by which an organization handles a breach. It aims to quickly identify an attack, minimize damage, contain, and remediate the cause to reduce the risk of future incidents.

Incident response report template (+ example)

Sample incident report template 👇

A real-world example of an incident response report created by the HTB Academy team. Use it as a template for your next report!

See incident response report template

Why are incident response reports important?

Incident Response (IR) reports are the true narrative of a cybersecurity incident's handling capturing the good, the bad, and the ugly. When accurately written, they serve as a critical platform for reflection and adjustment, spotlighting gaps in processes, people, and technology.

The real power of these reports lies in their ability to turn hindsight into foresight, allowing teams and organizations to rectify issues before they escalate into more significant threats.

Sabastian Hague (sebh24), Defensive Content Lead, Hack The Box

Incident response plans are critical as they help limit and mitigate a security breach's impact. This helps manage an organization’s financial and reputational damage while providing a blueprint for future incidents.

As a result, cybersecurity teams can consistently respond to attacks.

Writing effective incident response reports means striking a balance between detail and accessibility. A good report should be understandable to both technical and non-technical audiences.

A well-organized incident report is a clarifying tool for stakeholders across various functions, including legal departments ensuring regulatory compliance, executive management assessing risk profiles, and CFOs evaluating financial repercussions.

This clarity benefits the overall incident response process:

Improved response: Consistent incident response reports enable teams to learn how to spot the early signs of an attack, helping faster retention and recovery.
Early threat mitigation: Speed up forensic analysis, minimize the event duration, and any potential negative impacts.
Regulatory compliance: Many regulatory and certification bodies (such as the PCI DSS) require organizations to have an incident response plan.

💡 Recommended read: Our top 5 DFIR labs for beginner analysts (to get good fast)

Learn how security incident reporting works

Our Academy module on Security Incident Reporting teaches teams everything they need to know about documenting and reporting an incident.

Explore the art of identifying and classifying security incidents.
Understand the systematic process of incident documentation.
Perfect communication strategies during incidents.
Dive into the critical components of a detailed incident report.
Analyze a real-world incident report following best practices.

Learn incident reporting today

Incident identification and categorization

Organizations are threatened by many different attacks. So, a systematic approach to identifying and classifying security incidents is required.

How can we quickly identify security incidents? These are the three main sources:

Source	Description
Security systems	Some excellent sources for identification include IDS/IPS, EDR/XDR, SIEM tools, or even basic anti-virus alerts and NetFlow data.
Human observations	Users may notice and report suspicious activities, unusual emails, or systems behaving abnormally.
Third-party notifications	Partners, vendors, or even customers might inform organizations about any vulnerabilities or breaches they are experiencing.

Once an incident has been identified, it must quickly be categorized as this will impact the prioritization and allocation of appropriate resources.

Common incident types include:

Malware: Malicious software encompassing viruses, worms, and ransomware.
Phishing: Attempts to gather sensitive information, predominantly via email.
DDoS attacks: Deliberate attempts to inundate a system or network, thereby disrupting its regular functionality.
Unauthorized access: Incidents where unauthorized entities gain access to systems or data.
Data leakage: Exposure of confidential data, both within and outside the organizational perimeter.
Physical breach: Unauthorized physical access to secure locations.

Now that the nature of the incident has been categorized, individuals will be able to refer to incident response plans and past reports to understand how to react.

💡Get our full incident response template for free.

But what about prioritization? We can classify incidents with the following severity levels:

Critical (P1): Imminent threats that jeopardize core business functionalities or sensitive data, requiring immediate intervention.
High (P2): Threats to business operations that, while not immediately detrimental, are of elevated priority.
Medium (P3): Incidents that, although not posing an immediate threat to business operations, warrant timely attention.
Low (P4): Trivial incidents or routine anomalies that can be managed within standard operational workflows.

Incident reporting process

A solid incident reporting process will serve as a cohesive framework to identify, mitigate, retain, and remediate security breaches.

Here is the step-by-step report process that should be followed in the event of an incident:

1. Initial incident detection

Before we can report on an incident, we must first detect and acknowledge it. As mentioned previously, incidents can be detected via tools, humans, or a third party. Threat actors can also detect themselves, for example, when asking for a ransom.

2. Preliminary analysis

During this phase, the scope and potential ramifications of the security incident must be determined. The incident should be categorized based on our previously established classification and severity metrics.

3. Incident logging

Every action and observation related to the security incident should be meticulously logged using an established system.

Popular platforms for this purpose include JIRA and TheHive Project.

Lacking a system in place? Spreadsheets can also be used and even old-school pen and paper in the worst-case scenario!

4. Notification of relevant parties

communicating to stakeholders on an incident

Stakeholders and wider teams must be quickly notified about any security incidents. These can be separated into two groups:

Internal communications: relevant internal departments, such as IT, legal, PR, and executive teams, should be alerted. In cases where the incident has widespread and severe implications, an organization-wide notification may be warranted.
External communications: depending on the incident's nature and impact, external communications may be necessary. This could involve notifying customers, partners, regulatory bodies, or even the general public.

5. Detailed investigation & reporting

The duration of this phase can vary significantly. Ranging from a couple of days to potentially years. What's crucial here is a comprehensive technical analysis coupled with a compilation of all findings. This in-depth investigation is vital for understanding the incident's full impact.

6. Final report creation

The culmination of your role as a security analyst or incident responder is the creation of a finalized incident report. This document will provide regulators, insurers, and executive leadership with a detailed account of the incident, its origins, and the remedial actions taken.

7. Feedback loop

Post-incident reflection is essential for enhancing our preparedness for future incidents. This involves revisiting and analyzing the incident to identify areas for improvement.

Elements of an incident report

1. Executive summary

This is the opening to the report, designed to speak to a broad audience and so it’s advised to avoid too many technical details.

Its purpose is to provide readers with a succinct overview, key findings, immediate actions executed, and the impact on stakeholders.

Since many stakeholders may only read the executive summary, it's essential to get this section right. Here’s what should be included:

Section	Description
Incident ID	Unique identifier for the incident.
Incident Overview	Provide a concise summary of the incident's events and explicitly state its type. This should also encompass the estimated time and date of the incident, as well as its duration, the affected systems/data, and the status.
Key Findings	Enumerate any findings that emerged from the incident. What was the root cause? Was a specific CVE exploited? What data, if any, was compromised, exfiltrated, or jeopardized?
Immediate Actions Taken	Outline the immediate response measures taken. Were the affected systems promptly isolated? Was the root cause identified? Did we engage any third-party services, and if so, who were they?
Stakeholder Impact	Assess the potential impact on various stakeholders. For instance, did any customers experience downtime, and what are the financial ramifications? Was employee data compromised?

2. Technical analysis

In this section we dive into, you guessed it, the technical side of things.

This is the largest part of an incident response report and it should include the following:

Affected systems and data: All systems and data that were either potentially accessed or definitively compromised during the incident.
Evidence sources and analysis: Share the evidence examined, results, and what methodology was used.
Indicators of Compromise (IoCs): This enables us to attribute the attack to a specific threat group based on the IoCs identified.
Root cause analysis: Elaborate on the underlying cause of the security incident (vulnerabilities exploited, failure points, etc.).
Technical timeline: Vital to understand the sequence of events, including initial compromise, enumeration, lateral movement, data access, containment times, eradication times, and recovery times.
Nature of the attack: Deep-dive into the type of attack, as well as the tactics, techniques, and procedures (TTPs) employed by the attacker.

3. Impact analysis

This is where an evaluation of the adverse effects that the incident had on the organization's data, operations, and reputation will be recorded.

This analysis aims to quantify the extent of the damage caused by the incident, identifying which systems, processes, or data sets have been compromised. It also assesses the potential business implications, such as financial loss, regulatory penalties, and reputational damage.

4. Response and recovery analysis

Outline the specific actions taken to contain the security incident, eradicate the threat, and restore normal operations.

This section usually includes:

Immediate response actions

Revocation of access

Identification of compromised accounts/systems: A detailed account of how compromised accounts or systems were identified, including the tools and methodologies used.
Timeframe: The exact time when unauthorized access was detected and subsequently revoked, down to the minute if possible.
Method of revocation: Explanation of the technical methods used to revoke access, such as disabling accounts, changing permissions, or altering firewall rules.
Impact: Assessment of what revoking access immediately achieved, including the prevention of data exfiltration or further system compromise.

Containment strategy

Short-term containment: Immediate actions taken to isolate affected systems from the network to prevent lateral movement of the threat actor.
Long-term containment: Strategic measures, such as network segmentation or zero-trust architecture implementation.
Effectiveness: An evaluation of how effective the containment strategies were in limiting the impact of the incident.

Eradication Measures

Malware removal

Identification: Detailed procedures on how malware or malicious code was identified, including the use of Endpoint Detection and Response (EDR) tools or forensic analysis.
Removal techniques: Specific tools or manual methods used to remove the malware.
Verification: Steps taken to ensure that the malware was completely eradicated.

System patching

Vulnerability identification: How the vulnerabilities were discovered, including any CVE identifiers if applicable.
Patch management: Detailed account of the patching process, including testing, deployment, and verification stages.
Fallback procedures: Steps to revert the patches in case they cause system instability or other issues.

Recovery steps

Data restoration

Backup validation: Procedures to validate the integrity of backups before restoration.
Restoration process: Step-by-step account of how data was restored, including any decryption methods used if the data was encrypted.
Data integrity checks: Methods used to verify the integrity of the restored data.

System validation

Security measures: Actions taken to ensure that systems are secure before bringing them back online, such as reconfiguring firewalls or updating Intrusion Detection Systems (IDS).
Operational checks: Tests conducted to confirm that systems are fully operational and perform as expected in a production environment.

Post-incident actions

Monitoring

Enhanced monitoring plans: Detailed plans for ongoing monitoring to detect similar vulnerabilities or attack patterns in the future.
Tools and technologies: Specific monitoring tools that will be employed, and how they integrate with existing systems for a holistic view.

Lessons learned

Gap analysis: A thorough evaluation of what security measures failed and why.
Recommendations for improvement: Actionable recommendations based on the lessons learned, categorized by priority and timeline for implementation.
Future strategy: Long-term changes in policy, architecture, or personnel training to prevent similar incidents.

5. Diagrams

Being such a text-heavy and technical report, diagrams can help to communicate the incident more effectively.

Creating an incident flowchart, affected systems map, and attack vector diagram can be hugely beneficial.

Utilize arrows and annotations to trace the attacker's navigation and (post-)exploitation activities through our defenses visually.

6. Appendices

A section for supplementary material that provides additional context, evidence, or technical details that are crucial for a comprehensive understanding of the incident, its impact, and the response actions taken.

Despite being the final part of an incident report, it’s an essential piece of the puzzle as the appendices provide credibility and depth to the narrative presented in the main body of the report.

Some of the following might be included here:

Log files.
Network diagrams (pre-incident and post-incident).
Forensic evidence (disk images, memory dumps, etc.).
Code snippets.
Incident response checklist.
Communication records.
Legal and regulatory documents (compliance forms, NDAs signed by external consultants, etc.).
Glossary and acronyms.

💡Top tip: keep your communications private during cybersecurity incidents

We’ve established just how important effective communication is in the face of an incident. But how do we keep critical information under wraps while remaining compliant?

Here are our top tips:

Encryption: We must ensure that every piece of information we share is wrapped in robust end-to-end encryption. Which systems were attacked and what vulnerabilities were exploited should be considered top secret.
Authentication and authorization: Access to our communication channels should be strict. Never forget the importance of multi-factor authentication (MFA) to double-check the identities of those trying to access the channel.
Data integrity: We need to be certain that our messages remain unaltered during transit.
Ephemeral communications: for those top-secret discussions, we might consider using messaging platforms that auto-destruct messages post-reading.
Air-gapped communications: In situations where we suspect our primary communication backbone might be under threat, we might need to resort to air-gapped systems. These systems are our last line of defense, completely isolated from other potentially compromised networks.
Data privacy laws: If we're discussing or sharing personal data, especially of EU residents, we need to consider GDPR mandates.
Breach notification mandates: Certain jurisdictions have timelines for breach notifications.
Record-keeping: Some regulations mandate a clear record of all incident-related communications. So, in some cases, ephemeral communications may not be possible.
Cross-border communications: Some nations have stringent data sovereignty laws, dictating the hows and wheres of data transmission and storage.
Chain of custody: If there's even a hint that legal actions might follow the incident, we need to maintain an unbroken chain of custody for all communications.

Incident response report best practices

Now that you know how to write your own incident response report, we wanted to share some key takeaways you should always prioritize:

Root cause analysis: Always aim to find the root cause of the incident to prevent future occurrences.
Community sharing: Share non-sensitive details with a community of defenders to improve collective cybersecurity.
Regular updates: Keep all stakeholders updated regularly throughout the incident response process.
External review: Consider third-party cybersecurity specialists to validate findings.

While no one wants to have to report an incident, it’s common practice in the world of analysts. Learn all about incident reporting on Academy, and explore our SOC Analyst path for more defensive-related content.

Author Bio: Sabastian Hague (sebh24), Defensive Content Lead, Hack The Box

Sabastian Hague is a seasoned cybersecurity professional with over eight years of experience in the field. After serving in the Royal Air Force as a specialist in all things SOC, he went on to work for Vodafone's global CERT team before taking on a role as a senior security consultant with SpiderLabs and working on numerous high-profile incidents. He is now the Defensive Content Lead at Hack The Box.

Seb has numerous industry certifications, including GIAC Certified Detection Analyst (GCDA), GIAC Continuous Monitoring Certification (GMON), GIAC Certified Incident Handler (GCIH), GIAC Certified Intrusion Analyst, Offensive Security Certified Professional (OSCP), Blue Team Level 1 (BTL1), Blue Team Level 2 (BTL2), Cybereason Threat Hunter (CCTH).

You can connect with him on LinkedIn or Twitter.

Latest News