An auditor asks one question that most SOC 2 evidence cannot answer: show me a time your most valuable data moved somewhere it should not have, and show me that you saw it and acted. What teams hand over instead is a binder. Policies. Access reviews on schedule. Tickets closed. Logs retained.
None of that is the same as the thing the report implies. A SOC 2 Type II report tells a customer that an independent auditor watched your controls operate over a window and found they worked. The customer reads it as: this company can be trusted with our data. Your evidence describes intent and configuration. The promise is about behavior. That is the gap, and it is structural, not a matter of auditor laziness.
Two criteria most teams paper over
The Trust Services Criteria are where data movement lives, in two places teams quietly skip.
CC7 asks you to detect and respond to anomalies and security events. C1, the Confidentiality category, asks you to protect designated information through its lifecycle, including how it moves and where it lands. Read them together and they describe one capability: you can watch your sensitive data move, recognize when a move does not fit, and act while it is happening.
The honest test going into an audit is whether you can produce the record that this happened, not the policy that says it should. "We monitor for unauthorized data exfiltration" is a control description. What satisfies the auditor is the move itself: which one was anomalous, when you saw it, what you did.
That record is hard to produce, because the dangerous moves are the permitted ones.
The dangerous move already passed your controls
Your most valuable data does not leave through a hole. It leaves on access you granted on purpose, through channels you approved, carried by people and jobs that were supposed to touch it.
A file gets read in one service account. Minutes later, it leaves from a destination that account has never used. The service account reads the database because that is its job. The analyst exports the report because exports are allowed. The sync pushes records to the warehouse because that is the pipeline. Every tool you own lets each one through, correctly, because each one in isolation is fine. The breach is the pattern: the volume, the timing, the destination, the combination that does not fit what that identity normally does. Every move is permitted. The pattern is the breach.
So permission-based evidence cannot prove the monitoring criterion. An access log shows an action was allowed. It does not show whether the run of allowed actions was anomalous. A clean access log tells the auditor nothing violated a rule. It does not tell the auditor nothing was wrong.
Rules guess. Forensics arrive late. Runtime sees it move.
There are three ways to generate evidence about data movement. One of them answers the criterion the way the report implies.
Predictive tools, the DLP world, log rules and blocks. They guess in advance which moves are dangerous and fire on the patterns someone thought to write down. The evidence is real and partial: it covers what was anticipated, and it buries the audit in false positives that then have to be explained away.
Forensic tools reconstruct the move from logs and disk after the incident. This is the disclosure-letter timeline. Good for the postmortem, useless for the monitoring criterion, because the criterion is about catching the move inside the window, not narrating the loss after it.
Runtime evidence is the move seen as it happens: resolved to the identity and the job behind it, scored against what is normal, surfaced as a case when the pattern is wrong. That is what maps onto CC7 and C1, because it is the control operating on a real movement instead of a hypothetical one.
How the evidence comes off the kernel
Hilt is runtime Data Movement Governance. One lightweight collector watches data movement at the kernel, metadata only by default, off the path. It runs single-tenant inside your own cloud, on the order of 0.1% of one core and 4 to 8 MB of memory per host. It does not sit inline. It does not block, drop, or alter traffic. It watches the move instead of standing in front of it.
For each move it resolves a probabilistic, source-dependent identity: which user or service, which job, which destination, whether this fits how that identity normally behaves. When the pattern is wrong, the deviation shows up across layers at once. The job is unusual for the identity. The access is a bulk read of high-value paths in a short window. The destination volume is unusual even through an approved channel. Any one signal alone is noise. Together they are a case, and the system writes the case instead of paging you with alerts. When a move warrants it, the response is host-level network isolation, quarantine from the control plane.
Three things about this matter to a SOC 2 auditor.
The evidence is behavioral, not configurational. The written case shows the anomalous move, the identity it resolved to, the time, the signals that combined, and the action taken. That is CC7 operating, on a real event, with a timestamp. It is the record the monitoring criterion was written to require.
The control does not read your data to do its job. Metadata only by default means it sees the pattern is wrong without inspecting content. For C1 that is the point: a confidentiality control that has to read confidential data to protect it sits badly next to the criterion it serves. Content-aware inspection is there when you want it. It is not the cost of entry.
The events never leave your account. Kernel event to written case runs single-tenant inside your own cloud: AWS, GCP, Azure, Ali Cloud. The confidentiality evidence does not route through a vendor's SaaS, which is one fewer thing the auditor takes on faith.
What changes in the audit room
You stop telling the auditor what you would do and start showing what the control did.
Before, the monitoring narrative was a policy, a sampling of access logs, and a few closed tickets. The auditor tested that the process ran. The behavior underneath stayed dark.
Now the narrative is a set of written cases across the window: anomalous moves the system surfaced, resolved to identity, scored against normal, with the response recorded. Some of those cases will be benign once a human looks. A new but legitimate pattern, reviewed and cleared. That is good evidence too. It shows the control fired, someone looked, a decision got made. True cases and cleared cases together are exactly what a Type II report is supposed to demonstrate: a control operating over time, with judgment, on real movement.
Hilt does not replace your access governance, your SIEM, or your detection stack, and it does not let you off the other Trust Services Criteria. It closes the one gap those tools were never built for: the dangerous pattern across permitted moves, seen at runtime, written as a case an auditor can read.
A SOC 2 report says you can be trusted with data. CC7 and C1 are where that claim is tested, and they are the two most teams back with evidence of intent rather than evidence of behavior, because permitted moves leave permitted logs.
If your evidence cannot answer "show me an anomalous data move this control caught during the window, who it resolved to, and what the team did about it," you have the gap the report quietly assumes you closed.
If you want to see what that evidence looks like coming off the kernel, the shortest path is thirty minutes, engineer to engineer, walking one real case end to end.