What should teams do first when a cyber incident may be material?

What teams should do before deciding whether an incident is material

Start with a formal materiality workflow, not an ad hoc severity call. The first task is to assemble the people who can judge operational facts and disclosure impact together, then build a shared timeline of what happened, what was affected and whether the event could matter to investors or other reporting thresholds. That keeps the assessment anchored to the right standard from the outset.

Teams should also lock down the working record immediately. Preserve logs, timestamps, alert history, ticketing records and forensic artifacts before they roll over or are altered by cleanup activity. If the incident may involve disclosure obligations, this evidence becomes part of the decision trail, not just the technical investigation.

For the incident handling side of that workflow, use a structured response path rather than improvising under pressure. NHIMG’s Incident Response Guide is useful here because it ties the first-hour response to roles, containment, evidence retention and reporting deadlines. That sequence helps teams avoid treating materiality as a separate legal exercise detached from response operations.

Why materiality is a disclosure question, not just an incident-severity question

Materiality turns on the effect of the event, not only the technical size of the intrusion. A small but sensitive compromise can still be material if it affects business operations, financial reporting, customer trust, regulated data or the company’s public disclosures. The practical question is whether the facts, if known, could change an investor’s view of the business or its risk profile.

That is why legal, finance, security and incident response need to work from the same facts. Security can describe scope and containment, finance can judge reporting implications, legal can interpret disclosure thresholds and incident response can preserve the evidence that supports both. If those functions work separately, teams often end up with inconsistent timelines and an assessment that is too focused on internal severity.

For boards and executives, NHIMG’s Cyber Incident Readiness Executive Briefing is a good companion because it frames decision rights, disclosure clocks and the questions leaders need answered early. It reinforces that the first judgment is not “how bad does this feel”, but “what facts are known, what remains uncertain and what deadlines are already running”.

What good early assessment looks like in practice

The strongest early assessment is evidence-led and decision-oriented. It identifies the affected systems, the data or business processes involved, the likely onset of the incident, the containment status and the point at which disclosure analysis can start. It also records unresolved questions, because uncertainty itself may affect whether escalation is warranted.

Teams should avoid the common mistake of waiting for full root-cause analysis before starting the materiality review. In many incidents, the relevant question is not whether every technical detail is known, but whether enough is known to judge reporting significance and preserve the ability to explain the event later. That means the assessment should start while forensics continue, not after they finish.

NHIMG’s SEC Cyber Disclosure Executive Briefing and SEC Cybersecurity Disclosure Rules Guide both support this early-stage discipline by linking incident facts to materiality, disclosure governance and board oversight. They are useful references when a team needs to translate technical findings into a defensible reporting decision.

Risk and Threat Considerations

The main risk is losing evidentiary integrity or making a disclosure decision on incomplete facts. If logs are overwritten, timestamps are not preserved or the response team changes systems before the record is secured, it becomes much harder to prove what happened, when it happened and whether the event met the relevant threshold.

Failure mechanism: Teams treat the event as a technical outage first, then discover later that the record needed to support legal and disclosure analysis was degraded, fragmented or never captured in a defensible way.

Impact: That can lead to late escalation, inconsistent reporting positions, weak board oversight and avoidable exposure if the incident later proves to be material.

Practitioner Guidance

What to prioritise: Establish a single incident fact set before debating disclosure. The first working group should confirm timeline, affected assets, data exposure, containment status and whether external reporting clocks may already be relevant.

What to verify: Make sure logs, endpoint artifacts, cloud audit trails and analyst notes are preserved in a way that supports later review. If the evidence chain is weak, treat that as a response problem, not just a forensics problem.

Decision rule: If there is any plausible path from the incident to investor-facing disclosure, move the matter into formal materiality review immediately rather than waiting for complete technical certainty.

Practitioner takeaway: The first move is to align the incident record with the disclosure question, because response speed matters less than preserving a defensible assessment path.

Related resources from NHI Mgmt Group

• Cyber Incident
• Who is accountable for determining whether a cyber incident is material under the SEC rule?
• Who is accountable for determining whether a cyber incident is material enough to report?
• What breaks when a company tries to report a material cyber incident without defined disclosure workflows?