SEC Item 1.05 in Practice: Engineering the ‘Material Cyber Incident’ Determination

The four-business-day clock in SEC Item 1.05 does not start when you detect a cyber incident. It starts when you decide the incident is material — and that decision is the artefact a regulator will reconstruct after the fact.

Most writing on the SEC’s cybersecurity disclosure rule treats it as a filing deadline problem. It is not. The filing is the easy part. The hard part is the judgment that precedes it: the moment your firm decides that a given incident is material, because that moment is what arms the clock. Get the determination process wrong and you are exposed on both sides — filing too early on immaterial noise, or filing late because nobody can say when the determination was actually made. The engineering task is to make that determination timely, reconstructable and defensible, rather than improvised under enforcement scrutiny months later.

What the rule actually pins the clock to

The SEC adopted the rule in July 2023. Item 1.05 of Form 8-K requires a registrant that experiences a cybersecurity incident it has determined to be material to file within four business days of that materiality determination. The disclosure must describe the material aspects of the nature, scope and timing of the incident, and its material impact or reasonably likely material impact, including on the registrant’s financial condition and results of operations. You may withhold specific technical detail about your response or your systems.

Two phrases carry the whole engineering burden. The first is that the clock runs from the determination, not from detection or discovery. The second is the constraint on the determination itself: the rule requires it to be made “without unreasonable delay” after discovery of the incident. You cannot stop the clock by simply declining to decide. A firm that sits on a plainly serious incident for three weeks “investigating” before formally determining materiality has not been careful — it has unreasonably delayed the determination, which is itself the violation. The design has to hold both timeliness of the decision and defensibility of the decision at once.

Compliance dates are worth stating plainly because firms still get them wrong: non-smaller-reporting companies came into scope on 18 December 2023, and smaller reporting companies from 15 June 2024. There is no exemption tier below that; the smallest in-scope registrant runs the same determination discipline as the largest.

The workflow is a state machine, not a meeting

In most firms the materiality call is a conversation — legal, security and finance in a room, a decision reached, and if you are lucky an email that half-records it. That is exactly the artefact that falls apart under examination. Nobody can say when discovery occurred, when the assessment started, what facts were in front of the deciders, who actually decided, or when. The reconstruction the SEC’s enforcement staff will attempt is the reconstruction you failed to make.

Model the process as a state machine with a small, fixed set of states and an append-only log of transitions between them. An incident moves from detected, to under assessment, to a terminal state of either determined material or determined not material (with a path to re-open on new facts). Each transition writes an immutable record: who, when, on what facts, against which criteria. The determination is not a paragraph in a minute; it is a state transition with a timestamp you did not control after the fact.

This is where an honest incident taxonomy matters, because a single “incident” is often several related occurrences that the rule expects you to consider in aggregate. If your data model cannot bind related events into one assessable unit, your materiality call is being made on a fragment. I have written separately on how aggregating related occurrences breaks most incident taxonomies; the determination workflow inherits that problem directly.

A decision-log schema with immutable timestamps

The core control is an append-only, hash-chained decision log. Each record references the previous record’s hash, so any later edit to the timeline is detectable. This is what turns “we think we decided around then” into evidence.

from datetime import datetime, timezone
from hashlib import sha256
import json

# Fixed states for the determination state machine.
STATES = {"detected", "under_assessment",
          "determined_material", "determined_not_material"}

def record(prev_hash, incident_id, from_state, to_state,
           actor, facts, criteria):
    """Append one immutable transition to the determination log.
    The 8-K clock starts at the transition to determined_material."""
    if to_state not in STATES:
        raise ValueError(f"unknown state: {to_state}")
    entry = {
        "incident_id": incident_id,
        "from_state": from_state,
        "to_state": to_state,
        # Server-side UTC timestamp; never client-supplied.
        "decided_at": datetime.now(timezone.utc).isoformat(),
        "actor": actor,                 # named decision-maker
        "facts_known": facts,           # facts in front of the decider
        "criteria_applied": criteria,   # materiality test applied
        "prev_hash": prev_hash,
    }
    # Canonical serialisation so the hash is reproducible.
    body = json.dumps(entry, sort_keys=True, separators=(",", ":"))
    entry["hash"] = sha256((prev_hash + body).encode()).hexdigest()
    return entry

# Transition that arms the four-business-day filing clock.
determination = record(
    prev_hash="...",
    incident_id="INC-2026-0042",
    from_state="under_assessment",
    to_state="determined_material",
    actor="disclosure_committee",
    facts=["data exfiltration confirmed", "customer PII in scope"],
    criteria=["reasonable investor total mix",
              "financial condition / results impact"],
)
print(determination["decided_at"])  # start of the Item 1.05 clock

The schema is deliberately thin. What makes it defensible is not the field count but three properties: timestamps are server-generated in UTC and never client-supplied; the criteria_applied field forces the decider to record the materiality test used rather than a bare verdict; and the hash chain makes the sequence tamper-evident. Persist the log in append-only storage — write-once object storage or a database with row-level immutability — so “immutable” is enforced by the platform, not by policy.

The handoffs that actually get missed

Two seams cause most of the failures. The first is discovery-to-assessment. If your SOC ticketing system and your disclosure process are not wired together, discovery time is recorded in one system and the materiality assessment starts, untimed, somewhere else — and the “without unreasonable delay” gap becomes unmeasurable. The transition from detected to under_assessment has to be an automated, timestamped event, not a human remembering to loop in legal.

The second is the national-security delay path. The rule permits deferral only where the US Attorney General notifies the SEC in writing that disclosure poses a substantial risk to national security or public safety — initially up to 30 days, extendable by a further 30, and in extraordinary circumstances a final 60. This is a narrow, government-initiated exception, not a self-service pause button. Your workflow should model it as a distinct, separately evidenced state, so nobody confuses “we are still investigating” with a lawful delay.

It is also worth designing the determination once and reusing it, because the same incident frequently trips reporting duties under several regimes at different clock speeds. A firm operating across jurisdictions is often reasoning about the SEC, sectoral and EU obligations from the same facts — the reason we maintain a board-level cyber-incident reporting map — and the incident-reporting discipline European financial entities have built for DORA classification and reporting is the same muscle, aimed at a different deadline.

What a supervisor will ask you to produce

When the questions come, they are specific. When did you discover it. When did you start assessing materiality. What facts did you have at that point. Who decided, and when. What test did they apply. Why the gap between discovery and determination was reasonable. If your answer to every one of those is a single query against an immutable log, you are in a defensible position. If the answer is a reconstructed narrative assembled after the enforcement letter arrives, the process failed before the incident ever happened.

The determination is the disclosure. Build it so the decision can be read back cleanly, or you will be explaining, under oath, why it cannot.