Transfer responsibility, not just a transcript
A handover should state the current incident assessment, confirmed scope, remaining hypotheses, containment status, service impact, and the next decisions. List completed work separately from pending tasks. Each pending item needs an owner, priority, deadline or review point, and an evidence reference. Include constraints such as an expiring temporary control, a supplier call, or an approval that has not yet been granted.
Use a short live exchange where possible, supported by the controlled incident record. The incoming lead should confirm ownership and restate the immediate priorities, especially when a high-impact change is imminent. A chat archive alone forces the new shift to reconstruct decisions from fragments. Preserve the action history, but make the current position and unresolved work easy to identify without replaying the entire incident.
Make the after-action report useful
An after-action report explains the incident timeline, scope, impact, response decisions, evidence limits, and recovery outcome. Lessons learned identify what helped and what hindered the response. Root cause analysis examines enabling conditions and contributing failures rather than treating the first visible symptom as the whole explanation. Record corrective actions with owners and validation criteria, and track them after the incident is administratively closed.
An internal threat intelligence report can translate the incident into relevant defensive knowledge. Describe observed behaviours, affected technologies, confidence, and useful detection or hunting leads for the organisation’s environment. Keep sensitive case detail restricted and avoid unsupported actor attribution. Indicators should carry context and review expectations, because a temporary address may become stale while the underlying behavioural lesson remains useful to defenders.
Define the measure before comparing performance
Operational metrics need explicit start and stop events, a reporting period, and a population. Detection time may depend on an estimated first malicious event; report that uncertainty. Response activation, containment, verified remediation, service restoration, and administrative closure are different milestones. Label the interval being measured rather than using an ambiguous abbreviation. Compare similar incident classes and inspect distributions as well as averages.
Detection-quality rates require the right denominators and labelled outcomes. The fraction of investigated alerts found benign is not the statistical false-positive rate, which uses all actual negatives. True-positive rate also requires knowledge of missed positives, often assessed through controlled evaluation. Falling alert volume can reflect better tuning or lost telemetry. Pair speed and volume metrics with coverage, verified outcomes, and evidence of remaining work.
- Alert volume: count alerts in a stated period, noting collection coverage and grouping rules.
- False-positive rate: FP / (FP + TN) in a labelled evaluation; report benign-alert share separately if only investigated alerts are known.
- True-positive rate: TP / (TP + FN) in a labelled evaluation; unexplored incidents make operational estimates incomplete.
- Mean time to detect: average detection time minus the estimated first malicious event, with confidence and exclusions recorded.
- Mean time to respond: define the endpoint explicitly, such as detection to response activation, and use it consistently.
- Mean time to remediate: define the start event and end at verified remediation, keeping service restoration distinct.
- Mean time to close: state when the case clock starts and when administrative closure occurs; show unresolved cases separately.
- Phishing campaign click rate: specify unique clickers and the eligible delivered-recipient population, plus campaign scope and interpretation limits.