Incident Reporting and Post Incident Review

What it is

Incident documentation is the written record of what happened, what the team did and what was learned. It is created during the incident, not rebuilt afterwards from memory.

A post incident review (also called a lessons learned review or after action review) is a structured meeting held once the incident is under control. Its purpose is to improve the organisation, not to find someone to blame.

How it works

Documenting during the incident

Keep a running log, with a timestamp for every entry. Use a consistent time standard such as Coordinated Universal Time (UTC), and name who did what.

• Alerts and how they were first noticed.
• Observations and evidence collected, with locations.
• Decisions made, who approved them and why.
• Actions taken, such as isolating a host or disabling an account.
• People and groups notified, and when.
• Open questions and assumptions.

A good log lets a new person take over the response without a long briefing, and it supports the later report and any legal process.

Communication during an incident

Communication has to be controlled. The plan names who may speak to whom.

Rules that keep communication safe:

• Share on a need to know basis, since rumours and leaks can harm the response.
• Use approved and secure channels, and an out of band route if email is compromised.
• Label sensitive messages with handling rules, for example with the Traffic Light Protocol.
• Avoid speculation. State what is known, what is not known and when the next update will come.
• Direct all outside questions to the named spokesperson.

Operational security awareness. Staff are part of the defence, so give them short, factual messages during and after an incident.

• Send an advisory with what to watch for and what to do, such as "a phishing message with this subject is circulating: report it, do not click".
• Say who to report to, and use only approved channels. Do not discuss the incident on social media, public chat or personal accounts.
• Tell people not to investigate on their own or delete anything, because that can destroy evidence or alert the attacker.
• Keep the details of the response private, since an attacker may be reading the same channels.
• Afterwards, send a brief summary of lessons and refresh training or phishing exercises.

The incident report

A final report usually includes:

1. Executive summary: a short, plain statement of what happened and the business impact.
2. Timeline: key events from first sign to recovery, with times.
3. Scope and impact: systems, data and users affected, and costs or downtime if known.
4. Cause: how the attacker got in and the root cause.
5. Response actions: detection, containment, eradication and recovery steps.
6. Evidence summary: what was collected and where it is stored.
7. Findings and recommendations: what to change, ranked.
8. Appendices: technical details such as indicators of compromise.

Write the summary for non technical readers, and put detail in appendices for technical staff and auditors.

Running a post incident review

Hold the review soon after recovery, while details are fresh and before people move on to other work. Invite everyone who played a part.

Typical questions are:

• What happened, and in what order?
• How and when was it detected, and could it have been detected sooner?
• Did the plan and playbooks work, and were roles clear?
• What slowed us down, such as missing access, tools or contacts?
• What went well and should be kept?
• What must change in technology, process or training?

Use a blameless approach. Focus on how the system allowed the failure, not on who made a mistake, because people hide problems when they fear punishment.

Turning findings into change

Reviews fail when nothing changes. Every recommendation becomes an action item with an owner, a due date and a way to check completion. Typical outputs are:

• Updated incident response plan and playbooks.
• New or tuned detection rules.
• Patches, hardening changes and improved controls.
• Added logging or tooling.
• Training and exercises based on the scenario.
• Updates to the risk register.

Track the actions until they are done, and report progress to management. Retain the report and evidence according to the retention policy and any legal hold.

The internal threat intelligence report

An internal threat intelligence report is written from the organisation's own incidents, alerts and hunts, so it is tailored to the local environment and not generic. A typical report contains:

• Observed campaigns: who or what targeted the organisation, and when.
• Indicators of compromise: hashes, domains and addresses, with first seen and last seen dates and a confidence level.
• Techniques: the attacker behaviour, mapped to MITRE ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge).
• Trends: changes in volume or targets since the last period.
• Recommended actions: blocks, patches, new detections, awareness messages and hunts.

Put a short summary first for management, and the indicators in a technical annex for analysts and tools. Mark the report with a sharing label such as the Traffic Light Protocol.