Security incident response process flowchart
A swimlane flowchart of the security incident response process, from detection and triage through containment, eradication, breach notification and review.
How it works
Rename the lanes to your actual roles
Replace the five lanes with the roles you really have: SOC or MSSP, service desk, security lead, platform team, DPO, external forensics or breach counsel. If a role does not exist, delete the lane rather than leaving it unstaffed.
Set your severity criteria
Open the "Classify severity and impact" box and replace the note with your own matrix: what makes an incident high severity, who is allowed to declare it, and what response time each level commits you to.
Fix the notification window and regulator
Edit the "Breach notifiable?" decision so it names the regimes that apply to you: UK or EU GDPR (72 hours to the supervisory authority), NIS2, HIPAA, sector rules, and any contractual customer notice periods, which are often shorter than the statutory ones.
Add the contact points people need at 3am
Put the incident channel, the on-call number, the incident commander rota and the evidence storage location into the box comments, so the diagram is usable during an incident and not only during a review.
Adjust the loops and add missing steps
Decide whether the "Systems verified clean?" branch back to isolation matches how you work, and add anything specific to your estate, such as engaging a retained forensics supplier, cyber insurance notification, or a customer communications approval step.
Circulate for approval and keep the version
Share the chart with the security lead, IT operations and legal for sign-off, then keep the approved version. An incident response plan is a controlled document, and the version you exercise should be the version you publish.
Frequently asked questions
What are the stages of the incident response process?
This chart uses five: detection and reporting, triage and classification, containment, eradication and recovery, and notification and review. That maps closely onto NIST SP 800-61r2, which uses detection and analysis; containment, eradication and recovery; and post-incident activity. NIST also has a preparation phase, but preparation is continuous work (tooling, rotas, exercises, retainers) rather than a step you carry out during an incident, so it is not drawn on the flow.
How is security incident response different from IT incident management?
An IT service incident is finished when service is restored. A security incident is not, because there is an adversary. Restoring too early can reinstate the attacker's access, and there are obligations an ITIL incident process does not carry: preserve evidence before rebuilding, determine what data was affected, and notify regulators and individuals where required. That is why this chart puts evidence preservation and imaging before eradication, and adds a notification branch after recovery.
Who should be the incident commander, and when is one appointed?
The incident commander should be whoever has the authority to make decisions (take a production system offline, engage external counsel, contact customers), not necessarily the most technical person available. They coordinate rather than investigate. In this chart the commander is assigned only when the "High severity incident?" decision returns yes; lower-severity incidents stay with the security team. In a long incident the role is handed over explicitly at each shift change.
When does the 72-hour breach notification clock start?
Under UK and EU GDPR the 72 hours runs from when the organisation becomes aware that a personal data breach has occurred, not from when the attack began or when the investigation concludes, and you can notify in phases if the full picture is not yet available. Notifying affected individuals is a separate test: it is required without undue delay where the breach is likely to result in a high risk to them. Other regimes run different clocks, so set the one that applies to you on the decision box.