---
{
  "title": "Incident reporting and handover",
  "summary": "Separate facts, judgments, unknowns, and recommendations.",
  "topic": "soc",
  "level": "Beginner",
  "updated": "2026-10-12",
  "units": [
    3
  ],
  "aliases": [],
  "sources": [
    {
      "title": "NIST: Incident Response Recommendations, SP 800-61 Rev. 3",
      "url": "https://csrc.nist.gov/pubs/sp/800/61/r3/final"
    }
  ],
  "published": "2026-10-02",
  "editorialVersion": 2
}
---

## Explain the event so others can act

Incident reporting communicates what happened, what the evidence supports, what the team did, and what remains unresolved. A report may serve responders, service owners, leadership, or specialist advisers. Each audience needs a different level of technical detail, but the factual basis should remain consistent.

Separate observed facts from analytical judgments. “The audit record shows an external forwarding rule created at 09:14 UTC” is an observation. “The account was probably compromised before that time” is a judgment that needs supporting reasoning. “The available logs do not establish which messages were read” is a limitation, not an embarrassing detail to hide.

## Build a useful incident narrative

Imagine a fictional staff-account incident. Start with the reported symptom and affected service. Present the significant events in a consistent time zone, explaining any clock or ingestion uncertainty. Reference the records used to build the sequence rather than copying every log line into the main narrative.

Describe impact in terms the audience can understand: interrupted access, affected information, unauthorized configuration, or business disruption. If the exposed dataset is still being assessed, use a provisional description and identify the owner of that assessment.

Actions should include their purpose and observed outcome. “Sessions were revoked to interrupt continued access; subsequent sign-in attempts failed” is more useful than “Account fixed.” Explain whether other credentials, application grants, or devices remained under review.

## Handover is a report with a next step

A shift handover should state the current scope, working hypotheses, actions completed, restrictions still in force, pending evidence, and the next decisions. Assign each open item to a person or team. Include the case location and important timestamps so the receiving analyst does not reconstruct basic context from chat history.

Avoid ambiguous labels such as “false positive” without an explanation. A signal can detect a real action that turns out to be authorized. Recording that distinction helps [[detection-engineering]] improve the rule without suppressing behavior that still matters elsewhere.

Sensitive evidence belongs in appropriately controlled storage. A broadly distributed executive update does not need raw tokens, personal correspondence, or unrestricted links to forensic material. Share the minimum detail that enables the intended decision.

## Make recommendations traceable

Tie each recommendation to a finding and an owner. If limited audit retention prevented scoping, propose a reviewed retention and collection change rather than a vague instruction to “improve monitoring.” Explain what future question the change would help answer.

For practice, write a six-sentence leadership update and a technical handover for the same fictional account incident. Check that they agree on the facts and uncertainty. [[incident-timeline]] supports the sequence, while [[source-evaluation]] helps distinguish reliable evidence from an unverified early report.

## Related concepts

- [[chain-of-custody]]
- [[soc-metrics]]