An incident response case management workflow

1. Record the triage decision

Capture the source, receipt time, affected service, initial impact and reason for investigating. Separate the event’s occurrence time from the time your team learned about it. Check for an existing case before creating another one, and preserve the reference when classifying a report as a duplicate.

TheHive documents reviewing alert observables, adding analyst context, then closing an alert with a disposition or creating a case. Use a short rationale for either outcome. A closed alert should explain why no further investigation is needed, not merely disappear from the queue.

• TheHive — Alert management

2. Assign decisions and concrete tasks

Name one case owner and identify who can authorize disruptive actions. Turn the initial questions into tasks with an assignee and completion condition: confirm the affected account, preserve a stated log window, or determine whether a service is still exposed.

Record urgency with a reason and revisit it as impact becomes clearer. Keep “suspected affected” distinct from “confirmed affected” assets. A task marked done should link to an observation or output, while a blocked task should name the missing access, evidence or decision.

3. Keep evidence, actions and hypotheses distinct

Use separate entries for an observed event, an analyst interpretation and an action taken by the response team. Each should carry a timestamp and author. Reference evidence in controlled storage with its collection details instead of duplicating sensitive archives across unrelated channels.

DFIR-IRIS describes a collaborative investigation workspace. Its upstream repository currently recommends the stable v2 release for production while v3 is beta. Evaluate the actual version you plan to run; do not design a required workflow around a feature seen only in beta documentation.

• DFIR-IRIS — Project and release guidance

4. Make a shift handoff a deliberate checkpoint

Summarize current impact, confirmed scope, containment state, important unknowns and the next three actions. Include pending decisions and external commitments, with their owners. Ask the incoming responder to open one evidence reference and identify the next action to confirm the handoff is usable.

Prepare different updates for technical responders, service owners and external parties. Preserve the source’s sharing boundary and limit each update to what its recipients need. Keep a record of what was shared, with whom and when. TLP labels express sharing boundaries; actual permissions and delivery choices still need to enforce them.

• FIRST — Traffic Light Protocol 2.0

5. Close with evidence and follow-up owners

Agree closure conditions before marking the case resolved. Record recovery verification, remaining uncertainty, outstanding remediation and who accepts any residual issue. Distinguish restoring service from completing the investigation: one can happen while the other still has open work.

Review what delayed the response or produced incorrect decisions. Convert useful lessons into specific updates to collection, detections, contacts or task templates, each with an owner. Exercise the revised handoff with a small scenario. A case-management tool can preserve the record; it cannot decide that the organization is ready to close.

• NIST SP 800-61 Rev. 3 — Incident response recommendations