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

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?