diagram.mmd — flowchart
Security Incident Response flowchart diagram

Security incident response is the structured process an organization follows when a security breach, intrusion, or significant vulnerability is detected — from initial identification through containment, eradication, recovery, and post-incident review.

A well-defined incident response process minimizes the time an attacker spends in your environment (dwell time), limits the scope of damage, preserves evidence for forensic analysis, and drives continuous improvement through lessons learned. The NIST SP 800-61 framework defines four phases: Preparation, Detection and Analysis, Containment/Eradication/Recovery, and Post-Incident Activity.

Detection and triage is the starting point. An alert fires from the threat detection pipeline, a user reports suspicious activity, or a security researcher submits a vulnerability report. The first responder triages the alert — is it a true positive or a false positive? What is the severity and scope? Classification determines the response urgency and the required personnel.

Containment stops the bleeding. Short-term containment isolates affected systems immediately — block the attacker's IP, revoke the compromised credentials, disable the affected service, or take a network segment offline. Long-term containment involves patching the root cause vulnerability or applying a compensating control. Preserving forensic evidence (memory dumps, log snapshots, disk images) happens concurrently with containment, before any remediation steps might overwrite evidence.

Eradication removes the threat — deleting malware, closing the attack vector, rotating all potentially compromised secrets. Recovery restores systems to normal operation from known-good backups, validates integrity, and monitors closely for recurrence.

Post-incident review documents what happened, what the timeline was, what worked in the response, what failed, and what changes are needed. The output drives concrete improvements to detection rules, hardening, and runbooks. See Threat Detection Pipeline for how incidents are detected and Security Audit Logging for the evidence trail that supports investigation.

Free online editor
Edit this diagram in Graphlet
Fork, modify, and export to SVG or PNG. No sign-up required.
Open in Graphlet →

Frequently asked questions

Security incident response is the structured process an organization follows after detecting a security breach or significant vulnerability — from initial identification and triage through containment, eradication, recovery, and post-incident review. A defined process minimizes dwell time, limits damage scope, and preserves forensic evidence.
NIST SP 800-61 defines four phases: Preparation (policies, tools, and training in place before incidents occur), Detection and Analysis (identifying and triaging the event), Containment, Eradication, and Recovery (stopping the attack, removing the threat, and restoring services), and Post-Incident Activity (review and improvement).
Containment stops the immediate spread or damage — isolating a compromised host, revoking credentials, or blocking an attacker's IP. Eradication removes the root cause — deleting malware, patching the exploited vulnerability, or rotating all affected secrets. Containment happens first to limit harm; eradication follows once the scope is understood.
Evidence collection should begin concurrently with short-term containment, before any remediation steps are taken. Patching, reimaging, or restarting systems can overwrite memory dumps, process lists, and log entries that are essential for understanding how the attacker gained access and what they did.
Failing to preserve forensic evidence before remediating, failing to rotate all secrets exposed during the incident, not communicating breach status to affected parties within required regulatory windows, and skipping the post-incident review are the most damaging mistakes. Treating each incident as isolated rather than updating detection rules and runbooks is a systemic failure.
mermaid
flowchart TD A[Alert triggered or\nincident reported] --> B[Triage: Validate alert\nTrue positive or false positive?] B --> C{Confirmed incident?} C -- No, false positive --> D[Document and close\nTune detection rule] C -- Yes --> E[Classify severity\nCritical, High, Medium, Low] E --> F[Assemble incident response team\nNotify stakeholders] F --> G[Containment: Short-term\nBlock attacker IP, revoke credentials,\nisolate affected systems] G --> H[Preserve forensic evidence\nLog snapshots, memory dumps,\nnetwork captures] H --> I[Investigation: Determine scope\nWhat systems and data were accessed?] I --> J[Identify root cause\nHow did attacker gain entry?] J --> K[Eradication\nRemove malware, close attack vector,\nrotate all compromised secrets] K --> L[Recovery\nRestore from clean backups,\nvalidate system integrity] L --> M[Monitor for recurrence\nEnhanced logging and alerting] M --> N[Post-Incident Review\nTimeline, impact, and lessons learned] N --> O[Update runbooks\nImprove detection rules\nHarden affected systems] N --> P[Regulatory notification\nif required by GDPR, HIPAA, etc.]
Copied to clipboard