Reporting an incident under NIS2

NIS2 Article 23 puts a clock on you. If you are an essential or important entity and you detect a significant incident, you owe your national CSIRT an early warning within 24 hours, a fuller notification within 72 hours, and a final report within one month. Those deadlines run from detection, not from when you finished investigating, and they run whether or not anybody in your organisation is available.

This article explains what Qorionix does towards that obligation. The short version is that it holds a register, produces the evidence and generates a submission file, and it does not file anything, does not remind you, and — today — does not give you a way to put an incident into the register in the first place. All three of those are stated in detail below, because the gap between the platform has NIS2 incident reporting and the platform will meet your deadline for you is the entire subject.

The schedule you are working to

Every incident starts in the state draft. The transitions are strictly linear — draft to early warning, early warning to notification, notification to final — and there is no route back and no way to skip a step. Advancing to the wrong state cannot be undone through the product. Be deliberate with the button, because the state you set is the state a regulator will later be shown.

What the platform does supply today

The NIS2 report

GET /api/v1/organizations/{orgID}/compliance/nis2/report produces a structured document covering the last 30 days, fixed — the window is not a parameter. Reading it requires the compliance:frameworks permission with the read action.

• High-severity alerts. Every SIEM alert in the window at severity 8 or above, capped at 200 and newest first, with the numeric severity rendered as the word a regulator reads: high at 8, critical at 10.
• Incidents from the register, each carrying its own Article 23 deadlines, computed from that incident's detection timestamp.
• An autonomy policy snapshot. Which automated-response rules were in force, at what tier and with what confidence floor, plus every change made to that policy during the window and who made it. This is the section that answers what was the machine allowed to do while this was happening, and it is genuinely useful in a filing.
• A thresholds block, one row per Article 23(4) obligation, counting how many incidents met the deadline, met it late, are still within time or have passed it unmet.

How the deadlines are computed

Every deadline is measured from the incident's own detected_at, which the platform names on the artefact as the Article 23 became aware instant. That is a mapping rather than an identity — a detection you have not yet triaged is arguably not yet awareness — so it is stated rather than left for you to assume.

• Early warning, Art. 23(4)(a) — detected_at + 24 hours.
• Incident notification, Art. 23(4)(b) — detected_at + 72 hours.
• Final report, Art. 23(4)(d) — one month after the submission of the incident notification, not one month after detection. Before you record that notification, this deadline is reported as not_started with a null due_by, because inventing a date from detected_at would be a date with no basis in the Directive.

Each deadline reports one of five states: met, met_late, pending, breached or not_started. A late filing is recorded as met_late and never rounded up to met — a delay is a fact you have to account for, and a register that hides it is doing you no favours.

Two historical defects in this report are worth knowing about if you produced one earlier in the year, because both were silent and both made the report understate reality. The high-severity alert query named a table that has never existed, and later a second version compared a numeric severity column as though it were text; in both cases the section came back empty, and no high-severity alerts in the window is a positive claim in a regulatory document rather than an absence of data. The incident query named a bare incidents table that likewise never existed. Both are fixed, and collection failures are now surfaced rather than swallowed — see The evidence bundle.

The ENISA-format export

For an incident that is in the register, GET /api/v1/organizations/{orgID}/compliance/nis2/incidents/{id}/enisa returns a JSON document shaped after the ENISA notification template: the incident's title, severity, state, detection time, the three reporting timestamps, the affected services, the cross-border flag and your free-text description. Reading it requires compliance:breaches with the read action — a deliberately separate permission from the rest of compliance, because this document is the fullest description of a breach the platform produces.

The export is a starting document, not a submission. Most member states want their own web form or portal, and several want more than this file carries. Treat it as the structured record you copy from.

The surrounding evidence

The parts of a NIS2 filing that are hardest to reconstruct after the fact are the parts the platform is genuinely good at: what was detected and when, what was done about it, and who did it.

1. The alert and incident record. See How alerts are grouped into incidents for what is joined to what, and Searching your logs for reconstructing a timeline.
2. The audit chain, which records every privileged action with a hash linking it to the previous one. A regulator asking how do you know this record was not edited afterwards is asking about this. See Verifying the audit chain.
3. The evidence bundle, which packages the NIS2 report together with the GDPR, DORA and AI Act sections and an integrity hash over the whole thing. See The evidence bundle — including what it says when a section could not be collected, which matters more in a filing than in an internal review.

Nothing reminds you

There is no timer, no scheduled job, no notification and no escalation attached to the 24-hour or 72-hour deadline. Nothing turns amber at hour 20. The only place the deadlines appear at all is the open_items count in a report you have to go and generate.

That is worth saying plainly because it inverts the reasonable expectation. A platform that knows the deadline, knows when the incident was detected and has your notification preferences configured could obviously warn you, and it does not. Until it does, the reminder has to live in your process: when an incident is declared, somebody sets a calendar entry for detection time plus 20 hours, and somebody's name is against it.

What to actually do when you have an incident

1. 1

   Write down the detection time before you do anything else

   Every deadline in this article counts from it, and it is the single fact most often reconstructed wrongly a week later. If it came from an alert, the alert's triggered_at is your evidence and it is in the audit record.

2. 2

   Decide whether it is significant, and record the reasoning either way

   NIS2 turns on whether an incident is significant — severe operational disruption, financial loss, or material harm to others. That judgement is yours; nothing in the platform makes it. Write down why you decided as you did, because a decision not to notify is one you may have to defend, and we did not think it met the threshold is only a defence if it was written at the time.

3. 3

   Send the early warning within 24 hours

   To your national CSIRT, through whatever channel that authority publishes. This is a short message: is it suspected to be malicious, and could it have cross-border effect. You do not need the investigation finished.

4. 4

   Generate the report and build the 72-hour notification from it

   The 30-day report gives you the alert history and the autonomy-policy snapshot. Add your assessment and your indicators of compromise.

5. 5

   Produce an evidence bundle at the one-month mark

   It gives your final report an integrity hash and packages the surrounding compliance state with it. Check its completeness flag before you file — a bundle that says a section could not be collected must not be filed as a complete record.

6. 6

   Keep your own register until the platform has one you can write to

   A spreadsheet with detection time, significance decision, the three submission timestamps and who sent each is enough, and it is what an auditor will ask for.

Who can see any of this

If you get a 403 from one of these, compliance:breaches is the permission to ask your administrator for, and it is separate from the rest of compliance on purpose. An incident export names your worst day in detail; the person who compiles your evidence bundles does not automatically need it. See Who can see and do what.

One reassurance about the export specifically: it is keyed on both your organisation and the incident identifier, so naming your own organisation and somebody else's incident id returns not found rather than their filing. An incident belonging to another tenant is reported identically to one that does not exist, so the endpoint cannot be used to discover that another organisation has had a breach.

What to read next

1. NIS2: what your management is personally responsible for — the duties that sit with your board rather than with your IT.
2. The evidence bundle — what an auditor gets, and what it says when it is incomplete.
3. What an auditor will ask for — the requests to prepare for before they arrive.