Four business days. That is the clock the SEC's 2023 rules put on a material cyber incident: four days to make a legal determination that an incident crossed the materiality threshold and file an 8-K. Not four days to investigate. Not four days to contain. Four days to decide and publicly disclose.
The deadline does not test your security. It tests whether you can say what happened. Day three, your EDR shows an encrypted file, your SIEM shows some lateral movement, your network logs show traffic leaving. Ask the one question that matters for the filing, which data actually left, and the stack goes quiet. A detection gap just became a legal one.
What the rules actually require
Two obligations, not one. Incident reporting and annual risk disclosure.
Item 1.05 of Form 8-K requires disclosure within four business days of determining an incident is material. The clock starts at the materiality determination, not at detection. That reads like slack until you reach the SEC's qualifier: you make the call "without unreasonable delay." You do not get to stall the clock by sitting on the question.
Item 106 of Regulation S-K covers the annual side. Your 10-K has to describe how you identify and manage cyber threats, whether you have suffered material incidents (including ones you never disclosed), and how the board oversees the whole thing.
One exemption exists. The U.S. Attorney General can issue a written determination that immediate disclosure poses a substantial national security or public safety risk. That is for nation-state attacks on critical infrastructure. Ordinary ransomware and credential theft do not qualify.
What "material" means in practice
The SEC reuses the materiality standard from securities law: information is material if a reasonable investor would substantially likely consider it important to an investment decision. The standard is vague on purpose.
The guidance lists factors. Impact on financial condition, operations, customer and vendor relationships, reputation, and data sensitivity. It refuses to draw a bright line. A $100 million company losing customer PII may be material. A $50 billion company suffering the same loss may not be.
Most determinations turn on operational impact. An incident that takes revenue systems down, halts a production line, or exposes data that triggers regulatory penalties is probably over the line. A contained endpoint compromise with no data loss is probably not.
Every one of those calls assumes you know what happened. Not which alerts fired. Not what the attacker's toolkit could theoretically do. What they reached, what they moved, what they broke.
The detection gap that becomes legal exposure
Security stacks are built to catch threats, not to answer forensic questions against a deadline. The EDR caught the malware. The firewall logged the beaconing. The SIEM correlated a few events. Turning that into "here is every file the attacker touched" is manual reconstruction, and reconstruction runs in weeks, not days.
Three scenarios make the gap legally expensive.
Lateral movement after a foothold. An attacker spends 48 hours walking from a compromised workstation to your database servers. The alerts show the entry and a few scans. You have four days to determine whether customer data, financial records, or source code left. Log aggregation hands you the what (these connections happened) and withholds the why (these specific tables got pulled).
The vendor breach. Your SaaS provider tells you they were compromised and your data may have been accessed. Their environment is dark to you. Your own logs show API calls but not what those calls returned. The four-day clock runs while you guess at materiality with half the picture.
The insider. An engineer with legitimate database access runs queries off their usual pattern. A routine audit surfaces it three weeks later. So when did the incident happen, when they ran the queries or when you noticed? The SEC wants monitoring good enough to catch a material incident "without unreasonable delay," and three weeks is not that.
Where data movement governance changes the math
The four-day timeline is survivable for one reason: you are not asked to prove a negative. You do not have to show what the attacker did not touch. You have to establish what they did. That means watching the data move as it moves, not piecing it together afterward from logs that never agreed with each other.
That is the job of data movement governance. One lightweight collector watches data movement at the kernel, metadata only by default, off the path. It never sits inline and it never blocks traffic. It resolves each move to a probabilistic, source-dependent identity: which process, which job, which user, which destination. The lateral movement is on the record as it happens, attributed to the process chain behind it, not inferred a month later from what some toolkit suggests was possible.
The vendor breach reads the same way from your side. Their environment stays dark, but your own record shows which endpoints your systems called and what moved through each one. If the record shows you only ever pulled non-sensitive product data, never customer PII, your materiality determination rests on a fact instead of a hope.
The insider case is where the framing matters most. The signal is not one query. Each query is permitted. The danger is the shape of them together. At runtime, the collector shows how this run departed from the engineer's normal pattern and the role's expected behavior. The engineer who queries 100 rows on a normal day suddenly pulls 100,000, and the anomalous pattern surfaces as it forms, not in next quarter's audit. Content-aware inspection is there when you want it, but the pattern usually reads from metadata alone, so you act without reading your data.
Cost decides where this can run. A collector at roughly 0.1% of a core and 4 to 8 MB of memory, off the path, adds no meaningful delay, so it rides the production databases and revenue-critical workloads that heavier agents are kept off. When the pattern crosses the line, the response is host-level network isolation: quarantine the host at the network from the control plane, never inline. A four-day deadline needs coverage on the systems where materiality is actually decided, not just the perimeter.
The annual filing has to match the eight-K
Item 106 forces you to describe your cyber risk process in writing. Not a maturity scorecard. A narrative: how you spot threats, how you triage them, how you know a control works, and who on the board owns the decision. Incidents that fell short of the 8-K bar get disclosed here in aggregate.
The SEC wants specifics. Not "we use industry-standard tools" but which systems you monitor, which threat categories you catch, and which thresholds escalate to the board.
Here is the trap. Your 10-K claims "comprehensive monitoring across all critical systems." Then an 8-K shows you missed an incident for two weeks. The SEC reads both filings, and now you are explaining the gap between them. The annual story has to match the actual capability.
Run a legacy stack and the choice narrows to overstating coverage (legal risk) or confessing the gap (investor risk). The honest version names the limit, then names the compensating control and the fix. That paragraph writes itself when the fix is concrete: runtime visibility into data movement on the workloads and endpoints where the materiality questions get answered.
The rules do not demand perfect security. They demand honest, timely disclosure off a reasonable investigation. The bottleneck is not legal interpretation or compliance process. It is whether you can say what data moved before the clock runs out. Predictive tools guess early and still wave the permitted move through. Detection and response tell you once it is gone. Governing data movement at runtime is the third path, and it puts the move on the record as it forms, which is the one thing a four-day materiality call depends on. If that is the gap you are staring at, a 30-minute technical call is enough to see whether it closes yours.