Incident response
Also known as: incident handling, incident management
The organised way a company spots, stops and cleans up after a security attack or accident, then gets back to normal.
Draft - this entry has not been reviewed yet.
Formal
A prepared cycle of phases - preparation, detection and analysis, containment, removal of the cause, recovery, and review afterwards - carried out by named people with agreed authority when a security incident occurs.
In plain English
Like a fire drill that turns into the real thing - everyone knows who calls for help, who closes the doors and who counts heads.
In practice
At three in the morning the SIEM at a municipality flags a strange login; the on-call technician locks the account, cuts the laptop off the network and calls the incident lead.
Why it matters
Minutes count during an attack, and a team that improvises loses time, evidence and money that a prepared team keeps.
How to put it into practice
The usual steps, in order. Adapt them to your organisation.
- Get management to approve an incident response policy that defines what counts as an incident, the severity levels and who may decide to isolate systems or shut services down.
- Name an incident lead, deputies and a core team from IT, security, legal, communications and management, and keep an offline contact list that includes your external IR retainer and the police.
- Prepare playbooks for the likeliest scenarios, such as ransomware, a compromised account and a data leak, and make sure logs from SIEM, EDR and identity systems are kept long enough to investigate.
- When an alert comes in, triage it against the severity scale, open an incident record and keep a timestamped log of every observation, decision and action from the first minute.
- Contain the attack by isolating affected hosts and accounts, and secure logs, memory and disk images before anything is wiped or reinstalled.
- Check reporting duties early and give one person the job - an NIS2 early warning within 24 hours of becoming aware of a significant incident, and a GDPR notification to Datatilsynet within 72 hours if personal data is hit.
- Remove every foothold the attacker left, restore from clean backups, reset credentials and monitor closely before declaring a return to normal operation.
- Hold a lessons-learned review within a few weeks, turn the findings into actions with owners and deadlines, and update the plan and playbooks.
- Test the plan at least once a year with a table-top exercise, and again after major changes in systems, suppliers or organisation.
Common pitfalls
- Keeping the plan only on the network drive or in email, so it disappears together with everything else when ransomware hits.
- Wiping and reinstalling infected machines before logs and evidence are secured, so the cause and scope can never be established.
- Resetting passwords or blocking the attacker before the full scope is known, which tips them off and leaves backdoors in place.
- Losing track of the reporting deadlines to authorities in the middle of the technical work.
Good guides
- NIST SP 800-61 Rev. 3 - Incident Response Recommendations and Considerations for Cybersecurity Risk Management - A CSF 2.0 Community Profile(opens in a new tab) · NIST
- Incident management(opens in a new tab) · NCSC UK
- Gå fra panik til handling - brug nødplan ved cyberangreb(opens in a new tab) · Styrelsen for Samfundssikkerhed (in Danish)
- Minimer skaden og stop angrebet(opens in a new tab) · Styrelsen for Samfundssikkerhed (in Danish)
Technical deep dive
The discipline dates from the Morris worm of November 1988, after which DARPA funded the CERT Coordination Center at Carnegie Mellon; FIRST, the global forum of response teams, followed in 1990. For two decades the dominant process model has been the NIST SP 800-61 lifecycle, whose Revision 2 (2012) describes four phases: preparation; detection and analysis; containment, eradication and recovery; and post-incident activity. Revision 3 (April 2025) retired that lifecycle and instead maps incident response onto the six Functions of the NIST Cybersecurity Framework 2.0 (Govern, Identify, Protect, Detect, Respond, Recover), treating preparation and improvement as continuous rather than as phases. The SANS six-step model (preparation, identification, containment, eradication, recovery, lessons learned) splits the same work differently. ISO/IEC 27035-1:2023 frames it as plan and prepare, detect and report, assess and decide, respond, and learn lessons.
NIST SP 800-61 Revision 3, finalised in April 2025, withdrew Revision 2 and re-expressed incident response through the six functions of the Cybersecurity Framework 2.0. Govern, Identify and Protect cover the preparation that makes response possible; Detect covers finding and analysing adverse events; Respond covers incident management, analysis, reporting and communication, and mitigation; and Recover covers restoration and recovery communication. The change reflects the view that incident response is an organisation-wide capability tied to risk management rather than a separate team's process, and that lessons learned should feed improvement continuously, not only at the end.
Technically, detection and analysis rely on correlated telemetry from SIEM, EDR, identity provider and network logs, triage against a severity scheme, and scoping by searching for indicators of compromise and attacker techniques across the estate. Evidence is collected in order of volatility, as described in RFC 3227 (memory, network state and running processes before disk), with hashes and a chain of custody if legal action is possible. Containment choices are trade-offs: isolating a host with EDR keeps it available for forensics, while pulling the power destroys memory; resetting a compromised account before understanding the attacker's persistence can alert them and trigger destructive action. Eradication must remove every foothold, including scheduled tasks, web shells, new accounts, OAuth grants and, after domain compromise, the krbtgt key, which is reset twice.
Incident response is distinct from its neighbours. Crisis management is the leadership layer that makes business decisions around the incident, business continuity keeps operations running meanwhile, and disaster recovery restores technology after large-scale loss. Incident reporting to authorities under NIS2, GDPR or DORA is one of the obligations handled within incident response. In practice many Danish organisations rely on an external incident response retainer, whose activation procedure, contact details and pre-agreed access must be part of the preparation.
What to learn first
Everything this builds on, foundations first.
- Threat
- →Incident response
Relationships
- Requires
- Threat
- Don't confuse with
- Crisis management
Sources & further reading
Standards & official texts
Course material
- Cyber Security Fast Track - Ordliste
Where this data comes from
This entry was drafted by an AI from the sources above and has not yet been checked by a person. Treat it as a starting point, and check anything important against the sources.
See the review queueSuggest a correction on GitHubThis term as JSON
Mentioned in
Check yourself
Loading…