What should the final cyber-incident report achieve?¶

The final cyber-incident report should let a decision-maker understand what happened, how the evidence supports that account, what remains uncertain and what action or risk remains. Technical detail serves those conclusions; it is not the report's purpose by itself.

The report should be usable without requiring the reader to interpret raw logs independently.

Connect evidence to the supported incident¶

Organise the account around the material sequence and findings, which may include:

• scope, affected systems and accounts;
• initial access, persistence and movement;
• collection, transfer, disruption or destruction;
• operational and financial impact;
• response, containment and recovery;
• technical and personal attribution;
• provider, intelligence and specialist evidence; and
• unresolved gaps, remaining exposure and next decisions.

For each major conclusion, distinguish the observed records from their interpretation. Keep account, device, session, infrastructure and person separate unless evidence supports the connection. Do not replace that analysis with a dramatic incident label.

Make dependencies and uncertainty visible¶

Identify conclusions adopted from provider interpretation, external intelligence or specialist analysis, including the relevant confidence and limitations. A later reviewer should be able to tell what the investigation independently corroborated and what depends on another body's assessment.

Place material uncertainty beside the finding and in the operational summary. Technical annexes can retain detailed logs, methods and tables, while the main report explains the supported sequence, practical consequences and decisions in clear language.

The protected Dodgy Dave scenario that follows demonstrates this principle in an offender-perspective narrative without changing the evidential standards.