The SEC Cyber Disclosure Controls Gap: Wiring IR Into Disclosure Controls and Procedures

SEC Item 1.05 rarely fails on the legal drafting. It fails at the seam — the handover between the people who see the incident and the people who decide whether it is material. That seam is a governance artefact the board owns, and most boards have never looked at it.

The rule itself is short. Since it came into force, a registrant that determines a cybersecurity incident is material must file a Form 8-K under Item 1.05 within four business days, describing the material aspects of the nature, scope and timing of the incident and its material impact or reasonably likely material impact. The materiality determination must be made “without unreasonable delay” after discovery. Read those two sentences carefully and the real obligation appears: it is not the filing. It is the machinery that gets an incident from a security operations centre analyst’s screen to a disclosure committee’s agenda fast enough, and with enough context, to make a defensible materiality call on the clock. That machinery is what firms do not have.

The clock does not start where people think it starts

The four business days run from the determination of materiality, not from discovery of the incident. This is the detail every vendor briefing gets right and every operating model gets wrong. It sounds like breathing room. It is the opposite. The SEC paired the four-day filing window with the requirement that the materiality determination be made without unreasonable delay, precisely so that firms could not park an incident in triage indefinitely to stop the clock. So the governance question is not “can we file within four days” — almost any firm can draft an 8-K in four days. The question is: how long does it take you to reach the point where a qualified person is even in a position to determine materiality? If your answer is “it depends who is on shift and whether they thought to escalate,” you do not have a control. You have a hope.

Between detection and determination sit a series of handovers, and each one is a place the incident can stall. The SOC sees anomalous activity. Someone has to decide it is an incident rather than noise. Someone has to decide it is significant enough to escalate beyond the security team. Someone has to loop in legal and the disclosure function. Someone has to assemble the facts — scope, data affected, systems touched, likely financial and operational impact — that a materiality assessment actually needs. Only then can the determination be made. Every one of those steps has an owner, or it has no owner, and “no owner” is where the four-day clock quietly starts running against you before anyone senior knows there is an incident at all.

This is a disclosure controls problem, not a security problem

Public companies already maintain disclosure controls and procedures — the controls that ensure information required to be disclosed is recorded, processed and reported within the required timeframes, and escalated to the people who certify the filings. Cyber incident information is now, unambiguously, information of that kind. The engineering consequence is direct: the incident response runbook and the disclosure controls framework have to be the same system, not two documents owned by two functions that meet for the first time during an actual breach.

In practice they are almost never wired together. Incident response lives with the CISO and reads like an engineering document — containment, eradication, recovery. Disclosure controls live with the general counsel and the CFO and read like a securities document. Neither references the other. There is no defined trigger that says: an incident classified at this severity is automatically referred to the disclosure committee within this many hours, with this information package attached. So when a real incident lands, the escalation happens by relationship and instinct rather than by design, and the quality of your Item 1.05 response depends on whether the right people happened to know to phone each other. That is the gap. It is not a gap in either function. It is the missing wire between them, and closing it is squarely a disclosure-controls design exercise rather than a security upgrade.

What the board should demand to see

A director does not need to read the SOC’s playbook. A director needs to be able to ask five questions and get concrete answers, not reassurances.

1. Show me the escalation path, as a document. A single named route from incident detection to a materiality decision, with each step’s owner identified by role. If it exists only as tribal knowledge, it does not exist.
2. Show me the SLAs on each step. How many hours from classification to disclosure-committee referral? The absence of a defined interval is the finding. “As soon as possible” is not an SLA and will not survive an enforcement inquiry.
3. Who owns the materiality determination, and who is their backstop? A named accountable person and an alternate, because incidents do not wait for someone to return from leave.
4. What information package reaches that person, and who assembles it? A materiality call needs facts on scope, data, systems and likely impact. Define the template and its owner in advance, or the determination stalls while people gather the basics.
5. How do we handle related incidents that are individually immaterial but material in aggregate? The rule expects registrants to consider a series of related occurrences together, which breaks most incident taxonomies because they were never built to aggregate across time.

If those five answers exist and cohere, the firm is defensible. If they do not, the annual Regulation S-K Item 106 disclosure — which requires describing the processes for assessing, identifying and managing material cybersecurity risks and the board’s oversight of them — is describing a process the firm does not actually operate. That is the more dangerous exposure, because it is asserted in a periodic filing every year, not just when an incident happens to occur.

The wiring is measurable, so measure it

The good news for a technology-literate board is that this is instrumentable. Time-to-escalate and time-to-materiality-determination are metrics like any other operational latency; the same discipline that lets a firm instrument its delivery pipeline applies to the disclosure pipeline. Run the tabletop exercise, put a stopwatch on each handover, and the seam reveals itself — usually as one step with no owner and no clock, where the incident sat for two days while people worked out who to tell. Fix that step, and Item 1.05 stops being a compliance risk and becomes a process you can evidence.

The firms that will be caught out are not the ones that suffer a breach. Every firm will. They are the ones who discover, at the worst possible moment, that nobody had ever been made accountable for moving the incident across the gap between the people who saw it and the people who had to disclose it.