The first 24 hours of an incident are decided before it starts

In a serious cyber incident, the first 24 hours rarely fail on technology. They fail on questions nobody answered in advance: who may declare an incident, who may shut down a production system, who calls the insurer, who speaks to the regulator. Incident response for boards is mostly about these decisions, and most of them can be made today, in a quiet meeting room.

The regulators have shortened the time available. For listed companies in the US, the SEC expects a Form 8-K within 4 business days after the company determines that an incident is material. In Asia-Pacific the windows for critical infrastructure are even shorter: 2 hours in Singapore, 12 hours for serious incidents in Hong Kong and Australia. All of these clocks start while the picture is still incomplete.

The regulatory clock starts with awareness, not with certainty

The SEC rule is the reference point for US listed companies. Item 1.05 of Form 8-K is generally due 4 business days after the company determines that a cybersecurity incident is material. The clock starts with that determination, not with the incident itself. Someone has to make the materiality call, quickly and documented.

In Asia-Pacific, the clocks for critical infrastructure run in hours. In Singapore, owners of critical information infrastructure (CII) must report prescribed incidents to the Cyber Security Agency within 2 hours of becoming aware. Since October 31, 2025, this also covers incidents suspected of being caused by advanced persistent threats.

Hong Kong’s Protection of Critical Infrastructures (Computer Systems) Ordinance has applied since January 1, 2026. Designated operators notify the Commissioner within 12 hours of becoming aware of a serious incident and within 48 hours for other incidents. In Australia, responsible entities for critical infrastructure assets report a cyber incident with significant impact within 12 hours and an incident with relevant impact within 72 hours. Separately, Australian businesses with annual turnover above AUD 3 million must report a ransomware payment within 72 hours of making it.

The EU follows the same pattern. Under NIS2, the early warning for a significant incident is due within 24 hours of becoming aware. What all these regimes share is the trigger: awareness or a determination, not proof of impact. None of them waits for the forensic report.

The SEC also makes this a board topic. Under Item 106 of Regulation S-K, companies describe in their annual Form 10-K how the board oversees cybersecurity risk and what role and expertise management has in assessing and managing it. The response plan should show that this oversight works in the first hours.

Incident response for boards comes down to 5 decisions

In practice, the first hours of a serious incident come down to 5 decisions. First, is this an incident, and how severe is it? Second, which systems, accounts or sites are isolated? Third, which outside parties are called in: incident response firm, insurer, external counsel? Fourth, which authorities are notified, and when? Fifth, what do customers, employees and partners hear, and from whom?

None of these is a technical question. IT supplies the facts. Management carries the consequences: lost revenue during isolation, contractual exposure, disclosure obligations, reputational damage. That is why each decision needs an owner from management, a deputy, and a threshold that triggers it.

NIST makes the same point in a more formal way. Its revised incident response guidance, SP 800-61 Rev. 3 from April 2025, places incident response inside overall cybersecurity risk management under CSF 2.0, including the Govern function. Incident response is no longer described as an IT process that starts with the first alert.

Isolation is a business decision. IT only executes it.

Isolation is the decision that costs the most and is prepared the least. Disconnecting a site, disabling VPN access for all users or shutting down an ERP system can stop an attacker. It also stops invoicing, production or delivery.

In a typical environment, the on-call engineer at 3 a.m. sees the encryption activity first. That engineer should not have to decide alone whether to take the warehouse system offline. Equally, nobody should wait 4 hours for a board member who cannot be reached.

The answer is a pre-agreed matrix: which systems IT may isolate immediately, which need a call with the CIO or COO, and which need a management decision. Write it down per system, with the business owner’s signature. Then evidence preservation, such as memory images and log exports, belongs into the same runbook, because isolation without preserved evidence makes the investigation harder later.

Someone must be allowed to declare an incident at 3 a.m.

Many response plans name a crisis team but not the person who may activate it. The result is a delay of hours, while people ask whether the situation is serious enough to wake up the CEO.

A workable rule names 2 or 3 roles that may declare an incident on their own authority, for example the CISO, the head of IT operations and the managed security provider on duty. Over-declaring is cheap: a false alarm costs a few hours. Under-declaring is expensive, because a reporting clock may already be running.

The plan also needs a communication channel outside the affected environment. If the attacker has taken over an identity with access to Exchange Online or Teams, the crisis team should not coordinate in Teams. Out-of-band means a separate channel with separate accounts and a contact list that also exists on paper.

Logs you do not keep today will not exist tomorrow

Every investigation starts with the same question: since when has the attacker been inside? The answer depends on logs, and many organisations find out during the incident that they do not have them.

Microsoft Entra ID retains sign-in and audit logs for 7 days on the Free tier and 30 days with P1 or P2. Attackers often stay in an environment far longer before they act. Data that has already expired cannot be restored by upgrading the licence later. The only fix is to export the logs to a storage account, Log Analytics or a SIEM before you need them.

The same logic applies to firewalls, endpoints and backup systems. Retention is a decision with a price tag, and it should be made by someone who understands what an investigation needs, not by the default value of a product.

What to do now

1. Board: name the owner and deputy for each of the 5 decisions: declaration, isolation, outside help, notification and communication. Record it in the incident response plan and review it once a year.
2. CIO and business owners: build the isolation matrix per critical system. State which systems IT may isolate immediately and which need a management call.
3. CISO: name the roles that may declare an incident on their own, and set up an out-of-band channel with separate accounts and a printed contact list.
4. IT Operations: export Entra ID sign-in and audit logs and other security-relevant logs to long-term storage. Define retention based on investigation needs, not product defaults.
5. CFO and counsel: sign the retainer with an incident response firm and confirm with the insurer which firms are accepted under the policy, before you need them.

When we take over operations for a client, the response plan is one of the first documents we read, and the decision matrix is part of the handover. Our agents watch for signals around the clock and preserve evidence immediately, and a senior partner is on call to brief management and work through the decisions with them. More on this under Security and Incident Response, and for organisations without a CIO under Fractional CIO. Agent identities belong into the same plan, see our field guide on Entra Agent ID.