The roles, decisions, reporting deadlines and technical groundwork to have in place before the first alert, so the worst day is not also the most chaotic one.
In short
An incident response plan is a short, tested document that says who decides, who acts and who reports when a security incident happens. Prepare named roles and contact lists, severity levels, playbooks for likely scenarios, logs and backups you can trust, and the reporting deadlines that apply to you. Then rehearse it at least once a year.
Most organisations discover what their incident response actually looks like at two in the morning, with an encrypted file server and no idea who may approve taking it offline. This guide is written by Devies, a Gothenburg-based product and engineering consultancy, for CTOs, IT leaders and product owners who want that decision made in advance. It covers what the plan must contain, which Swedish and EU reporting deadlines apply as of October 2026, how to build the plan step by step, and how to keep it alive.
What is incident response, and what should the plan cover?
Incident response is the organised way an organisation detects, contains, investigates, recovers from and learns from a security incident, and the plan is the agreed description of how that happens.
Some definitions keep the scope clear:
- A security incident is an event that actually or potentially compromises the confidentiality, integrity or availability of systems or data.
- An incident response plan is the document that sets roles, decision rights, severity levels, communication routes and reporting duties for those events.
- A playbook is a short, scenario-specific checklist inside the plan, for example for ransomware, a leaked credential or a compromised customer account.
- Business continuity and disaster recovery plans are related but different: they keep the business running and restore systems, whatever the cause. The incident plan must point to them, not replace them.
In Swedish the field is usually called incident handling (incidenthantering). The main international reference is NIST SP 800-61 Revision 3, published in April 2025. It replaced the 2012 revision and now places incident work inside the broader risk management of the NIST Cybersecurity Framework 2.0, rather than treating it as a separate lifecycle. The practical lesson: preparation, detection and recovery are ordinary security management, not special procedures you invent during a crisis.
Which reporting deadlines apply to you?
Your plan must name every reporting duty that can apply to you, because the clocks start when you become aware of an incident, not when you have finished investigating it.
As of October 2026, three regimes matter most for Swedish companies:
Regime
Who it covers
What triggers a report
Deadlines
Swedish Cybersecurity Act (NIS2)
Who it covers
Essential and important entities
What triggers a report
Significant incident
Deadlines
Early warning within 24 hours, incident report within 72 hours, final report within one month
GDPR
Who it covers
Any organisation processing personal data
What triggers a report
Personal data breach that is not unlikely to pose a risk to people
Deadlines
Notify IMY within 72 hours of becoming aware
Cyber Resilience Act
Who it covers
Manufacturers of products with digital elements
What triggers a report
Actively exploited vulnerability or severe incident affecting product security
Deadlines
Early warning within 24 hours, notification within 72 hours, then a final report
The Swedish Cybersecurity Act (cybersäkerhetslagen) implements NIS2, Directive (EU) 2022/2555, whose Article 23 sets the three-step timeline. As of October 2026, significant incidents are reported to the National Cyber Security Centre (NCSC) from 1 July 2026, according to the Swedish Transport Agency's guidance. Personal data breaches go separately to the Swedish Authority for Privacy Protection, and IMY's guidance also requires you to document every breach, reported or not. For the full NIS2 picture, see NIS2 and the Swedish Cybersecurity Act: what to do.
One incident can trigger all three. A ransomware attack on a covered manufacturer that leaks customer data needs three reports to three recipients, on overlapping clocks. Your plan should contain a one-page reporting matrix that someone can follow under stress.
How do you build the plan, step by step?
Build the plan in a fixed order: ownership first, then decisions and contacts, then scenarios, then rehearsal.
- Name an owner. One person maintains the plan and runs exercises. In smaller companies without a security lead, a part-time arrangement, often sold as CISO as a service, can fill the role, but decision rights must stay with management.
- Define the incident team and decision rights. List the incident lead, technical lead, communications, legal or data protection, and the executive who can approve drastic actions such as shutting down a service. Name deputies for each.
- Set severity levels. Three or four levels with concrete criteria: affected customers, data types, downtime and regulatory impact. Severity decides who gets woken up and whether reporting deadlines start.
- Write the reporting matrix. For each regime: the trigger, the deadline, the recipient, the channel and who signs off.
- Build the contact list. Internal people, cloud and hosting providers, key suppliers, your insurer, external forensics support and the authorities. Keep a copy offline.
- Write three to five playbooks. Start with your most likely scenarios: ransomware, compromised administrator account, leaked secret in code, data exposed by misconfiguration, and a vulnerability in your own product.
- Agree internal and external communication. Who informs staff, customers and partners, using which pre-approved holding statements.
- Plan evidence handling. Decide how logs, disk images and timelines are preserved before systems are rebuilt.
- Approve and publish. Management approves the plan; everyone involved knows where it is and can open it without the systems that might be down.
What should you prepare technically before an incident?
The plan only works if the technical groundwork exists, because you cannot add logging, backups or emergency access after an attacker is already inside.
Check these before you need them:
- Logging: central collection of sign-in, administrative and application logs, retained long enough to investigate an intrusion that started weeks earlier, with synchronised clocks.
- Backups: at least one copy that the attacker cannot reach or delete, and a restore that has actually been tested within the last year.
- Emergency access: break-glass administrator accounts stored securely and monitored, in case your identity provider is the thing under attack.
- Out-of-band communication: a channel that does not depend on your own email or chat, such as a separate messaging group.
- Asset and data inventory: which systems hold which data and who owns them, so you can judge impact and reporting duties quickly.
- Product security contacts: for manufacturers, a way to receive vulnerability reports and an SBOM to see which products a new vulnerability affects.
How do you test and maintain the plan?
A plan that has never been exercised is a hypothesis, so test it with a tabletop exercise at least once a year and after every real incident.
A tabletop exercise is a guided discussion of a realistic scenario, usually two to three hours, where the incident team walks through what they would do while a facilitator adds new information. It exposes the gaps that reading never does: the deputy who has no access, the supplier contact who left, the report nobody knew how to submit. Record what failed, assign fixes, and update the plan.
Also update the plan after organisational changes, new critical suppliers, new regulations and every real incident. Short after-action reviews, held without blame within two weeks, are where most of the lasting improvement in cybersecurity (cybersäkerhet) practice comes from.
Keep reading
From our work
Consilium and Devies Cybersecurity+Consilium Safety Group and Devies Cybersecurity+: a partnership for future-proof cybersecurity in fire, flame and gas safety systems.Read the caseDevies
Want a second opinion?
Devies, a Gothenburg-based product and engineering consultancy, works on questions like this with Nordic product and IT teams. Tell us where you are and we will suggest a sensible first step.
Frequently asked questions
What should an incident response plan contain?
At minimum: the plan owner, the incident team with deputies and decision rights, severity levels with concrete criteria, a reporting matrix for NIS2, GDPR and the Cyber Resilience Act where relevant, a contact list kept offline, playbooks for the most likely scenarios, communication templates and rules for preserving evidence. Keep it short enough to use under stress, and store a copy that does not depend on the systems that may be down.
How quickly must we report a cyber incident in Sweden?
It depends on the regime. As of October 2026, entities covered by the Cybersecurity Act send an early warning for a significant incident within 24 hours, an incident report within 72 hours and a final report within one month. Personal data breaches go to IMY within 72 hours. Manufacturers under the Cyber Resilience Act report actively exploited vulnerabilities and severe incidents with a 24-hour early warning.
What is CISO as a service?
CISO as a service is a part-time or fractional arrangement where an external security leader takes on the responsibilities of a chief information security officer: security strategy, risk management, policies and incident readiness. It suits organisations that need senior security leadership but not a full-time hire. Decision rights and accountability for cybersecurity still sit with management, especially under NIS2, so the arrangement supports leadership rather than replacing it.
How often should we test the plan?
Run at least one tabletop exercise a year, and more often if your systems, suppliers or regulatory duties change quickly. Test the technical parts separately: restore a backup, use the break-glass account and check that logs reach the central store. Every real incident is also a test, so hold an after-action review within a couple of weeks and update the plan with what you learned.
Sources
- NIST SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management (April 2025)
- Directive (EU) 2022/2555 (NIS2), EUR-Lex
- Transportstyrelsen, Incidentrapportering enligt cybersäkerhetslagen
- IMY, Personuppgiftsincidenter
- MCF, MCFFS 2026:8, föreskrifter om incidentrapportering och informationsskyldighet
- Regulation (EU) 2024/2847 (Cyber Resilience Act), EUR-Lex
- Devies Cybersecurity+
- Devies CTO as a Service
