07.01 What is Incident Response?

Why this matters

Something has gone wrong. A user clicked the link, the alert fired, the server is acting strangely, the customer's data is in the wrong place. Incident response is the structured discipline of the next several hours — what the team does, in what order, with what authority, to contain the damage, eradicate the cause, recover normal operations, and capture what was learned. A program with rehearsed incident response handles the bad day the same way it handles a normal day; a program without it improvises under pressure, which is where most incident responses go badly.

The trap is conflating incident response with incident management. They overlap but they're not the same. Incident response is the per-incident operational work (detect, contain, eradicate, recover, learn). Incident management is the program-level discipline of running the response capability — defining the playbooks, training the responders, tracking the incidents over time, reporting to leadership, integrating with risk and compliance. SimpleRisk's Incident Management Extra is named for the program-level discipline; the per-incident response is the work it supports.

The other reason this matters: incident response is the discipline the audit reads about, but it's the capability (the prepared playbooks, the trained responders, the rehearsed handoffs) that determines whether a response actually works. Documentation describing a response capability the team has never exercised is theater; the auditor can usually tell. The discipline is in running the playbooks, including in tabletop exercises, even when no real incident has occurred.

The fourth thing: an incident is operationally distinct from a vulnerability and from a risk. A vulnerability is a technical weakness that could be exploited (see What is Vulnerability Management?). A risk is the prospective scenario where a threat exploits a vulnerability against an asset (see What is a Risk Register). An incident is what's happening right now — the scenario has materialized, or is in the process of materializing, and the team needs to act. The same situation moves through all three states over time: a vulnerability gets identified, a risk gets recorded against it, the incident response runs when the risk materializes.

How frameworks describe this

Incident response is treated as a load-bearing capability across every major security framework, with NIST publishing the most prescriptive lifecycle.

• NIST Special Publication 800-61 r2 Computer Security Incident Handling Guide is the federal reference and the model SimpleRisk's Incident Management Extra is built around. The 800-61 lifecycle has four phases: 1. Preparation — establishing the response capability before an incident occurs (playbooks, training, communication channels, jump kits, escalation lists). 2. Detection & Analysis — identifying that an incident is occurring and understanding its scope, vector, and impact. 3. Containment, Eradication & Recovery — stopping the spread, removing the cause, restoring normal operations. NIST explicitly groups these three because they often happen iteratively and in overlapping order. 4. Post-Incident Activity — capturing lessons learned, refining the playbooks, updating the risk register, communicating to stakeholders.

The lifecycle is iterative, not strictly sequential — detection-and-analysis often continues while containment is in progress, and post-incident lessons feed back into preparation for the next incident.

• NIST Cybersecurity Framework (CSF) v2.0 addresses incident response across three of its six functions: Detect (identify the incident), Respond (contain, mitigate, communicate, analyze), and Recover (restore operations, lessons learned, communications). The CSF mapping isn't identical to 800-61's four phases but covers the same ground.
• NIST SP 800-53 IR family (Incident Response) contains the federal control set: IR-1 (Policy and Procedures), IR-2 (IR Training), IR-3 (IR Testing), IR-4 (Incident Handling), IR-5 (Incident Monitoring), IR-6 (Incident Reporting), IR-7 (IR Assistance), IR-8 (IR Plan), IR-9 (Information Spillage Response). Programs running 800-53 implement the IR discipline through this family.
• ISO/IEC 27001 Annex A A.5.24 (Information security incident management planning and preparation), A.5.25 (Assessment and decision on information security events), A.5.26 (Response to information security incidents), A.5.27 (Learning from information security incidents), and A.5.28 (Collection of evidence) cover incident response. The 2022 update made the requirements more explicit than the 2013 edition.
• PCI DSS v4.0 Requirement 12.10 mandates an incident response plan, annual testing, and specific provisions for cardholder data exposure. The PCI requirements are prescriptive on testing cadence and on the response timeline for cardholder-data incidents.

