NIS2 Incidents

NIS2 incident notifications, on the clock from the moment you know

Record a cybersecurity incident, assess whether it's significant, and the three statutory clocks start from the moment you became aware. Generate each stage's filing, track who submitted it and where, and keep an append-only audit trail of every step.

What NIS2 requires

Directive (EU) 2022/2555 requires essential and important entities to notify a significant cybersecurity incident to their national CSIRT on a strict cascade: an early warning within 24 hours, a fuller notification within 72 hours, and a final report within one month, plus an ongoing incident register of all significant incidents.

This is the notification-and-register discipline after detection, not detection itself. NIS2 doesn't ask you to find the incident faster; it asks you to tell the right authority, in the right form, inside deadlines measured in hours, and to be able to show afterwards that you did.

Most organisations learn of a qualifying incident the way they always have, through their own monitoring or a report from someone else, and the clock starts the moment they become aware, not once someone gets round to writing it up.

The deadlines

The early warning and notification clocks run from the moment you become aware of the incident, independently of each other, not in a chain where finishing one starts the next. Art. 23(4)(d) anchors the final report one month after the incident notification is submitted; Klaruna counts that same month from the earlier moment of awareness instead, so it's never late.

  • 24 hours
    Early warning

    To the relevant national CSIRT, counted in exact hours from the moment you became aware, never rounded to the end of a day.

  • 72 hours
    Notification

    A fuller notification with your assessment so far, counted from the same moment of awareness as the early warning, not from when it was filed.

  • 1 month
    Final report

    Root cause and remediation, one calendar month from the moment you became aware.

How it works

  1. Record the incident

    Title, description, incident type and a cross-border flag are enough to save. The moment of awareness defaults to now and can be corrected to an earlier time, which immediately recomputes every deadline.

  2. Assess significance

    Answer the Art. 23 criteria and see a live recommendation as you go. A named person records the actual decision, agreeing or overriding with a reason either way, and that decision is what puts the due dates on the incident — the clocks themselves have been running since the moment of awareness.

  3. Generate each stage's filing

    The responsible CSIRT is resolved from your entity class and sector and shown before you generate anything. Each stage produces a PDF and plain-text document you download, then mark as submitted with the method and reference you used.

  4. Nothing goes quiet

    An incident that's unfiled, or unassessed altogether, is chased with reminders that get louder the closer it gets to being overdue, and the clock keeps running whether you've looked at it or not.

  5. Keep the register

    Every incident, significant or not, stays in the register with its full chronology: every assessment, every generated document, every submission, timestamped and attributable. Export it as CSV, or a full case-file PDF for one incident at a time.

What's included

Fast intake, no blocked fields

A title and description are enough to save a draft in under a minute. Incident type, cross-border flag and everything else can be filled in later.

An awareness clock you can correct

The moment of awareness defaults to when you start the record and can be moved earlier, with a reason, when the true moment was before you sat down to write it up. All three deadlines recompute immediately, even if that means showing an incident as already overdue.

Significance triage, recommendation and decision kept apart

The Art. 23 questionnaire shows a live, labelled recommendation as you answer it. A named person records the decision separately, and overriding the recommendation carries the same weight as agreeing with it.

Authority routing shown before you file

The CSIRT responsible for your entity class and sector is resolved and displayed before you generate a document. Where more than one is plausible, you're shown the candidates and asked to choose, rather than having one picked silently.

Generated filings, human submission

Each stage produces a downloadable PDF and plain-text document carrying the template version it was generated from. You record who submitted it, by what channel, and the authority's own reference.

An incident register that reads as a register

Significant and non-significant incidents alike, each row showing its status, significance and awareness date, with a view of just your own and a full audit trail per incident: every assessment, generation, submission and note.

Escalation that doesn't wait for someone to check

Handlers are chased as each clock approaches its deadline, and again, more insistently, if it's missed. An incident that hasn't even been assessed yet gets its own reminders, so nothing sits silent while a real statutory clock might already be running.

Built for consultancies

A partner managing several client entities sees every client's open and overdue incidents in one queue, with a direct link to the one that needs attention first.

Data and security

Everything runs in EU data centres: the application, the database, file storage, backups and email delivery.

Incident content is encrypted at rest, and every assessment, generation, submission and note is written to an append-only audit trail.

The CSIRT templates are the directive's text, not a jurisdiction's own legal sign-off: a document generated where the underlying authority hasn't yet been confirmed by counsel carries a visible notice to that effect, so you know to check the format and channel yourself before relying on it.

Where it applies

The workflow and deadline tracking work in every EU country. Legal templates are available for Poland, with more countries to follow.

Questions

When do the clocks start?
From the moment your organisation becomes aware of the incident, not from when you get round to assessing it or filing anything. That's why the awareness time is editable: if you actually learned of the incident earlier than the record was created, correcting it recomputes all three deadlines from the true moment.
Does finishing the early warning start the 72-hour clock?
No. Each stage's deadline is calculated independently from the same moment of awareness, so the 72-hour notification is never delayed by a late early warning, and generating one stage doesn't require finishing another first.
What if we're not sure whether an incident is significant?
Record it anyway. The incident's real statutory clock may already be running even though nobody has assessed it yet, which is why it gets its own 24-hour assessment deadline, counted from awareness, until someone makes a decision. The questionnaire can also return 'inconclusive' rather than guess, and you still record an explicit decision either way.
Who decides significance, the software or us?
You do. The questionnaire shows a recommendation, always labelled as one. A named person records the actual decision, and overriding the recommendation is treated the same as agreeing with it, not as an error.
Does Klaruna submit the filing for us?
No. It generates the document for the stage and shows you the responsible CSIRT, its channel and where to send it. A human submits it and records how and when, because an automated submission that silently failed would be a missed statutory deadline presented as a completed one.
What about an incident that's assessed as not significant?
It stays in the register with no deadlines attached. Recording that it was assessed and found non-notifiable is itself part of the evidence that your process works.