Guide

NIS2: Detection and Reporting Need Data Movement Evidence

May 5, 2026 Hilt 8 min

Your most valuable data leaves on access you granted on purpose. NIS2 raises detection and incident-reporting duties across essential and important entities. How runtime data movement evidence supports both the detection and the clock.

NIS2: Detection and Reporting Need Data Movement Evidence cover image

Article 23 starts a clock. You become aware of a significant incident, and 24 hours later an early warning is due. At 72 hours you owe a notification with an initial read on severity, impact, and any known indicators of compromise. A final report lands inside a month. Miss the substance of those filings and the directive treats it as a failure of the security program, not a paperwork slip.

The first NIS2 directive let you answer with posture. Have the controls, file the policies, pass the audit. The second one wants operation. Detect the incident, then describe what it did to your data before the deadline forces you to guess. Your risk assessments and supply-chain reviews do not answer that. They prove you prepared. They do not tell you what moved on a Saturday night.

The incident that never trips a control

A file gets read in one account. Minutes later, the same data leaves through an integration you approved last quarter.

That is the class of incident NIS2 inherits and does not fix. Your most valuable data leaves on access you granted on purpose. A compromised login. A third-party token with standing permission. An employee three weeks from a competitor. Each one moves data through a channel that is supposed to be open. Every move is permitted, so every control you own waves it through. There is nothing for a policy engine to deny.

The pattern is the breach. A service account reads a handful of records a day for a year, then a hundred thousand over a weekend. A user pulls from paths their role has never touched, at an hour their job has never run, toward a destination that is new for that identity. No rule breaks. The shape of the activity does.

This is where a posture program meets its 24-hour clock with nothing to file, because nothing ever flagged. The breach sat in plain view the whole time. It was not legible to a control that asks whether each move was permitted instead of whether the pattern was normal.

Watch the movement while it happens

You cannot meet a detection duty against this by predicting it in advance, and you cannot meet it by reconstructing it after the disclosure letter goes out. You watch the movement as it forms.

Hilt is runtime Data Movement Governance. One lightweight collector watches data movement at the kernel, metadata only by default, off the path. It does not sit between your data and its destination. It does not block, drop, or alter traffic. It reads the shape of the movement and resolves it. The footprint runs around 0.1% of one core and 4 to 8 MB of memory per host, light enough for in-scope entities running throughput-sensitive infrastructure that cannot carry a heavy inline agent.

Every move resolves to a probabilistic, source-dependent identity: which workload, which user, which job sits behind it, which destination, and whether any of that fits how the identity usually moves. When the activity deviates, it deviates on several axes at once. The job is wrong for the identity. The read is a bulk pull of high-value paths in a narrow window. The volume to that destination is off, even though the channel was approved. One axis alone is noise. Stacked, they are a pattern. A pattern is a case, not an alert.

Your bank flags the charge that does not fit. Hilt does the same for your data, and that is the difference between an incident you report and an incident a regulator reports to you. Detection that fires on the pattern, while the data is still moving, is what makes the 24-hour clock survivable.

It runs single-tenant inside your own cloud: AWS, GCP, Azure, or Ali Cloud. Events never leave your account. An entity already counting its third parties under NIS2 does not get a new one holding its most sensitive movement data.

Evidence the report can stand on

The 72-hour notification wants an initial assessment: severity, impact, what is known about the cause. An honest one answers a hard question fast. What did this actually touch? Which identity, which job, which paths, which destination, across what window? A program that knows an incident happened but cannot characterize the movement either delays the filing or fills it with guesses. A regulator reads both for what they are.

Hilt resolves each move to an identity and writes the case as the pattern forms, so the material the 72-hour notification needs is assembled before the deadline lands. Not a raw log dump to reconstruct under pressure. A written account of what the data did, scored against how it normally moves. The case answers the questions the notification asks, and it carries into the one-month final report, where the standard rises to a fuller account of the incident and the response.

When the case warrants it, Hilt responds with host-level network isolation, quarantine from the control plane. You contain the host at the network rather than by filtering traffic inline, and the action is recorded as part of the case instead of improvised afterward. That is a containment measure NIS2 expects an essential or important entity to be capable of, and one you can describe in the filing because it is already written down.

Where Hilt fits

Hilt is not a NIS2 compliance suite, and it does not stand in for the governance the directive requires. It will not write your risk assessment, run your supply-chain reviews, or build your management accountability structure. Those duties are real and they live elsewhere in your program.

What it adds is the evidentiary layer under the detection and reporting duties. A runtime account of data movement that makes detection meetable against permitted-pattern incidents, and makes the reporting clock survivable because the description of what moved is already written when the deadline arrives.

The directive moved the bar from posture to operation, and operation runs on evidence. Under NIS2 the evidence that decides your filing is the evidence of what your data did, resolved to the job behind each move, while there was still time to act.

If your readiness work can describe your controls but cannot answer "what did this identity's data do, between these hours, through this approved channel, scored against how it normally moves," that is the gap a runtime data movement layer closes.

If you want to see how that maps onto your in-scope estate, the next step is a 30-minute technical call, engineer to engineer. Long enough to walk through where the collector sits, what it resolves, and what the case looks like when the pattern is the breach.