Incident Response Defined in Plain Terms
Incident response is the organised process a security team uses to detect a cyberattack, limit the damage, remove the attacker and restore normal operations, then learn from what happened. It replaces a chaotic emergency with a set of planned steps and clear roles so decisions are made in minutes rather than argued over for hours.
It matters now because incidents are no longer rare events. Swedish organisations have been hit through their own suppliers in waves from the Coop checkout outage in 2021 to the Tietoevry disruption in 2024 and the Miljödata breach that reached around 200 municipalities in 2025. When the alert comes the question is not whether you will respond but how well.
The Incident Response Lifecycle
Most incident response work follows a lifecycle, a repeatable set of stages a team moves through during and after an incident. Two models dominate. The long-standing reference is NIST Special Publication 800-61 which for years set out four phases.
- Preparation: Build the plan, the team and the tooling before anything happens.
- Detection and Analysis: Spot the incident, confirm it is real and work out its scope.
- Containment, Eradication and Recovery: Stop the spread, remove the attacker and restore clean systems.
- Post-Incident Activity: Review what happened and feed the lessons back into preparation.
In April 2025 NIST published Revision 3 and withdrew the older version. Revision 3 drops the fixed four-phase diagram and instead maps incident response onto the six functions of the Cybersecurity Framework 2.0 which are Govern, Identify, Protect, Detect, Respond and Recover (NIST, 2025). The practical message is that response belongs inside how you manage risk every day rather than sitting apart as an occasional fire drill.
The other common model comes from SANS and names six steps often remembered by the shorthand PICERL. They are preparation, identification, containment, eradication, recovery and lessons learned. The labels differ from NIST but the shape is the same. Prepare first, find the incident, stop it, clean up, get back to normal and learn.
CSIRT, DFIR and the Incident Response Team
Someone has to run the response. In most organisations that is a Computer Security Incident Response Team or CSIRT, the standing group that takes charge the moment an incident is declared.
You will also see the term CERT or Computer Emergency Response Team. CERT is a registered trademark of Carnegie Mellon University which ran the first such team in 1988 after the Morris worm so most organisations use CSIRT for their own group.
DFIR stands for Digital Forensics and Incident Response and it pairs two jobs that belong together. Forensics works out how the attacker got in, what they reached and what they took. Incident response uses that picture to contain the threat and recover. Skip the forensic half and you can clean a machine while missing the back door the attacker left behind.
A working incident response team reaches well beyond the technical staff. It usually includes:
- Incident manager: Owns the decisions and keeps the response moving.
- Security analysts and DFIR specialists: Investigate, analyse and contain.
- IT and system owners: Can isolate systems and rebuild them.
- Legal and compliance: Handle the reporting duties and liability.
- Communications: Brief staff, customers and the press.
- Management sponsor: Authorises hard calls such as taking production offline.
A security operations centre or SOC, is not the same thing. The SOC watches around the clock and raises the alarm. The CSIRT is what the alarm calls into action and the two often share people. At national level Sweden runs CERT-SE which helped coordinate the response to the Miljödata attack and supports organisations through serious incidents.
What Slow Incident Response Costs
The cost of an incident is mostly the cost of time. IBM’s 2025 Cost of a Data Breach Report puts the global average breach at 4.44 million dollars, the first fall in five years which it credits to faster detection and containment. The average breach still runs 241 days from first compromise to containment, 181 days to find it and 60 to shut it down (IBM, 2025).
Preparation is what moves that number. Organisations with a tested incident response plan saved an average of 2.66 million dollars per breach, the single largest cost reducer in the report (IBM, 2025). A plan you have rehearsed is not a compliance nicety. It is the cheapest security control you can buy.
The damage shows up in several ways:
- Downtime: Operations stop while systems are offline as Maersk found when it ran by hand for ten days.
- Recovery and rebuild: Reinstalling systems, restoring data and paying responders.
- Regulatory exposure: Fines and missed reporting deadlines under NIS2 and GDPR.
- Lost trust: Customers and partners who leave once a breach becomes public.
- Extortion: A ransom demand which most victims now refuse with 63 percent saying no in 2025 (IBM).
Real-World Incident Response Cases
Three incidents show what good and bad response look like in practice.
Norsk Hydro, 2019
On 19 March 2019 the Norwegian aluminium producer Norsk Hydro was hit by LockerGoga ransomware that encrypted around 22,000 computers across 170 sites in 40 countries. Production lines stopped and many plants switched to manual operation.
Hydro refused to pay. It rebuilt encrypted machines from backups kept factories running by hand and published daily updates so customers, staff and the market knew exactly what was happening. The company put the total cost near 800 million Norwegian kroner, roughly 75 million dollars with insurance covering only a fraction (Norsk Hydro, 2019).
What saved Hydro was preparation that existed before the attack. Backups it could trust and a workforce that could run the plants without computers meant it had real options. Transparency did the rest, turning a crisis into a case study other boards still learn from.
Maersk and NotPetya, 2017
On 27 June 2017 the NotPetya wiper tore through the shipping giant Maersk. Spread through a compromised update to Ukrainian accounting software, it destroyed the company’s domain controllers and locked tens of thousands of machines within hours.
Maersk reinstalled 4,000 servers, 45,000 PCs and 2,500 applications in ten days and ran about 80 percent of its shipping volume by hand in the meantime. The chairman later estimated losses of 250 to 300 million dollars (Maersk, 2018).
The recovery worked largely by luck. One domain controller in Ghana had been offline during the attack and held the only intact copy of the directory. A flat network and backups that were not isolated by design meant survival hinged on a single surviving machine. Network segmentation and offline backups remove that gamble.
Miljödata, 2025
The most recent lesson is Swedish. In August 2025 a ransomware group hit Miljödata, an HR software supplier used by roughly 80 percent of Sweden’s municipalities. The attack disrupted services across around 200 of the country’s 290 municipalities and reached universities and private firms including SAS and Volvo (SecurityAffairs, 2025).
Miljödata detected the intrusion on 23 August and brought in external experts, while CERT-SE coordinated support for affected organisations. Sensitive records on sick leave and work injuries were later published on a leak site.
For every municipality involved the incident was not their own breach but a supplier’s, and the reporting clock still started. The control here is harder than a firewall. It means knowing your critical suppliers having a plan for when one of them is breached and being ready to notify regulators within days.
Incident Response and Compliance
In Sweden incident response is now written into law. Several regimes set reporting deadlines you have to plan for in advance and more than one can apply to the same incident.
NIS2 and Cybersäkerhetslagen. Sweden’s NIS2 law, Cybersäkerhetslagen (SFS 2025:1506), took effect on 15 January 2026. It requires covered entities to handle and report significant incidents and it sets a strict cascade to MCF (formerly MSB) and the relevant sector authority. Covered entities must send an early warning within 24 hours, a full notification within 72 hours and a final report within one month.
Article 20 makes the board responsible and supervisors can hold directors personally accountable. Fines reach 10 million euros or 2 percent of global turnover for essential entities. Our NIS2 compliance guide covers the full requirements.
GDPR. When an incident exposes personal data, GDPR Article 33 adds its own duty. You must notify the Swedish data protection authority, IMY, within 72 hours of becoming aware. The NIS2 and GDPR clocks run at the same time and report to different authorities so your plan has to track both. Our GDPR compliance guide has the detail.
DORA. Financial entities face a third regime. DORA Article 17 requires a formal process for managing ICT incidents with reporting supervised by Finansinspektionen. If you are in scope for DORA you are almost certainly in scope for NIS2 as well. Our DORA compliance guide explains how they fit together.
ISO 27001. The standard’s Annex A controls expect a documented incident management process which is a practical way to evidence the duties above. See our ISO 27001 guide for how the control set maps to your programme.
What an Incident Response Plan Contains
An incident response plan is the document that tells your team exactly what to do when an incident is declared. A good plan is written to be used under pressure so it is short, specific and kept somewhere the team can reach it when systems are down. At a minimum it should cover:
- Roles and contacts: Who is on the team, who decides and how to reach them out of hours.
- Severity levels: Clear criteria for what counts as an incident and how serious it is.
- Playbooks: Step-by-step actions for the incidents you are most likely to face, such as ransomware, business email compromise and a breached supplier.
- Containment and recovery steps: How to isolate systems, preserve evidence and restore from backups.
- Reporting triggers: Who notifies MCF, IMY or Finansinspektionen and the 24, 72 and 30-day deadlines.
- Communications templates: Pre-written messages for staff, customers and regulators.
- Evidence handling: How to capture logs and system images so forensics and any legal case hold up.
The plan is only half the job. Decide in advance who you call for deep forensic work, whether that is an in-house DFIR team or an incident response retainer so you are not negotiating a contract while the attacker is still inside your network.
How to Build a Response Capability
A plan on a shelf does not stop an attacker. Response capability is a plan that has been resourced, practised and connected to real detection. It rests on people, process and technology and it is built through a handful of concrete habits.
- Rehearse the plan: Run tabletop exercises at least twice a year so the team has made the hard calls before a real incident.
- Make detection fast: Collect and monitor logs centrally so you see an intrusion in hours, not months.
- Keep backups you can trust: Store them offline or immutably and test a full restore so you know it works.
- Segment the network: Limit how far an attacker can spread from a single foothold.
- Know your suppliers: List your critical third parties and plan for the day one of them is breached.
- Pre-agree your responders: Put a forensic retainer and legal contacts in place now.
- Brief the board: Make sure leadership knows its NIS2 duties before an incident, not during one.
Few organisations can watch their own systems around the clock. This is where a managed detection and response service earns its place, giving you continuous monitoring and a team that can contain a threat at 02:00. Whether you build the capability in-house or buy it, the rule holds. The work that stops an incident from becoming a disaster is the work you do before the alert fires.
