Incident response process flowchart

Incident response process flowchart

A worked example to adapt. Rename steps, add branches and owners to match how your team actually works.

flowchart TD
  s(["Alert or user report"])
  ack["On-call acknowledges"]
  tri["Triage: confirm impact"]
  d1{"Real incident?"}
  close(["Close as false alarm"])
  d2{"Severity 1 or 2?"}
  page["Page incident commander, open status page"]
  fix["Contain and mitigate"]
  d3{"Service restored?"}
  comm["Post updates to stakeholders"]
  res["Resolve and monitor"]
  pm["Blameless postmortem and action items"]
  e(["Incident closed"])
  s --> ack
  ack --> tri
  tri --> d1
  d1 -->|No| close
  d1 -->|Yes| d2
  d2 -->|Yes| page
  d2 -->|No| fix
  page --> fix
  fix --> d3
  d3 -->|Yes| res
  d3 -->|No| comm
  comm --> fix
  res --> pm
  pm --> e

About this incident response process flowchart

When something breaks, nobody should have to decide the process on the spot. An incident response flowchart answers the first questions in advance: is this real, how severe is it, who leads, and when do we tell customers.

This example follows a common software operations pattern. Security incidents add evidence preservation and legal or regulatory notification steps; add those branches if your plan covers breaches.

Step by step

1. Detect. An alert fires or a user reports a problem, and the on-call engineer acknowledges it.
2. Triage. Confirm the impact. False alarms are closed and the alert is tuned.
3. Classify severity. High-severity incidents bring in an incident commander and a public status update.
4. Mitigate. Contain the problem first (roll back, fail over, disable a feature), then find the root cause.
5. Communicate. While the service is still degraded, post regular updates to stakeholders.
6. Learn. After resolution, run a blameless postmortem and track the action items.

How to make it in flow-chart.io

1. Start from the example. Edit the text in the generator box above so it names your own alerting tools, severity levels and roles, then press Generate. The free preview needs no sign-up.
2. Add the branches. Add the decision points that matter for you, for example security incident? or customer data affected?. Each decision becomes a diamond with labeled outcomes.
3. Assign owners. Save the diagram to the editor (free account) and rename steps to show who does what: on-call engineer, incident commander, communications lead.
4. Share or export. Share a read-only view link: people with the link can view the diagram but not edit it. Downloads as PNG, SVG or PDF are part of Flow Pro (see pricing).

Tips

• Define severity levels in writing before you need them.
• Mitigate before you investigate; restore service first.
• Separate the incident commander from the person fixing the problem.

Frequently asked questions

What are the phases of incident response?

Common frameworks such as NIST SP 800-61 describe preparation; detection and analysis; containment, eradication and recovery; and post-incident activity. This flowchart covers the operational path from detection to postmortem.

Who should be on an incident response flowchart?

The on-call responder, an incident commander for severe incidents, a communications owner, and whoever runs the postmortem.

Can I make a security-specific version?

Yes. Add branches for evidence preservation, legal review and notifications in the generator box, then generate an editable diagram.

Related