What to Do in the First 24 Hours of a Cyber Incident

In the first 24 hours of a cyber incident, two things are happening simultaneously: the attacker is still active or their tools are still running, and the business is making rapid decisions under pressure without full information. The decisions made in those first hours determine how long the incident lasts, how much damage accumulates, and whether the organisation will have the evidence it needs to understand what happened. Most of the critical mistakes we see in incident investigations were made in this window.

The instinct to act immediately is understandable. People want to do something. They restart servers, reset every password in the directory, reimage the affected laptop, call every vendor at once. Some of those actions are necessary. Some destroy evidence. The challenge in the first 24 hours is separating the actions that reduce harm from the actions that feel productive but create problems you will spend weeks untangling.

Hour One: Confirm and Contain

The first priority is confirming that you are dealing with an actual security incident, not a misconfiguration, hardware failure, or software bug. This matters because the actions you take differ significantly. Once confirmed, the next step is initial containment: limiting the attacker's ability to move further through the environment or cause additional damage. Containment does not mean remediation. It means buying time while you understand the scope.

Initial containment typically involves isolating affected systems from the network without shutting them down, which preserves volatile evidence in memory. It means identifying which credentials may be compromised and beginning the process of identifying affected accounts, even if you do not yet reset everything. It means pulling relevant logs from network devices, firewalls, and authentication systems before they roll over. These first actions set the conditions for everything that follows.

What Not to Do

The most damaging actions we see in early incident response are: shutting down affected systems instead of isolating them (which destroys memory forensics), reimaging endpoints before they are forensically imaged, deleting logs that appear to be the source of the compromise, and running antivirus scans across the environment that alert the attacker and modify file timestamps. These actions all feel like remediation. They eliminate the evidence needed to understand what actually happened.

Equally damaging is the impulse to communicate too widely too early. Sending a company-wide email about the incident, posting in team channels, or briefing staff beyond the immediate response team can alert an insider threat, trigger premature public disclosure, or compromise negotiations if ransomware is involved. In the first 24 hours, communication should be on a strict need-to-know basis and should preferably use out-of-band channels if the primary systems are compromised.

Engaging Your Response Team

If you have an IR retainer, the first 24 hours is exactly when you activate it. Your retainer firm should be contacted immediately, given a brief factual summary of what is known, and asked to deploy. If you do not have a retainer, you are now engaging a firm for the first time while an incident is in progress. That process takes hours you do not have: legal agreements, scoping calls, briefings, travel or remote access setup. The gap in response quality between these two scenarios is significant.

Internally, you need a defined incident commander who owns decisions and coordinates the response team. This is not necessarily the most senior technical person. It is the person with the authority to make calls quickly, communicate with leadership, and keep the response organised. Without a clear decision-maker, critical choices get delayed by committee, and the attacker benefits from every hour of confusion.

Documentation From the Start

Everything that happens in the first 24 hours must be documented in real time. Who was notified and when. What systems were identified as affected. What actions were taken and by whom. Which credentials were reset. Which systems were isolated. This timeline becomes the foundation of your incident report for regulators and insurers, and it is almost impossible to reconstruct accurately from memory after the fact.

Assign someone specifically to documentation from the start. That person's job is to maintain a running log of events, actions, and findings. Use a system that is not affected by the incident. If your primary collaboration tools are on a compromised domain, use a phone, a personal device, or a pre-established out-of-band communication channel. The documentation you produce in the first 24 hours will be read by regulators, lawyers, and insurers. It needs to be accurate.

If you are in the middle of an incident or want to prepare before one happens, contact us at info@cyberlinx.com.au. We provide incident response support, retainer agreements with guaranteed response times, and first-24-hours coaching for organisations that want to be prepared.