45 CFR § 164.312 names four standards and gives you eight words to satisfy the hardest one. "Mechanisms that record and examine activity." That is the entire audit-control specification. No technology, no checklist, no definition of which activity. The rule was written in 2003 and patched in 2013 to cover a rural clinic on a closet server and a cloud telehealth platform with the same sentence, so it had to stay abstract.
That abstraction is where auditors and breaches both live. You get four standards. Two are required: Access Control (§164.312(a)(1)) and Audit Controls (§164.312(b)). Two are addressable: Integrity (§164.312(c)(1)) and Transmission Security (§164.312(e)(1)). Addressable does not mean optional. It means you may swap in a different control if you write down why the default one does not fit your environment. Most healthcare orgs implement all four and move on.
The specifications underneath read like a hardening guide: unique user IDs, encryption, automatic logoff, audit logs, integrity checks. Not one of them tells you how to catch a privileged account copying fifty thousand records at 2 AM. None tells you how to notice that a process that has only ever touched the billing database started reading treatment notes last night. The regulation requires the outcome. It hands you nothing for the mechanism.
Audit controls: the gap is not the log, it is the layer
Every healthcare CISO can recite the inventory. Application logs, database audit trails, network flow records, endpoint agents. The problem is not that you lack logs. It is where the logs sit relative to the move.
Application logs record what a user did inside the application. They go dark when someone runs scp against a database dump on disk. Database audit trails record queries the database ran. They say nothing when a compromised service account pulls PHI out of a container that should not be running at all. The log is downstream of the application processing the request, so an attacker who bypasses or tampers with that application produces a clean log of a move that already happened.
Logs are also scattered. The EHR, the PACS system, the patient portal, the HL7 interface engine, the database, the network, the endpoints each keep their own. Stitching one exfiltration path across all of them is either a large SIEM bill or an analyst reading dashboards at midnight. And even stitched together, the logs describe symptoms of the move, not the move. To judge whether a transfer of PHI is a backup or a theft you need the user context, the process that opened the file, the destination it reached, and whether any of that matches how the host behaves on a normal Sunday. Watching at the kernel, beneath whichever application or account ran the move, is what puts those facts in one place.
Access control after RBAC
Section 164.312(a) requires unique user identification and emergency access procedures and makes automatic logoff and encryption addressable. Your EHR already enforces role-based access. Physicians see treatment data, billing sees claims, registration sees demographics. RBAC answers who is allowed in. It says nothing once a permitted account does something it has never done.
A physician assistant gets phished. The attacker signs into the EHR from a residential IP two states away at 11 PM and pulls two hundred records in fifteen minutes. The PA's credentials are valid. The role grants the access. The EHR writes a log of a successful authentication and an authorized read. Your SIEM might flag the geography, if that rule is tuned and not already buried under false positives from clinicians who travel.
Catching this needs three readings of the same event at once. Is this normal for this PA. Is this normal for PAs as a role. Is this normal for this server at this hour. User behavior analytics watch the first. Performance monitoring watches the third. Few tools hold all three against a single move, watched below the application layer where the attacker is editing the logs. When a valid process reads PHI off disk and ships it out, the read looks authorized. The pattern around it does not.
Detecting PHI movement at runtime
Transmission security (164.312(e)) says guard PHI in transit. Most orgs read that as TLS everywhere and stop. Encryption is necessary and it solves a different problem. It does nothing about an authorized account moving PHI to the wrong place.
A real exfiltration rarely breaks a rule. It uses sanctioned tools, sanctioned accounts, and sanctioned channels, at the wrong hour, in the wrong volume, to the wrong destination. Each move is individually permitted, so every control you own correctly waves it through. The breach is the pattern across the moves. You can see that pattern in one window only: at runtime, while the data is moving. Not before, when predictive tools are guessing. Not after, when the records are gone and you are drafting the breach notification.
Your network monitor sees encrypted bytes and trusts them. Your DLP decided in advance and only fires if the PHI sits in a shape its signatures already recognize. Your endpoint tools see the file operation if the agent is deployed and the attacker did not turn it off first.
Hilt governs the move itself. One lightweight collector watches data movement at the kernel, metadata only by default, off the path and single-tenant in your own cloud. It sits beside the workload, never inline, so it does not block, drop, or alter traffic. It reads the metadata of each move, the process behind it, the file path, the destination, the timing, and resolves the move to a probabilistic, source-dependent identity and the job that ran it. Content-aware inspection is there when you want it. The default is metadata only, so you govern where PHI goes without reading the records themselves.
A backup job that reads patient data at 3 AM every Sunday is baseline. The same job firing Tuesday at 2 PM and writing to an S3 bucket no one has seen before is an anomaly on all three readings at once: the user, the role, and the host. Hilt surfaces that pattern, writes the case, and responds with host-level network isolation (quarantine) from the control plane. The host comes off the network. Nothing gets filtered packet by packet.
Implementing the safeguard without rebuilding the stack
Keep the EHR. Keep the EDR. Keep the network monitoring. Each does a job, and Hilt sits additive to all of them. The missing layer is governance of the data movement itself, at runtime, beneath the application abstractions an attacker rewrites first.
One collector covers that layer across cloud workloads and macOS-compatible user endpoints under a single model. It runs off the path, so the overhead is small and measurable: about 0.1% of one core and 4 to 8 MB of memory in production. Because it watches from beside the workload instead of in the request path, it does not slow the systems carrying your PHI.
Deployment is unglamorous, which is the point. Put the collector on the workloads and endpoints that touch PHI, let it learn what normal movement looks like, then read the deviations across user, role, and host together. Identity resolution is probabilistic and source-dependent, so accuracy climbs as the baseline matures instead of leaning on brittle rules that page clinical staff at every false alarm.
What you end up with maps to the regulation's intent without quoting its words back to it. You know how PHI moves. You can audit it. You can catch an unauthorized access or transmission as it forms, and isolate the host before the records leave. That comes from watching the movement directly, with full context, not from aggregating logs and writing correlation rules in advance for an attack you have not seen yet.
The Security Rule never names the mechanism. It asks you to record and examine activity, limit access, and protect PHI in transit, on the same access you granted your own staff on purpose. The rest of your stack guesses ahead of the move or reports after it. If you want to see how watching the move itself fits your environment, we can walk through it on a 30-minute technical call.