DDR put data at the center of the question, and that was overdue. The industry had spent a decade watching the perimeter and the endpoint: keeping attackers out, logging which processes ran. None of that answered where your data went. Data Detection and Response named the missing object. Not the host. Not the login. The data, and what happened to it.
Then it answered the question in the past tense.
Most DDR, as the term gets used, reports after the move lands. It tells you sensitive data left, names the destination, names the account, on a timeline you rebuild once you already suspect something. That is forensics with a faster clock. Useful. Not the same as catching the move while it forms.
Data movement governance keeps the object DDR named and moves the action to runtime. Same problem. Earlier in time.
What DDR got right
Most of the value is here, so keep it.
DDR changed the unit of analysis. The thing you protect is not a server and not a session. It is data, and data has a lifecycle: created, copied, transformed, moved across cloud stores, SaaS apps, endpoints, and now AI agents. Track that lifecycle directly instead of guessing at it from host telemetry. DDR got that call right.
DDR also made classification operational. Knowing a given store holds regulated records, source code, or customer financials is the prerequisite for caring when those records move. That work is real, it is upstream, and Hilt does not redo it.
And DDR dropped the prevention theater. The prior generation of data loss prevention promised to stop bad moves in advance, buried teams in false positives, and missed the move that mattered anyway. DDR admitted what the false positives proved: you cannot reliably pick the dangerous permitted action before it happens. Watch closely, respond fast.
Right object. Right groundwork. Honest about prediction. What it left on the table was when it acted.
The blind spot the after-the-fact frame keeps
Your most valuable data leaves on access you granted on purpose. The trading model copies out through an approved transfer job. The customer table gets pulled by a service account that pulls tables all day. The repository clones to a laptop owned by an engineer who clones repositories for a living. Every move is permitted. Every tool you own lets it through, correctly, because each move on its own is exactly what you authorized.
The danger is never the single move. It is the pattern across moves: this identity, this volume, this hour, this destination, set against what this identity has done for months. A permitted move can still be the breach. The permission was right. Only the behavior changed.
After-the-fact DDR can show you that pattern. It shows it once you go looking, and you go looking because something already happened: a disclosure, a tip, an audit at quarter close. The pattern sat in the logs the entire time. You read it too late to use it.
That is the gap. Not negligence. Not a missing feature on a roadmap. A timing limit baked into where the action sits.
What changes when the action moves to runtime
Runtime is the one window where the pattern is visible and you can still do something. Not before, where predictive tools guess and guess wrong. Not after, where the data is gone and you are drafting the notification. While the data moves.
Data movement governance runs a light collector inside your own cloud and watches data movement at the kernel. The kernel sees every move regardless of which app, protocol, or account drove it, because everything that moves data crosses it. The collector reads metadata by default: which identity, which job, which destination, how much, when. It does not read your data to know a pattern is wrong. Content-aware inspection is there when you want it, not the toll for entry.
Each move resolves to an identity, probabilistic and source-dependent: the user or service behind it, the job it belongs to, where it is headed. That resolved move scores against how the identity normally moves data. A quant researcher copies proprietary code in small off-hours chunks through an approved channel over two weeks. No single action trips a rule. The sequence drifts from her baseline on job, on access shape, and on destination volume at the same time. Any one signal is noise. Together they are a case, written while the move is still happening, not reconstructed after.
Then the action: host-level network isolation, quarantine, issued from the control plane. The collector never sits inline. It does not block, drop, or alter traffic, and it is not a chokepoint in front of your data path. It watches the move and isolates the host at the network when the pattern warrants it. That is the response in data movement governance: a real action at runtime that never stands in front of the business.
The architecture is the difference, not the acronym
Call it DDR with a fresh label and the claim falls apart on one test, an architectural one.
After-the-fact tooling can live in a vendor's SaaS, batch your events, and answer on a delay. Its job is answering questions about the past, and the past waits. Acting while a move forms does not wait. The collector has to sit close to the data, run light enough to live everywhere the data lives, and stay private enough that you actually let it run there.
The constraints follow. The collector stays off the path, on the order of 0.1% of one core and 4 to 8 MB of memory per host, because anything heavier gets vetoed by the infrastructure team before security gets a vote. It is single-tenant inside your own cloud, AWS, GCP, Azure, or Ali Cloud, because events describing how your most sensitive data moves should never leave your account to reach a verdict. The same collector covers cloud workloads and user endpoints, because data ignores the line between them and so should the thing watching it move.
None of that is bolted onto DDR. It is what acting at runtime forces. You cannot pull the action earlier in time without pulling the collector closer in space, lighter in weight, and tighter in residency. The timing changed, and the timing rewrote the architecture.
How to place the two
Running DDR, a data security posture tool, or classification today? Keep them. They do inventory and after-the-fact reconstruction well, and data movement governance does not replace that. The classification, especially, is upstream of everything Hilt does.
What governance adds is the runtime layer the after-the-fact frame cannot reach by design: the dangerous pattern across permitted moves, surfaced as a case while you can still isolate the host, without reading your data and without sitting inline. DDR named the problem. Moving the action to runtime is what it took to act on the problem in time.
Try the test on your own stack. Can you answer "what did this identity's data actually do, resolved to the job behind it, scored against how it normally moves, in the window it is moving right now" from the tools you have? Then you are covered. If the honest answer is "we would find that in the logs next week," that is the layer you are missing.
If you want to see what runtime watching looks like on real movement, the next step is thirty minutes, engineer to engineer. No deck. We walk the architecture and where it fits next to what you already run.