A major ICT incident starts a clock. The initial notification to your competent authority is due in hours. An intermediate report follows. A final report closes it out with root cause and remediation. That is what the Digital Operational Resilience Act asks of banks, insurers, investment firms, payment institutions, crypto-asset service providers, and the ICT third parties behind them. Most resilience programs prepare for the part that is easier to prove: harden the systems, test the recovery, map the supplier dependencies.
The clock measures something else. It measures whether you can say what your data did, not whether a system stayed up. A continuity dashboard tells you a service degraded at 14:02. It does not tell you that an approved processor integration read a client book it had never touched and shipped it somewhere new. Both happened while the lights stayed green.
The detection bar, and the reporting bar
Two of DORA's five pillars turn on evidence your continuity tooling does not produce.
The risk-management pillar requires you to detect anomalous activities and to have mechanisms to do it promptly. Promptly is the load-bearing word. A mechanism that surfaces the problem in next quarter's audit is not detection under DORA. It is forensics with a delay.
The incident-reporting pillar is harder still, because it forces you to be specific on a deadline. Classification as major is the trigger, and classification rides on impact: clients affected, data lost, geographic spread, duration, cost. You classify off what you can see. Then the final report wants root cause, and root cause cannot be invented after the fact. It has to have been captured while the event was live.
Your data leaves on access you granted
Here is the structural problem, and DORA did not create it. Your most valuable data leaves on access you granted on purpose. The quant copies a model. The integration syncs to a third-party processor. The analyst pulls a client book. The AI agent reaches across systems on a service credential you issued. Every one of those moves is permitted. Every tool you own lets it through, because nothing is broken. The single move is not the danger. The pattern across moves is.
Run that move past your controls and watch them all wave it on. Access governance asks whether it was allowed. It was. DLP asks whether it broke a rule. It did not. Continuity tooling asks whether the system held. It did. The move clears all three, and what it leaves behind is scatter: log fragments across applications that were never built to correlate.
The clock starts before you have assembled them. So you reconstruct intent from fragments, after the fact, against a deadline. That is the position DORA penalizes you for being in.
Where the evidence comes from
The only place to see the pattern is at runtime, while the data moves. Not before, where predictive tools guess and miss the permitted move anyway. Not after, where forensics and the disclosure letter describe what is already gone.
Hilt watches data movement at the kernel. One lightweight collector per host or workload, metadata only by default, off the path. It does not sit between your data and where it is going, and it does not block, drop, or alter traffic. Overhead runs on the order of 0.1% of one core and 4 to 8 MB of memory per host. It runs single-tenant inside your own cloud, AWS, GCP, Azure, or Ali Cloud, and the events never leave your account. Under DORA that last point is not a footnote. Data residency and third-party ICT dependency are regulated surfaces, and your incident record is itself data. Route it through a vendor SaaS and you have added a dependency to the very evidence you need to prove residency for. Hilt keeps it inside the boundary the regulated entity controls.
Each move resolves to a probabilistic, source-dependent identity: which workload, which job, which destination, and whether this fits what that identity normally does. When a move deviates, several signals line up at once. The job is unusual for the identity. The access pattern is a bulk read of high-value paths in a short window. The destination volume is unusual despite an approved channel. Any one signal alone is noise. Together they are a case, not an alert.
What the clock actually wants
Walk the reporting timeline, which is the part of DORA hardest to talk your way through.
Classification starts it. To call an incident major you need the impact picture: what moved, where, over what window, touching which clients. A written case that already resolves the move to its identity and destination hands you those inputs, instead of a triage team assembling them by hand while the deadline runs down.
The intermediate report asks what you know and what you are doing. Hilt responds with host-level network isolation from the control plane: quarantine. It contains the affected host at the network without standing inline, and the action lands in the case with a timestamp. That is a remediation step you can name, not a promise that a process kicked off somewhere.
The final report asks for root cause. This is where evidence stitched from fragments comes apart under a careful reader. A case built at runtime, resolving the move to the job behind it and scoring it against months of how your data normally moves, holds up when a regulator reads it line by line. The answer to what happened is already written, because it was written while it happened.
What this does not do
Hilt is not a DORA compliance suite, and runtime evidence does not satisfy DORA by itself. The act spans governance, resilience testing, supplier contracting, and information sharing, and most of that lives in your GRC program. Hilt does not replace your continuity planning, your access governance, your DLP, or your third-party risk register. Those cover real ground, and they cover it.
Hilt adds the layer none of them were built to provide: a live, identity-resolved record of what your data did across permitted moves, available in time to act and written well enough to report. It closes the distance between "a system had an incident" and "here is what the data did, who it resolved to, and when we contained it."
For DORA, that distance is the difference between racing the reporting clock and running ahead of it.
So ask your current stack one thing. If a workload's data moved right now on access you granted, could you show in writing what it did, who it resolved to, and how far it fell outside the norm, before the classification clock runs out? If the honest answer is not yet, the detection and reporting pillars are leaning on evidence you do not have.
That is a question worth thirty minutes, engineer to engineer. If you want to see how the runtime record reads against your own DORA reporting workflow, we will walk through it with you.