Four breach clocks, and the one you budgeted for is not running

We read a lot of incident-response plans, usually because somebody has asked us to test one. A striking number of them contain the same sentence, in slightly different words: in the event of a significant cyber incident, the company will report to CISA within 72 hours. It is written with confidence, it is often the only deadline in the document, and it is describing a rule that has never taken effect.

The 72-hour figure comes from the Cyber Incident Reporting for Critical Infrastructure Act of 2022. The Act is real and the number is real. But the obligation it creates does not exist until a final rule implements it, and there is no final rule. CISA's own CIRCIA page (opens in a new tab) published the proposed rule on April 4, 2024, took comments until July 3 that year, and as of this writing still says that covered incident and ransom payment reporting “will not be required until the CIRCIA final rule goes into effect.” No effective date has been announced. The page attributes part of the delay to funding lapses.

We are not saying the plan is wrong to anticipate it. We are saying that a plan whose only named deadline is one that is not running has not been tested against the deadlines that are, and that is the condition we keep finding. The exercise that reveals it takes about twenty minutes: ask which clock starts first for this company, and watch the room discover that nobody has separated the four.

The clock that binds public companies¶

If you file with the SEC, the live obligation is Item 1.05 of Form 8-K (opens in a new tab), and the detail that matters is where the clock starts. The filing is due within four business days of the registrant determining that a cybersecurity incident is material, not within four days of discovering it, and not within four days of containing it. The determination itself must be made “without unreasonable delay,” which is the clause that stops the first half from being a loophole.

That structure is frequently misread in both directions. Read one way it becomes an excuse to defer a determination indefinitely; read the other way it becomes a four-day deadline from discovery, which is stricter than the rule and produces filings about incidents nobody has finished understanding. Both readings cause real damage, and the second one is the one that gets a company into print about an event that turned out to be nothing.

The SEC has said so itself. In a May 2024 statement from the Director of the Division of Corporation Finance (opens in a new tab), the Division encouraged companies to disclose incidents that are not material, or whose materiality has not yet been determined, under Item 8.01 instead, precisely so that an Item 1.05 filing keeps meaning what it says. A company filing under 8.01 while it works out materiality is following guidance, not dodging a rule. It is worth having read that statement before the week you need it, because the instinct in the room will be that any filing under a different item looks evasive.

The clock that binds defense suppliers¶

If you hold a contract with the defense flow-down, DFARS 252.204-7012 (opens in a new tab) has required reporting within 72 hours of discovery for years. This is the genuine 72-hour rule, it is in force, and it is narrower than the one people quote: it attaches to covered defense information and to the contract, not to critical infrastructure at large. If you are quoting 72 hours because of this clause, you are right. If you are quoting it because of CIRCIA, you have the right number for the wrong reason, and the scope you have written down is wrong.

The two clocks that bind almost everybody¶

For the mid-market manufacturer, utility contractor or clinic that most of this writing is addressed to, neither of the above applies, and the plan citing CIRCIA has therefore named no applicable deadline at all. The two that do apply are less glamorous and considerably less forgiving.

The first is state breach notification law. Every state has one, you are subject to the law of the state where the affected person lives rather than where you operate, and the trigger is not intrusion. It is unauthorized acquisition of defined categories of personal information. That distinction decides more incidents than any other single fact: a ransomware event that encrypts a plant historian and touches no personal data may trigger nothing, and a lost laptop with an HR spreadsheet on it may trigger notifications in eleven states.

The second is your own customer contracts, and it is the one we find unread most often. Master service agreements routinely carry notification clauses, and they are frequently shorter than any regulator's: 24 hours is common, immediately upon becoming aware appears more than it should, and the definition of the triggering event is usually broader than a statute would allow, because it was drafted by a customer with no interest in narrowing it. Nobody in the security function typically has a copy.

Why this is an engineering problem¶

All four live clocks share a structure. Each starts on a determination: that an incident is material, that covered information was involved, that personal data was acquired, that the customer's defined event occurred. None of them starts on a feeling. And a determination is a claim about what happened, which means it is a claim about evidence.

This is where a notification deadline stops being a legal question and becomes a logging one. NIST's incident response guidance (opens in a new tab) puts the preparation phase first for this reason. If you cannot establish which records were accessed, you cannot determine whether personal data was acquired, and the state clock does not start, which sounds like relief and is not, because the regulator's position will be that a reasonable investigation would have established it. The absence of evidence is not a defense; it is the finding.

We have written separately about why forensic readiness is a build decision rather than an incident-response one. The short version is that the questions asked after an incident are answerable only if somebody made specific logging decisions months earlier, and that almost nobody makes them, because they cost money in a quarter when nothing has happened.

The test¶

One question, and it is worth asking at a table with the general counsel present rather than in the security function alone. For this company, name the four: which statute, which regulator, which contracts, and what event starts each clock. Then name, for each one, the system that would produce the evidence to make that determination, and say when it was last checked.

Most organizations get through the first half and stop cold at the second. That is a useful place to stop, because it is the point at which the conversation moves from writing a policy to changing a system, and it is much cheaper to arrive there deliberately than at two in the morning with a lawyer on the phone.

What this piece is not: legal advice, and not a substitute for counsel reading your actual contracts. The mapping above is the engineering half of the problem: which systems must produce which evidence, by when. Which obligations attach to your entity is a question for a lawyer, and any consultant who tells you otherwise is selling you something they cannot deliver.