NIS2 incident reporting – 24 hours, 72 hours and final report

By Mallbutiken · Facts verified September 30, 2026 · Approx. 9 minutes reading

For entities covered by the Cybersecurity Act, a significant incident must be reported in several stages. The main workflow consists of an initial notification as soon as possible and within 24 hours at the latest, an incident report within 72 hours at the latest, and a final report no later than one month after the incident report. For trusted service providers, a specific 24-hour deadline also applies to the incident report.

NIS2 reporting in Sweden – four potential steps

The Cybersecurity Act (2025:1506) entered into force on January 15, 2026. Reporting is part of the entity's obligations and must be integrated with incident management, governance, business continuity, and supplier management.

What needs to happen during the first 24 hours?

The initial notification must be submitted as soon as possible, but no later than 24 hours after the entity became aware of a significant incident. In practice, this means that the organization's internal escalation must be faster than that.

A functional process should therefore immediately secure at least: the time the incident was discovered, affected services and systems, preliminary operational impact, known indicators of attack or failure, which containment measures have been taken, and who is leading the continued management.

It is not realistic to have a complete root cause analysis in the first few hours. The process should instead be built to report verified facts, mark uncertainties, and supplement once more information is available.

Incident report within 72 hours

For entities other than trusted service providers, the incident report must be submitted as soon as possible and no later than 72 hours after becoming aware. For trusted service providers, the law specifies a 24-hour deadline for this step as well.

By the 72-hour mark, the organization should normally have clearer information regarding scope, impact, suspected cause, geographical or customer-related spread, and ongoing measures. The internal incident case must therefore contain version history so that it is possible to see what was known at each respective reporting occasion.

Final report no later than one month after the incident report

According to the law, the final report must be submitted as soon as possible and no later than one month after the incident report. If the incident is still ongoing at that time, a status report is submitted instead, and a final report is submitted no later than one month after the incident has been managed.

The final report should tie together the incident's timeline, impact, probable or established root cause, technical and organizational measures, and lessons learned. The internal post-analysis should also lead to concrete changes in risk registers, continuity plans, supplier requirements, and security controls where necessary.

Build an internal process that meets the clock

Incident reporting is not a task that can be left solely to IT. A significant incident may require coordination between IT/security, business management, legal, communications, data protection, supplier managers, and leadership.

A simple chain of responsibility could be: discovery → triage → legal/regulatory assessment → decision on reporting → external report → ongoing update → final report → lessons learned. For each step, there should be a named role, a substitute, and an out-of-office contact method.

Separate NIS2 from other reporting obligations

The same event may simultaneously involve a personal data breach under GDPR or contractual requirements toward customers. These processes have their own criteria and deadlines. The incident plan should therefore have a screening matrix rather than assuming that one report automatically satisfies all regulations.

When the incident starts at a supplier

An entity may have a reporting obligation even when the technical cause lies with an external supplier. Agreements must therefore provide the customer with sufficiently fast information to make their own assessment and meet their own deadlines.

Regulate contact point, initial notification time, what factual data the supplier must provide, update frequency, and access to relevant logs. Also, read the guide on NIS2 and security requirements in supplier contracts.

Checklist for NIS2 incident reporting

• Do staff know how to escalate a suspected incident?
• Is there a 24/7 contact for critical events?
• Are the criteria for a significant incident integrated into the triage process?
• Is it logged when the organization became aware?
• Is there a template for the 24-hour notification?
• Is there a template and designated responsibility for the 72-hour report?
• Can suppliers provide necessary information quickly?
• Are GDPR and other parallel reporting requirements screened?
• Is there a routine for partial reports and final reports?
• Are lessons learned fed back into risk and continuity work?

Do you need a documented NIS2 process?

Mallbutiken's NIS2 Template Package contains integrated document templates for risk management, incidents, continuity, and supplier security, among others. Delivered in Word and PDF. Price in store: 199 SEK.

See the NIS2 template package

Common questions

Is 24 hours the deadline for the entire incident report?

No. The law has a multi-step flow. The initial notification must occur within 24 hours at the latest, followed by an incident report according to the deadlines applicable to the entity.

What happens if the incident is ongoing after one month?

In that case, the law states that a status report must be submitted at the time when the final report would otherwise have been submitted, and that a final report is submitted no later than one month after the incident has been managed.

Can a supplier report for us?

Contracts can regulate practical assistance, but the entity needs to understand its own obligations and ensure that information actually arrives on time.