The 24-Hour Clock Starts Earlier Than You Think

---

The short answer

Both CRA Article 14 and NIS2 Article 23 require an early warning within 24 hours of becoming aware. Neither says "within 24 hours of confirming".

That single word is the difference between a report that is on time and one that is late — and most incident runbooks are written as though it said "confirming".

awareness    the moment you have reasonable grounds to believe
confirmation the moment you have established the facts

The obligation attaches to the first. Most processes are built around the second.

---

Why teams get this wrong

The instinct is entirely reasonable and entirely wrong: *do not report until you know what happened.*

Under a regime built for early warning, that instinct produces a late report. The early warning is not a findings report. It is a signal that something is happening, sent while you still know very little.

The structure of both regimes makes this explicit:

24 hours    early warning        what you suspect
72 hours    incident notification what you have established
1 month     final report          what it was, and what you did

Three reports, escalating certainty. A team waiting for certainty before the first has misread the architecture — the design assumes you do not know yet.

---

What triggers awareness in practice

There is no exhaustive list, and that is the point. But some events start the clock more often than teams expect:

• A researcher emails your disclosure address describing an actively exploited flaw
• A customer reports behaviour consistent with compromise
• Your own monitoring flags an anomaly your team judges credible
• A supplier notifies you that a component you ship is affected
• A vulnerability you already knew about appears in an exploitation feed

The last one is the trap. Under CRA Article 14, the obligation covers *actively exploited* vulnerabilities. A known, unpatched, low-priority flaw becomes reportable the moment exploitation is observed — and the clock starts then, not when you re-triage it.

---

The organisational failure hiding behind the technical one

Ask a compliance team who can send an early warning to an authority, and the answer is usually a committee.

A committee cannot convene inside 24 hours reliably, and never at 2 a.m. on a Saturday.

This is not a technical problem. It is a decision-rights problem wearing a technical costume. The 24-hour clock is a test of your escalation path, not your forensics.

---

What a working process looks like

One named person, with a named deputy, who can notify without seeking approval. Not a role — a person, with a phone number.

A written low threshold. "When in doubt, send the early warning" is a defensible policy. An early warning that turns out to be nothing costs a follow-up. A missing one costs a breach of the obligation.

A pre-drafted template. At hour one you know almost nothing. The form should be answerable with almost nothing.

A timestamped log of when you became aware. This is the artefact an authority will actually ask for, and it cannot be reconstructed later.

---

Why the log matters more than the report

An authority reviewing a late report asks one question: when did you know?

If the answer comes from a system — a ticket, an inbox timestamp, a monitoring alert — it is evidence. If it comes from memory, it is an assertion, and it will be read against you.

Record the moment of awareness as it happens. It is one line, it costs nothing, and it is the only thing that can prove the report was timely.

---

Four things to fix this week

1. 1Name the person who can notify, and their deputy. Write the names down.
2. 2Set the threshold low, in writing. Ambiguity resolves toward silence otherwise.
3. 3Draft the early warning template now, while nothing is on fire.
4. 4Start logging awareness timestamps — the log is the evidence, not the report.

---

Test your reporting readiness — free, no account

• [Free readiness assessment](/assess) — which reporting obligations reach you, and on which clocks
• [Compliance responsibility mapper](/resources/responsibility-mapper) — who is accountable for the notification

---

Further reading

→ CRA Article 14 incident reporting → NIS2 incident reporting timelines → Audit-ready evidence for the CRA → One evidence set across five EU regulations

---

*This is regulatory information, not legal advice, and nothing here constitutes a compliance guarantee. Reporting obligations, recipients and thresholds differ between instruments and, for NIS2, between national transpositions. Verify against the applicable texts and consult your competent authority or a qualified adviser.*