The takeaway across all five: incident response is required, the lifecycle is well-established (NIST 800-61's four phases are the de facto standard), and the audit will check both the plan and the evidence that the plan operates (test results, lessons-learned records, real-incident timelines).

How SimpleRisk implements this

SimpleRisk's incident-response capability lives entirely in the Incident Management Extra. Core SimpleRisk has no native incident recording — the /incidents/ URL paths in the application redirect to either the Extra (if active) or to /admin/incidentmanagement.php to activate it.

The Extra structures its workflow explicitly around NIST 800-61's four phases, surfaced as sidebar entries under Incident Management → Incidents:

• Preparation (/incidents/index.php?menu=preparation) — pre-incident readiness items the program tracks (playbook authoring, responder training, communication-channel setup). The page lets the program record what's been prepared and what's still outstanding.
• Identification (/incidents/index.php?menu=identification) — NIST's Detection & Analysis phase, branded "Identification" in the UI. This is where new incidents are recorded via the Submit An Incident form (covered in Recording an Incident).
• Response (/incidents/index.php?incident_id=X) — the per-incident detail view, with Containment, Eradication, and Recovery as tabs. Each tab walks the assigned playbook's actions; ticking off actions is gated by the Able to Select Incident Response Items permission. The full walk-through of the response workflow lives in The Incident Management Extra.
• Lessons Learned (/incidents/index.php?menu=lessonslearned) — NIST's Post-Incident Activity. Programs can attach lessons to specific incidents (and dismiss reviewed incidents from the queue) using the global lessons library.

Each incident moves through the workflow as a single record in incident_management_incidents with a status field that maps to the response phase: 1 = Response/New, 2 = Response/Containment, 3 = Response/Eradication, 4 = Response/Recovery, and 5–11 = Closed (with various closure reasons). The status is the operational signal for which phase the team is in.

Two other SimpleRisk-specific facts worth knowing:

• Bidirectional risk linkage: The incident_management_incident_to_risks table holds the link between incidents and risks. An incident can be created from a risk that materialized; a post-incident review can surface a new risk that's then added to the register. The relationship works both ways and is the bridge to the risk-management discipline (see From Incident to Risk and Back).
• Playbooks: Containment, eradication, and recovery actions are organized into named playbooks (incident_management_playbooks) with categorized actions. A playbook gets assigned to an incident at the start of the response phase; the response tabs then show the playbook's actions as a checklist the responders work through. Playbooks are reusable across incidents — typical examples are "Ransomware Incident Response," "Data Exposure Response," "Account Compromise Response."

The Extra doesn't currently ship a structured "incident-review-meeting" template (the Lessons Learned page is a list of attached lessons, not a formal review form), and it doesn't enforce SLA timers on the phases. Programs that need either layer that on through their own conventions or through external tooling.

Common pitfalls

A handful of patterns recur with incident response programs.

• Plan documented, never exercised. A 40-page incident response plan that nobody has run through in a tabletop exercise is documentation, not a capability. The audit will check whether the plan has been tested; the operational reality will only match the plan if the team has practiced it. PCI DSS 12.10.2 mandates annual testing for cardholder-data scope; for non-PCI programs, an annual tabletop is still a reasonable minimum cadence.

• Detection without analysis. The alert fires, the responder acknowledges, the alert is closed without confirming what triggered it or whether anything else is going on. Detection is the easy half; analysis is the half that produces the right next action. NIST's pairing of "Detection & Analysis" as a single phase exists for exactly this reason — detecting an event without analyzing it produces metric improvements (mean time to detect went down!) without producing better incident outcomes.

• Containment that becomes recovery without eradication. The system was misbehaving, the team rebooted it, the misbehavior went away, the incident was closed. Reboot solved the symptom; the cause is still there, waiting for the next trigger. The eradication phase exists because containment is necessary but not sufficient. Skipping it produces incident reports that close cleanly and incident patterns that recur for years.

• No post-incident review. The incident is closed, the team moves on, the lessons go uncaptured. The Lessons Learned phase exists because incident response is a learning discipline; without the review step, the program runs through the same incidents repeatedly without improving the playbooks. Block off review time as part of the close-out, even if the incident was small.

• Response in panic mode every time. A program that experiences every incident as a fire drill (people scrambling, decisions made on the spot, no record of what was done) produces incident outcomes that depend entirely on who happened to be on call. The discipline of running the playbook, even when the playbook is incomplete or imperfect, is what produces consistent outcomes. Improve the playbook between incidents; don't improvise during them.

• Conflating events with incidents. An "event" is something that happened on a system (a log entry, an alert, a user action); an "incident" is an event (or set of events) that's being responded to. SimpleRisk's incident_management_occurrence_type table distinguishes Event from Incident at the data-model level. Recording every alert as an incident produces an incident register where the genuinely-significant ones are buried in noise; recording only the ones that warrant response keeps the register meaningful.

• No linkage to the risk register. An incident with no risk-register link describes the response work without surfacing the underlying exposure. The post-incident review should ask: "did we know this risk existed? If yes, why didn't the controls hold? If no, what should be added to the register now?" Use the incident_management_incident_to_risks linkage to make those questions answerable; see From Incident to Risk and Back.

• Treating incidents as the security team's problem. Major incidents touch legal, communications, customer support, executive leadership — sometimes within the first hour. A program where incident response is run entirely by the security team, without preparation that includes the other functions, learns about the cross-functional coordination requirement during the first major incident. Build the playbook with all the affected functions; rehearse with all of them.

Related

• Recording an Incident
• The Incident Management Extra
• From Incident to Risk and Back
• What is Vulnerability Management?
• What is a Risk Register and Why Every Program Needs One
• The GRC Program Lifecycle