From incident to regulatory report in 24 hours – without guessing

NIS2 gives you 24 hours for an early warning. See how an access incident is recorded automatically, escalated into a regulatory case and filed on time – with countdowns, PDFs and an unbroken chain of evidence.
6 min

It is 16:45 on a Friday. A door to a plant building is forced open. There is no matching key access in the log.

If you are covered by NIS2, you now have 24 hours to file an early warning. The clock started when you became aware of the incident — not on Monday morning when somebody finally notices.

This is where most organisations lose the deadline. Not because they do not want to report, but because the event sits in a log nobody is watching, and because nobody knows what the report should say.


The problem has three parts

Detection comes too late

The incident happened Friday. Someone sees it Tuesday. The deadline passed on Monday.

The facts cannot be reconstructed

Who was there? Which key? Was the door open for 4 minutes or 4 hours? Without data the report becomes conjecture.

The report starts from a blank page

Each stage needs its own fields. On a Friday evening there is no template and nobody who knows what the authority expects.


Step 1: the incident records itself

In SnapKey, incidents are raised automatically from what alarm sensors on the doors report, and refused attempts on the iLOQ locks – logged with key, lock and time – appear alongside them. Each gets a type and a severity:

Type What it means Typical severity
Forced open An alarm sensor saw the door open without a matching unlock Warning; critical if the sensor also reports tampering
Access denied Someone tried to open without a valid key –

The decisive part is the timestamp. It establishes a documented moment of detection from which the deadline can be measured — instead of "we think it was sometime over the weekend".

An incident moves through three states: open → acknowledged → closed. On closure, a reason and a note are stored, so the decision can still be read a year later.


Step 2: escalate to a regulatory case

Not every incident has to be reported. A single denied attempt is not a significant incident. A forced entry at a pumping station may well be.

When the assessment is that it must be notified, a regulatory case is created from the incident. The first choice is which regime applies:

  • NIS2
  • CER
  • NIS2 + CER – for organisations covered by both

That choice determines which stages and deadlines the case gets. The incident stays linked to the case, so the chain of evidence from raw event to filed report is unbroken.


Step 3: the clock becomes visible

The case has three stages, each with its own deadline:

Incident detected  ──► the clock starts
   │
   ├─ Early warning (24 hours)
   │     Summary · severity assessment · suspected unlawful or
   │     malicious act · possible cross-border impact
   │
   ├─ Notification (72 hours)
   │     Updated summary · impact assessment
   │     · indicators of compromise
   │
   └─ Final report (1 month)
         Detailed description · threat type · root cause
         · mitigation applied and ongoing

Each stage shows the next deadline and how long remains. An overdue stage is flagged, and a banner appears across the system when a stage is overdue or falls due within eight hours.

You can also nominate compliance contacts — up to ten email addresses that receive deadline reminders. That is what stops the Friday incident becoming Monday's unpleasant surprise.


Step 4: generate and file

For each stage you can:

✅ Save a draft as you go, so work is not lost between shifts
✅ Generate a PDF collecting that stage's fields
✅ Mark it submitted with an optional authority reference once filed

The system does not file on your behalf. That would be promising more than any vendor can keep. What it does is make sure you know what to send, when, and that you can afterwards prove it was done.

When a case is closed, it is final — no stage can be edited or submitted afterwards. That is deliberate: compliance documentation that can be changed retroactively is not worth much.


Why this matters for supervision

When supervision asks about incident handling, it is rarely the individual incident they want to see. It is the pattern:

  • How long typically passes from incident to acknowledgement?
  • Are critical incidents handled faster than warnings?
  • Are there incidents that have sat open for months?
  • Is there a record of why something was not reported?

The incidents and sign-off report type captures exactly that: incidents and access sign-offs with response times, for a chosen period. It is the answer to the question before it is asked.


FAQ

When does the 24-hour deadline start?

When you become aware of the incident. This is why automatic recording matters – it establishes a documented moment of detection rather than an estimate.

Does every incident have to be reported?

No. Only significant incidents under NIS2, or incidents that significantly disrupt an essential service under CER. The assessment is yours – but both the assessment and the basis for it should be documented.

What if we are covered by both NIS2 and CER?

Choose the "NIS2 + CER" framework on the case. The two regimes have different stages – NIS2 has 24 hours, 72 hours and one month, while CER has an initial notification within 24 hours and a detailed report within one month.

Does SnapKey file the report with the authority?

No. SnapKey assembles the content, tracks the deadlines and generates the PDF. You file it yourself and then mark the stage as submitted with an authority reference.

Can a closed case be reopened?

No. Closure is final and no stage can be edited or submitted afterwards. This is a deliberate constraint so the documentation holds value as evidence.


Contact us

Want the 24-hour deadline under control before it becomes relevant? Contact SnapKey.