A clinician opens a chart she is authorized to open. Your access control list says yes, correctly. The Security Rule does not stop there, and neither should you. It asks what happened next: where that ePHI went, who moved it, and whether that move was normal for that person and that job.
Most compliance programs prove the first half and assume the second. They document who was granted access. They cannot show how the data behaved once the access was used. The audit and integrity standards live in that gap, and a list of permissions does not satisfy them.
What the rule actually requires
The Security Rule is not a list of products. It is a set of required and addressable safeguards, and several of them are about movement, not permission.
Audit controls (§164.312(b)) require a mechanism that records and examines activity in systems that hold ePHI. Information access management and access control (§164.308(a)(4), §164.312(a)) cover who may reach the data. Integrity (§164.312(c)) requires that ePHI is not improperly altered or destroyed. Information system activity review (§164.308(a)(1)(ii)(D)) asks you to regularly examine records of system activity.
Notice the verbs: record and examine, review, examine again. The rule does not only gate access. It tells you to look at what access did, often enough that you would catch a move that should not have happened. That is an evidence requirement about behavior, not a policy about permission.
The blind spot every covered entity shares
Your most valuable data leaves on access you granted on purpose.
A billing system exports claims it is supposed to export. An integration engine syncs records to a partner under a signed business associate agreement. The clinician opens her chart. Every move is permitted. Every access control, every BAA, every role-based gate lets it through, because that is what it was configured to do.
The danger is not the single permitted move. The danger is the pattern across moves. The same authorized clinician pulling charts she has no clinical reason to see, in volume, off-hours, against patients she is not treating. The integration engine that normally syncs a steady trickle suddenly draining a quarter of a patient population to a destination it has never used. No policy breaks on any single action. No access rule fires. The tools built to enforce permission stay silent, because permission was never what broke.
So the disclosure surfaces late. In the forensic review. In the notification letter to the Office for Civil Rights. The control that proves "this person was allowed" is blind to "this movement was abnormal," and abnormal is the part that hurts you.
Logs versus evidence of movement
Most HIPAA audit programs lean on application and access logs. Those logs are real and useful. They tell you a user authenticated, a record opened, an export ran. They are a building's sign-in sheet: who badged in, when.
A sign-in sheet does not tell you what someone did once inside. Application logs record actions within one application. They do not stitch together what a single identity did across an EHR, a file share, a database export, and an outbound connection in the same window. They rarely resolve a move to the job behind it. They almost never score a move against months of history to say whether it fits how that identity normally behaves.
That gap decides whether you pass an audit. "We retained logs" meets the letter of keeping records. "We reviewed ePHI movement, and abnormal movement surfaced as a case someone could read and act on" meets the spirit of the audit-controls and activity-review standards. The second answer is the one that holds when OCR, an auditor, or your own incident responder asks what actually happened.
Where runtime data movement evidence fits
The only place to see the pattern is at runtime, while the data moves. Not before, where predictive tools guess and false-alarm. Not after, in the forensic timeline. While it happens.
Hilt watches data movement at the kernel, metadata only by default, off the path. The collector does not sit between the data and its destination, and it does not have to read your data to see a move is wrong. It resolves each move to a probabilistic, source-dependent identity: which user or service, which job, which destination, and whether this fits what that identity normally does. One lightweight collector per host or workload, single-tenant inside your own cloud, on the order of 0.1% of one core and 4 to 8 MB of memory. The events never leave your account.
For the Security Rule, that produces evidence, not another log to retain. When an authorized identity moves ePHI in a way that breaks its own pattern, the deviation shows up across layers at once. The job is unusual for that identity. The access is a bulk read of high-value paths in a short window. The destination volume runs abnormal despite a permitted channel. One signal is noise. Together they form a pattern, and a pattern becomes a written case, not an alert.
That answers the rule on its own terms. Audit controls get a mechanism that examines activity against ePHI rather than only recording it. Activity review gets anomalous movement surfaced as it forms, continuously, instead of a quarterly log dig. Integrity gets early sight of the abnormal movement that tends to precede improper alteration or exfiltration. When a move warrants it, the response is host-level network isolation, quarantine from the control plane, never inline filtering that could take a clinical system down with it.
What it does not do, and where it sits with what you have
Hilt does not replace your access controls or your BAAs. Role-based access, minimum-necessary policy, and encryption at rest and in transit stay the foundation, and the rule still requires them. Those tools answer "who may." They answer it well.
Hilt adds the layer above: what did this access actually do, and was that normal. It sits alongside your EHR audit logs and your DLP, and it covers the one thing they were never designed to cover, the abnormal pattern run through permitted channels by legitimate, authorized people. On the endpoint, Hilt can stand in for your endpoint sensor, and many teams retire their EDR once it is in place; keep an EDR alongside only if you want the malware and intrusion layer too. It also will not read PHI by default, which is the point. Metadata-only is the default vantage, so the system sees that a movement pattern is wrong without inspecting the content of a single record. Content-aware inspection is available the day you decide you want it. It is never the price of admission, and for a HIPAA program a control that reads almost no PHI is a privacy posture worth having on its own.
Questions worth asking any vendor
If you are evaluating how to prove ePHI movement, not permission, a few questions separate real evidence from more logging.
Does it resolve movement to an identity and a job, or just log the action? A record that a user opened a chart is an action. A record that resolves the move to who, which job, which destination, and how it compares to normal is evidence.
What does it have to read to work? Metadata-only by default means the system reasons about ePHI movement without inspecting record content. The less PHI a monitoring control must read, the smaller your exposure.
Where does the evidence stay? Data residency is not optional for ePHI. The path from a kernel event to a written case should run single-tenant inside your own cloud, AWS, GCP, Azure, or Ali Cloud, and events should never route through a vendor's environment.
How does it respond without risking a clinical system? A control that sits inline can become a single point of failure in front of care delivery. Ask whether it stays off the path and responds with host-level network isolation from the control plane rather than filtering traffic.
What the rule has always asked
The HIPAA Security Rule was never only about who holds the keys. The audit, integrity, and activity-review standards ask you to know what your ePHI actually did. For most programs that knowledge stops at the access list and picks back up, too late, in the breach review.
Runtime data movement evidence fills the middle. It shows how PHI moves, resolved to the identity and the job behind it, scored against how it normally moves, while it is moving. That is the difference between proving who could touch the data and proving how the data behaved.
To see what that evidence looks like against your own environment, the fastest path is a 30-minute technical call, engineer to engineer. That is usually enough to show how the collector resolves a move and where it fits alongside what you already run.