Item 1.05 gives a public company four business days to file a Form 8-K after it determines a cybersecurity incident is material. Most coverage counts those four days. The counting starts a word too late.
The hard word is determines. You cannot disclose what you cannot describe, and a materiality call is a factual claim a registrant has to sign and then defend: what data left, where it went, and whether that movement was the breach. Miss those facts and the clock is running against a guess.
The clock starts when you know, not when it happened
The four-day trigger is not the moment of compromise. It starts when you determine the incident is material, and the SEC has said a registrant may not stall that determination once the facts are in hand. So the pressure lands somewhere most companies do not rehearse. Not the disclosure draft. The factual record underneath it, and how many days pass between detection and the moment that record is complete enough to call.
Build the call on partial facts and you will amend it. Item 1.05 expects amendments when material information was not yet determined or available at filing. Each one is a public correction. A run of them tells the market, and the staff reviewing the filing, that you did not know what moved.
Materiality runs on movement, and most stacks go quiet there
Materiality turns on whether a reasonable investor would care. For a cyber incident, that judgment is almost always a movement question: which records left, how many, whose, to where. A perimeter alert says something got in. It says nothing about what left.
Here is where the trouble lives. Your most valuable data leaves on access you granted on purpose. The credential was valid. The export job was an approved job. The destination was a sanctioned integration. Every move cleared, so every tool you own let it through. No single move is the breach. The pattern is: the volume, the off-hours timing, the identity behind the job, the destination that does not fit the work.
Tools that judge permission fall silent on exactly the events that decide materiality, because nothing was forbidden. That leaves you rebuilding the movement after the fact, from logs never designed to answer what this data actually did, while the clock keeps moving.
A disclosure needs four facts, and they are all about movement
What data left. Not which systems got touched. Which records walked, and in what volume. Materiality scales with the records at stake, so a number you can defend beats a precise count you cannot.
Where it went. Internal staging, a sanctioned SaaS destination, or out of the account entirely. The destination often draws the line between a contained incident and a reportable one.
Who and what carried it. The identity and the job behind the move. "An approved export ran" and "an approved export ran for a user who never runs it, after hours, at twenty times the usual volume" are different filings. Only the second is one you can stand behind.
When the pattern formed. Determinations get tested on timing. A record of when the anomalous movement began and when it surfaced is what lets you defend the date the clock started.
No stack that produces those four facts fast, and the materiality call is an estimate wearing a timestamp.
Where the record gets built
You get a movement record in one of three places. In advance, where predictive tools guess and the permitted export reads as routine. After the fact, where forensics reconstruct what is already gone. Or at runtime, on the move itself, while it is happening. The pattern is only visible in the third place, and the third place is the only one that hands you the evidence as it forms instead of weeks later.
Hilt watches data movement at the kernel, metadata only by default, off the path at roughly a tenth of a core. It resolves each move to a probabilistic identity: which user, which job, which destination, and whether this fits what that identity normally does. When the shape is wrong it writes a case, the identity, the access pattern, the destination, the volume, the window, and it can isolate the host at the network from the control plane. It never sits inline. It never blocks, drops, or alters traffic.
That case is the thing a disclosure needs: a contemporaneous, structured record of what moved, captured as it moved, not pieced together later from logs built for some other question. Producing it does not require reading your data. The default vantage is metadata, so the record carries the shape of the movement, not its contents. Content-aware inspection is there when you want it, never the price of admission.
The case does not make the materiality call. That judgment belongs to you and your counsel. It gives the judgment a factual spine instead of a best guess, and it shortens the run from detection to a determination you can sign.
This is not a stand-in for incident response, outside counsel, or your disclosure committee. The endpoint tools still catch known attack patterns. The network controls still govern access. The SIEM still aggregates. What runtime governance adds is the layer none of them were built to cover: the movement record itself, resolved to identity, scored against normal, captured live.
The SEC rule did not invent the need for that record. It made the absence of it expensive, in public, on a four-day clock, in a filing the market reads line by line.
If your stack cannot answer "which records actually left this account, resolved to the job behind the move, scored against how that data normally moves, in the window between detection and now," your materiality clock is running against a gap. The next useful step is a 30-minute technical call to walk through what it would see in your own environment.