Public companies must disclose material cybersecurity incidents and describe their cybersecurity risk management, strategy and governance in periodic filings. The headline requirement is disclosure within four business days.

The deadline gets the attention. In practice, the four days is the easy part. The hard part is the judgement that starts the clock.

When the clock starts

The four business days run from the point at which the company determines an incident is material — not from discovery of the incident itself. That distinction gives companies room to investigate before disclosing, which is necessary: a premature disclosure based on an incomplete picture serves nobody.

It is not unlimited room. The materiality determination must be made without unreasonable delay. A company that discovers an incident and takes six weeks to reach a conclusion will struggle to defend that timeline, particularly if internal documents show the answer was evident much earlier.

The defensible position is a documented, reasonably paced assessment process — not a fast answer, and not a slow one, but an evidenced one.

What materiality actually means

Materiality in securities law turns on whether a reasonable investor would consider the information important. That is broader than a financial threshold, and the qualitative dimension is where teams most often misjudge.

Quantitative factors include direct response costs, remediation, legal exposure, regulatory penalties, lost revenue from disruption and the effect on future earnings.

Qualitative factors carry real weight and are easy to underweight:

  • Harm to reputation and customer relationships.
  • Impact on business operations and the ability to deliver.
  • The nature and sensitivity of compromised data.
  • Whether the incident indicates a systemic weakness in controls.
  • Competitive harm from stolen intellectual property.
  • Litigation and regulatory follow-on risk.

An incident with negligible direct cost can still be material if it reveals a governance failure or exposes highly sensitive information. Conversely, an expensive but well-contained incident in a non-core system may not be.

Building the process before you need it

The most common failure is treating materiality as something to work out during an incident. It needs a standing process:

A defined committee with defined authority

Typically the CISO or equivalent, the General Counsel, the CFO and a senior business leader, with a clear escalation path to the board. Named individuals with named alternates — incidents do not respect holiday schedules.

Documented criteria

Written factors the committee will consider, so the assessment is consistent and defensible. This is not a formula that produces an answer; it is a framework that produces a record of reasoned judgement.

A clear trigger for convening

What level of incident brings the committee together? Set this deliberately — too high and you miss the clock, too low and the committee stops taking it seriously.

Contemporaneous documentation

Record what was known, when it was known, what was decided and on what basis. If a determination is later questioned, this record is the entire defence. Reconstructing it afterwards is both harder and less credible.

Pre-drafted disclosure language

A skeleton 8-K that can be completed quickly. Four business days is not long when it includes legal review, executive approval and coordination with the ongoing response.

The annual disclosure is the underrated half

Alongside incident reporting, companies must describe their cybersecurity risk management processes, strategy and governance in annual filings. This gets far less attention than the four-day rule, and it is arguably more consequential.

Incident disclosures are read under time pressure. The annual governance disclosure is read carefully, at leisure, by regulators, plaintiffs' lawyers, insurers and investors — and it is compared against what actually happens when you have an incident.

A company that describes a mature programme in its 10-K and then demonstrably fails to follow it during an incident has created a problem larger than the incident. Whatever you write should be accurate, specific enough to be meaningful, and something you can evidence.

Where security and legal have to align

The recurring friction: security teams want to withhold detail that could aid attackers or compromise an ongoing investigation; disclosure obligations push toward transparency.

The workable resolution is that disclosure should describe impact, not architecture. Investors need to understand the effect on the business. They do not need the specific vulnerability exploited, the systems involved or the state of remediation. Establish that principle in advance, with legal, rather than arguing it in hour thirty of a live incident.