Incident response is the set of activities that begin when something has gone wrong and end when the organization is back to a state it understands. It is the part of a security program that is dormant until it is the only thing that matters, which is exactly why it has to be built when nothing is happening.
This article walks the stages, identifies the decisions that must be settled beforehand, and is explicit about the two stages organizations most often fail: eradication and improvement.
There is no single correct model
Published incident response models differ in how they carve up the same work, and the current NIST guidance is deliberate about not insisting: organizations can use an incident response life cycle framework or model that best suits them to develop practices that reduce risk to acceptable levels.
What matters is that a model exists, that people have practiced it, and that authority is settled. The stages used here are prepare, detect, analyze, contain, eradicate, recover and improve.
Prepare: almost all of the value
Preparation determines how the rest goes. It covers the plan itself, the contact list, the authorities, the tooling access, the evidence sources, and the rehearsal.
The contact list is more than a phone directory. It includes the executive who can authorize disruptive action out of hours, legal counsel, the insurer and the notification contact under any applicable breach requirement, the relevant regulators, key suppliers, and any retained response firm. It has to exist somewhere reachable when the corporate systems are not, which is a detail organizations discover during their first serious incident.
The authorities matter most. Who may disconnect a production system. Who may disable a senior executive's account. Who may block a supplier's connection. Who decides to pay, or not to pay. Deciding these in advance converts the first hour from a negotiation into an action.
Rehearsal is what turns a document into a capability. A tabletop exercise costs a morning and reliably surfaces the gaps: the person on the call list who left, the runbook that assumes access to a system that would be down, the assumption that somebody else was watching.
Detect and analyze
Detection is covered in security monitoring and incident detection. What response adds is the judgment that turns an alert into a declared incident, which is a decision with consequences and therefore needs a named decision maker and a threshold.
Analysis establishes scope: which systems, which accounts, what data, how long. The instinct to act immediately is strong and frequently wrong. Containing the one machine you have found, while the actual foothold is elsewhere, tells the intruder they have been seen and buys very little.
Analysis depends entirely on evidence that was being collected before the incident. An organization that cannot reconstruct which account was used, or when access began, is not short of skill. It is short of logs.
Contain: buying time without destroying evidence
Containment limits the damage while the rest is worked out. The tension is that the fastest containment actions frequently destroy the evidence needed to understand scope.
Powering off a compromised machine loses memory and often the clearest indicators. Reimaging before capture removes the ability to say what happened. Rotating credentials before mapping the intrusion tells the intruder they are detected. None of these is always wrong, and each should be a decision rather than a reflex.
Good containment is usually staged: isolate at the network rather than the host where possible, preserve what can be preserved, and accept a short period of controlled exposure where the alternative is blindness.
Eradicate: the stage most often declared complete too early
Eradication removes the intruder's access. It is harder than it sounds because the visible access is rarely the only one.
Persistence is the issue. An intruder with time will have created accounts, added credentials to existing accounts, registered scheduled tasks or services, added authentication tokens, altered a trusted configuration, or left a web shell in a location nobody inspects. Removing the malware that triggered the alert addresses the symptom.
The practical test for eradication is not that the alert stopped. It is that the scope established during analysis has been fully remediated, that credentials across that scope have been rotated, and that the initial access route is closed. An organization that reimages a machine without closing the vulnerability that was used has scheduled its next incident.
Recover: returning to service, carefully
Recovery restores normal operation. The sequencing question is which systems return first, and it should follow business priority established in advance rather than technical convenience established on the day.
Two specific hazards. Restoring from a backup taken after the intrusion began reinstates the intruder, which is why the analysis timeline matters to the recovery decision. And returning a system to the same configuration that was exploited, because that is what the backup contains, repeats the original exposure.
The mechanics of restoration, and the difference between having backups and having demonstrated recovery, are covered in backup, recovery and cyber resilience.
Recovery also includes the non technical work: notifications where they are required, communication to staff and customers, and the record of decisions taken. That record is worth keeping contemporaneously, because it will be requested later and memory will have reorganized it.
Improve: the stage that pays for the program
The post incident review is the cheapest security improvement available and the most frequently skipped, because by the time it is due everyone is exhausted and the pressure has lifted.
A useful review asks four questions. How did the intruder get in, and is that route closed everywhere rather than on the affected system. How long were they present before detection, and what would have shortened that. What slowed the response, and was it a missing decision, a missing access, or a missing log. And what in the plan turned out to be wrong.
The output is a small number of changes with owners and dates, fed back into the cycle described in the managed cybersecurity lifecycle. A review that produces a narrative and no changes has documented an incident rather than learned from one.
Blame is the thing that destroys this stage. A review that identifies a person rather than a condition teaches the organization to report incidents later next time, which is the opposite of the intended effect.
Ransomware changes the sequence
Ransomware deserves separate treatment because it compresses the stages and introduces decisions that are not technical.
Encryption is usually the last act rather than the first. By the time files are locked, the intruder has typically been present for some time, has established persistence, and has frequently taken a copy of data before encrypting it. That changes the response: restoring service does not end the incident, and it does not address a disclosure that may already have occurred.
It also raises questions that belong to the executive rather than the responder. Whether to pay is a business, legal and insurance decision with sanctions implications in some jurisdictions, and it should never be encountered for the first time during the event. Whether to notify, and whom, follows the data involved rather than the technical severity.
Practically, the preparation that helps most is the one covered in backup, recovery and cyber resilience: backups that an intruder with domain privileges cannot reach or delete, and a restore that has been timed rather than assumed. An organization that can restore quickly has a different conversation from one that cannot.
What the plan should physically be
A plan nobody can find during an incident is not a plan. The practical form is short, printed or stored somewhere independent of the corporate environment, and structured as a set of first actions rather than a policy document.
It should contain the declaration threshold and who decides, the contact list with out of hours numbers, the authorities, the first five actions for the most likely scenarios, the evidence preservation instruction, and the notification obligations with their clocks. Anything longer will not be read at 2am.
The documentation practice that keeps it current is covered in cybersecurity policies and documentation.
Where a service helps, and where it does not
A provider can supply detection, analysis, containment execution and the discipline of a rehearsed process. It cannot supply the organizational decisions: what may be disrupted, what must be notified, what risk is acceptable. Those stay with the organization, and a service that claims otherwise is describing something it cannot deliver.
LABUSA provides incident support within the scope agreed in the service agreement as part of LABUSA's managed cybersecurity offering. Incident scope is defined explicitly in that agreement rather than implied here, because response commitments are precisely the thing that should not be assumed.
Sources
- NIST, Incident Response Recommendations and Considerations for Cybersecurity Risk Management, SP 800-61 Rev. 3.
- NIST, The NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29, February 2024.
- NIST, Contingency Planning Guide for Federal Information Systems, SP 800-34 Rev. 1.