DORA went enforceable across the EU on January 17, 2025. The clock that matters runs after that: once you classify a significant incident, you have four hours to file the initial notification with your supervisor. Four hours assumes you already saw the thing. Most firms cannot start the clock, because the incident never tripped an alert.
Article 6 wants "mechanisms and procedures to promptly detect anomalous activities." Read it next to how the damage actually happens in regulated finance. Your most valuable data leaves on access you granted on purpose. A service account reads a position table it is entitled to read. A credential authenticates correctly. An agent does the job it was deployed to do. Every move is permitted, so every tool you own lets it through and logs nothing worth waking up for. The breach is not any single move. It is the pattern across them, and the pattern is only visible at runtime, while the data is moving.
The detection clause is the hard part, not the governance binders
Three of DORA's five pillars put weight on your infrastructure rather than your policy folder.
ICT risk management requires continuous identification and assessment of ICT risks. That means knowing what runs, where it runs, and how it behaves on a normal day, so you can tell when a day is not normal.
Incident management, classification, and reporting sets a taxonomy and the four-hour initial notification window for significant incidents. You cannot classify what you never detected.
Digital operational resilience testing mandates basic testing for everyone and threat-led penetration testing every three years for significant entities. Article 26 names the scenarios it expects you to survive and detect: lateral movement, privilege escalation, data exfiltration.
The binders are the easy part. Firms write the governance framework and still fail the spirit of Article 6, because they have no runtime view of how data moves across the estate or whether a given move fits the pattern it should.
"Anomalous relative to what?"
A hostile examiner asks one question and your stack goes quiet: anomalous relative to what baseline?
EDR watches process execution and file access. Network tools read traffic metadata at the perimeter. DLP guesses in advance which content might be sensitive. SIEM aggregates the logs applications choose to emit. None of these resolve the move itself: did this transfer fit the pattern, given who moved it and the job behind it. A trading application reads a position table, calls an external API, writes to a bucket. Each action passes every check. The incident is the shape of the three together.
Build your baseline from logs and rule breaks alone and you build a baseline that cannot see the move that broke no rule. A compromised service account passes every check. An over-scoped automation passes every check. A token stolen and replayed passes every check. Predictive tools guess in advance and miss the permitted move. Forensics arrives after the data is gone, which in DORA terms is the disclosure, not the detection.
Three baselines, correlated
Detection that satisfies "anomalous activities" needs a norm to deviate from, and one norm is not enough. Context decides severity, so Hilt profiles movement against three baselines at once.
User. What a single resolved identity normally does with data. A service account that starts reading databases outside its usual scope. A developer who never touched a production store pulling records from one at 3 AM.
Role. What the group does: all developers, all DBAs, all pipelines. This catches a compromised credential that stays within one person's plausible bounds but breaks the norm for the role.
Workload. What a service or workload type does. A payment processing workload reaching destinations it has never used. A batch job that starts behaving like an interactive session.
One unusual move on its own might be nothing. A move that lands anomalous against user, role, and workload at the same instant is a pattern, and a pattern is what becomes a case. That correlation is the line between behavior and noise.
Where Hilt sits
Hilt is runtime Data Movement Governance, a different category from the tools above. It governs how data moves instead of guessing beforehand or reconstructing afterward.
One lightweight collector watches data movement at the kernel, the vantage where everything a workload does resolves. It runs metadata only by default, so you see that data moved, where it went, and whether it fits the pattern, without reading the data itself. Content-aware inspection is there when a case calls for it; seeing the pattern does not require it. The collector sits off the path. It observes. It never sits inline, and it never blocks, drops, or alters traffic.
The footprint suits production financial systems: on the order of 0.1% of one core and 4 to 8 MB of memory per collector. Hilt resolves each move to a probabilistic, source-dependent identity and the job behind it, so what surfaces is not a raw event but a move attributed to a who and a why.
When a dangerous pattern forms, Hilt writes the case and responds with host-level network isolation from the control plane: it quarantines the host at the network, never by filtering packets inline. A payment processor that starts moving data toward a destination it has never used, on a service account that has never done so, in a workload where it is unprecedented, arrives as one correlating case, and likely a reportable incident, rather than three alerts no one connected. Events never leave your account. The collector is single-tenant, in your own cloud: AWS, GCP, Azure, Ali Cloud.
What TLPT proves
Article 26 testing exercises lateral movement, privilege escalation, and exfiltration. The exercise validates two things: your controls, and whether you would have seen what got past them.
Governing data movement at runtime leaves an artifact for each, even when the attacker uses legitimate tools and credentials. Lateral movement shows up as data moving between systems with no history of exchanging it. Privilege escalation shows up as a low-scope identity suddenly moving data it never touched. Exfiltration shows up as a move toward a destination, or in a volume, that does not fit that identity and job. During the test, a runtime record of how data actually moved gives you ground truth independent of application logs, which is exactly what you need to defend your detection and classification procedures to an examiner.
Hilt can stand in for your endpoint sensor, and many firms retire their EDR once it is in place. Keep an EDR alongside only if you want the malware and intrusion layer too, since Hilt does not do malware, exploit, or live-intrusion detection. Your SIEM, DLP, and network tools can stay in place, and Hilt is additive to each of them. It answers the question none of them was built to answer, whether a permitted move fits the pattern, and it governs the movement those tools correctly let through, especially for cloud workloads and AI agents where access is granted on purpose.
DORA assumes breach and then puts you on a four-hour clock. Whether you make that window comes down to whether you saw the move while it was still moving, on a pattern no rule flagged, without having to read the data to know it was wrong. If you want to walk through how that detection holds up against your own DORA scenarios, book a 30-minute technical call.