Cybersecurity incident response process flowchart (SOC)
Swimlane flowchart of the technical cybersecurity incident response lifecycle a SOC or CSIRT runs, from alert triage to eradication, recovery and rule tuning.
How it works
Rename the lanes to your real structure
Replace Detection / SOC, Incident responder, Incident commander, IT operations and Management with what you actually have: an outsourced MSSP, tier 1 and tier 2 split into separate lanes, a platform or cloud team instead of IT operations, a retained forensics supplier. Delete a lane rather than leaving it unstaffed, and merge the commander into the responder lane if one person genuinely does both.
Put your severity matrix on the declaration step
Open 'Declare incident and set severity' and replace the note with your own criteria: what makes an incident critical, who is allowed to declare one, and what each level commits you to in response time, staffing and out-of-hours callout. Severity is what drives every downstream decision on this chart, so it is worth being specific.
Set the containment authorisation rule
The 'Containment will disrupt services?' branch only works if someone can answer it at three in the morning. Write down which systems may be isolated on the responder's own authority, which need a business decision, who holds that decision, and what happens if they cannot be reached within an agreed time.
Fix the evidence rules before containment
Record your collection order on 'Preserve forensic evidence and images': memory and live network state before disk, disk before archived logs, following the order-of-volatility approach set out in RFC 3227. Note that hosts are isolated at the network layer rather than powered off, and say where images are stored and who signs for them.
Define what 'threat fully removed' means
Write the exit criteria next to the 'Threat fully removed?' decision: the observation window with no attacker activity, every indicator swept across the estate, every compromised credential rotated, the exploited vulnerability patched. Decide too whether the failure branch returns to scoping, as it does here, or to containment.
Connect it to the processes either side and version it
Add explicit links to your breach notification path, to problem or change management for the permanent fixes, and to cyber insurance or supplier notification if those apply. Then circulate the chart to the security lead, IT operations and management for sign-off and keep the approved version, because the plan you exercise should be the plan you publish.
Frequently asked questions
What are the stages of a cybersecurity incident response process?
This chart uses six columns: detection and triage, declaration, scoping and containment, eradication, recovery, and lessons learned. That maps onto the SANS six-step model of preparation, identification, containment, eradication, recovery and lessons learned, and onto NIST SP 800-61 Revision 2, which groups the work as detection and analysis; containment, eradication and recovery; and post-incident activity. Revision 3 reorganises the guidance around the Cybersecurity Framework 2.0 functions rather than a fixed list of phases. Preparation is not drawn as a step because it is continuous work - detection engineering, rotas, retainers, exercises - carried out before any alert, not during one.
How is this different from IT incident management and from breach notification?
IT incident management restores a disrupted service and closes when the user is working again. A security incident has an adversary in it, so restoring service is not the finish line: it is the point of maximum risk if the threat is still resident, which is why this chart puts a verification decision before recovery. Breach notification is the other neighbour. Deciding whether personal data was affected, whether a supervisory authority or a customer must be told, and within what statutory window, is legal and communications work on a legal clock, and it runs in parallel with the technical response rather than inside it.
Why does evidence preservation come before eradication?
Because the most common containment actions destroy the evidence you will need. Powering off a host loses memory-resident malware, live network connections, decrypted material and injected processes. Rebuilding a server before the scope is understood removes the artefacts that show how the attacker got in and what they reached. The order-of-volatility principle described in RFC 3227 is the practical rule: capture memory and live state first, then disk, then archived logs. In this chart the evidence step sits after isolation and before any eradication work, and hosts are isolated at the network layer so they stay running.
How do you decide the threat is fully removed?
With criteria written before the incident, not judged in the moment. Typically: no attacker activity observed across the estate for an agreed observation window; every indicator from the investigation swept across all hosts, not only the ones that alerted; every credential that could have been captured rotated, including service and machine accounts; and the vulnerability or misconfiguration that allowed initial access closed. When the answer is no it usually means the scope was wrong rather than the clean-up was sloppy, which is why the failure branch here returns to 'Identify affected assets and accounts' rather than to isolation.
Who authorises containment that takes a production service offline?
Somebody with the authority to accept the business impact, which is rarely the responder who spotted the problem. This chart routes that case through the Management lane, but the point is not the lane name: it is that the decision, the named role and the fallback if they are unreachable are agreed in advance. Many teams pre-authorise isolation for a defined list of systems and severities so the common cases never wait for a call, and reserve the escalation for revenue-bearing or safety-related services. Without that, the argument happens while the attacker is still working.