What NIS2 and DORA actually ask of your telemetry

NIS2 and DORA are usually introduced to engineering teams at the end of a governance programme, as a set of controls to be evidenced. That framing misses the part that costs the most to retrofit. Underneath the obligations sits a small number of very concrete demands on data — how fast it can be queried, how far back it goes, whether it can be shown not to have been altered, and whether anyone can reconstruct a sequence of events across systems that were never designed to be read together.

Those are architecture decisions. They are made years before an incident, usually by people who were not thinking about regulation when they made them, and they are expensive to reverse under time pressure.

The clock is the requirement

NIS2 structures significant-incident reporting in three stages: an early warning within 24 hours of becoming aware, a fuller notification within 72 hours carrying an initial assessment of severity, impact and indicators of compromise, and a final report within one month covering root cause and remediation. DORA, which applies to financial entities, sets a tighter initial notification than that — so an entity in scope of both meets DORA's clock first.

Read as an engineering specification rather than as a compliance artefact, the sequence says something unambiguous. Within one day you must be able to state that something significant is happening. Within three you must be able to characterise it. Within a month you must be able to explain how it began. Each of those is a different question asked of the same data, and each fails in a different way.

What each stage asks of the platform

The three deadlines are not the same requirement at three levels of detail. They are three genuinely different workloads, and a platform can satisfy one while being structurally unable to satisfy another.

Retention is not a single number

NIS2 does not prescribe a retention period. That is frequently reported as helpful flexibility, and it is the opposite: it moves the decision to the organisation without removing the consequence of getting it wrong. A final report has to establish root cause, and root cause is routinely older than a short retention window — the foothold precedes the detection by weeks more often than it follows it.

The workable answer is the tiering decision made deliberately rather than by default: recent data fast enough to answer the 24-hour question, a broader window queryable within the 72-hour one, and an archive that is actually readable — partitioned the way an investigation searches, in a schema the query engine will still understand in three years. An archive that is written but has never been read is a storage cost, not a capability.

A retention policy set by licence cost is an incident-reporting policy that nobody wrote down.

Evidence, not just data

The obligation is to report, which means the output is a statement to an authority rather than a dashboard for an analyst. That raises the bar on the record itself in three ways that ordinary operational telemetry rarely meets.

• Integrity: the store has to make tampering detectable, and access to the store has to be logged somewhere the same incident cannot reach.
• Provenance: every transformation between the source and the archive has to be recorded, so an absence in the data can be distinguished from an absence in the world.
• Time: clock discipline across sources, because a reconstruction that cannot order two events reliably cannot establish causation between them.

None of this is exotic, and all of it is cheap to build in at the pipeline and very expensive to add afterwards — which is the recurring shape of this whole subject.

Where the engineering and the compliance work meet

An organisation in scope of several of these regimes at once — NIS2 for its sector, DORA if it is a financial entity, the AI Act if it places or operates certain AI systems — will find that each demands its own documentation and its own evidence chain, on inconsistent timelines. The compliance response is to map the controls. The engineering response is different and complementary: build the telemetry once, to the strictest of the obligations, and let each framework read the same substrate.

That is worth stating plainly because it is the part that is routinely done twice. A platform that can answer an incident question in an hour, prove what it holds, and keep the answer available for a year satisfies the technical core of all of them. What remains genuinely per-regulation is the scoping, the classification and the submission — and those are not engineering problems.