The First 24 Hours of a Serious Cyber Incident

What you will know, and what you will not

Early in a serious incident, the facts are thin. You will usually know that something is wrong, that some systems or accounts are affected, and that the business is feeling it. You will usually not know how the attacker got in, how long they have been there, what they have taken or whether they still have access.

The CISA federal incident response playbook is explicit that scope is updated as new information emerges. Treat early scope statements as working hypotheses. Ask your incident lead for two things every time they brief you: what is confirmed, and how confident they are in the rest.

The first day in three blocks

The decisions that cannot wait

Any contact with an attacker, including a decision on whether to engage, should involve legal counsel first. It is not a decision to make under the pressure of a countdown timer, and it should not be made by default.

The clocks that may start

Legal and contractual deadlines often begin before the technical picture is clear. Two examples show the pattern. Whether either applies to your organization depends on what you are, where you operate and what data is involved. Your counsel decides that.

• EU General Data Protection Regulation, Article 33. A controller must notify the competent supervisory authority of a personal data breach without undue delay and, where feasible, not later than 72 hours after becoming aware of it. Notification is not required where the breach is unlikely to result in a risk to the rights and freedoms of individuals. If notice goes beyond 72 hours, it must explain the delay. A processor must tell the controller without undue delay.

• US Securities and Exchange Commission, Form 8-K Item 1.05. A registrant must disclose a material cybersecurity incident within four business days of determining that it is material. The determination itself must be made without unreasonable delay, and the SEC release states that a company may not delay it to avoid the disclosure obligation. A delay is available only if the US Attorney General determines that disclosure poses a substantial national security or public safety risk.

Notice that the starting points differ: awareness in one case, a materiality determination in the other. Other national and sector regulators, customer contracts and insurance policies set their own deadlines and triggers. Keep a single register of every clock that may apply, with its trigger, its owner and its status, and have counsel confirm it.

Five mistakes that are hard to undo

1. Wiping before capturing. Reimaging or rebuilding a system destroys what you need to understand the attack. The CISA playbook calls for memory and disk images when an endpoint needs forensic analysis, and for a log of how and when each item of evidence was acquired and by whom.

2. Coordinating over compromised channels. If email or chat may be compromised, the attacker may be reading your plans. The same playbook places out-of-band communication in preparation and recommends, for example, notifying users of affected machines by phone rather than email.

3. Evicting too early. Removing the attacker before you know how they persist invites a return. CISA advises confirming that all means of persistent access are accounted for, that activity is sufficiently contained and that evidence is collected before eradication starts. It also notes that some adversaries watch defensive actions and change tactics.

4. Speaking before the facts are firm. An early public statement that names a cause or a scope can be wrong, and a correction is costly. State what is confirmed, what is not yet known and when the next update will come.

5. Delaying the assessment to avoid the answer. Postponing a materiality or notification decision does not stop a clock from mattering. The SEC release says so directly for materiality determinations.

What good looks like at hour 24

• One person leads the response, and everyone knows who it is.

• A scope hypothesis exists, written down, with confidence stated.

• Containment actions are logged, with who approved them and why.

• Evidence has been preserved, and its handling is recorded.

• The team is communicating on channels the attacker cannot read.

• A register of notification clocks exists and has an owner.

• Affected business services have named owners and an interim plan.

• The next decision points are scheduled, with times.

Questions to ask at hour 24

6. What do we know for certain, what do we believe, and what are we guessing?

7. What have we changed on affected systems, and what evidence did we preserve first?

8. What could the attacker still be doing, and how would we know?

9. Which deadlines have started, and who is tracking each one?

10. What are we telling staff, customers and regulators, and is every statement verified?

11. What decision do we face in the next four hours, and who makes it?

Most of this is cheaper before the incident

Almost every decision above is easier when authority, contacts, thresholds and escalation paths are agreed in advance. NIST’s current incident response guidance, SP 800-61 Revision 3, frames incident response as part of cybersecurity risk management, aligned to the NIST Cybersecurity Framework 2.0, and not as a separate technical function. Leadership teams that have rehearsed these calls together tend to find the gaps in authority and information when it costs little to fix them.

What to do next

Ask your incident lead to walk your leadership team through these six decisions against your own organization: who decides, what they would need to know, and how long it would take today. The gaps are your readiness agenda. If you want an independent view of incident readiness and response decision-making, Cybrilliant works with leadership teams on readiness reviews and decision exercises.

Sources

• Federal Government Cybersecurity Incident and Vulnerability Response Playbooks. Cybersecurity and Infrastructure Security Agency (CISA). https://www.cisa.gov/resources-tools/resources/federal-government-cybersecurity-incident-and-vulnerability-response-playbooks

• General Data Protection Regulation (GDPR), Article 33: Notification of a personal data breach to the supervisory authority. European Union. https://gdpr-info.eu/art-33-gdpr/

• Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure, Final Rule, Release No. 33-11216. US Securities and Exchange Commission, available on sec.gov. sec.gov

• Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile, SP 800-61 Rev. 3. National Institute of Standards and Technology (NIST). https://csrc.nist.gov/pubs/sp/800/61/r3/final