The First 24 Hours of a Data Breach: What to Do, and What Not To

Declare an incident as soon as a breach is credible, not when it is certain. Name an incident lead, a technical lead, a scribe who keeps the timeline, and a communications owner. Keep the group small; every extra person is another possible leak.

Move communication out of band. If an attacker has access to your identity system or email, they may be reading your response. Use a separate channel on accounts not tied to the potentially compromised directory, and share details on a need-to-know basis.

Start the timeline now. Every action, finding, and decision, with times. You will need it for the investigation, for regulators, and possibly for litigation. Record facts and decisions, not speculation.

The instinct is to shut down the affected machine or wipe and rebuild it. Both destroy evidence.

Do not power off compromised systems unless they are actively causing serious harm, such as encrypting data, and cannot be isolated. Memory holds running processes, network connections, encryption keys, and attacker tools that exist nowhere else and vanish at shutdown.

Isolate instead. Remove the system from the network through switch ports, security groups, or endpoint isolation features, so it cannot communicate while its state is preserved.

Capture memory and disk images where you have the capability, or engage a forensic firm that does. For cloud workloads, snapshot volumes and preserve instance metadata before terminating anything.

Authentication logs, VPN and remote access logs, firewall and flow logs, cloud audit trails, email and identity provider logs, and endpoint telemetry. Many systems keep only days or weeks of history by default. Export copies to storage the attacker cannot reach, and extend retention on anything relevant.

These logs answer the questions everything else depends on: how did they get in, when, what did they touch, and are they still there?

Mass password resets, disabling accounts, or blocking an address in the first hour feel decisive. Before you know the attacker's footholds, they can backfire: the attacker notices, switches to a persistence mechanism you have not found, or triggers destructive actions such as encryption or deletion.

Where the attacker is actively causing harm, act immediately. Otherwise, scope first, then remove access across all known footholds in one coordinated action. Credentials for highly privileged accounts are the exception to consider early, with the incident lead weighing the risk.

Notification obligations can start when an organisation becomes aware of a breach, not when the investigation ends. Under the GDPR, for example, a personal data breach must be reported to the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it. Other regimes, sector regulators, and contracts impose their own deadlines.

Involve legal counsel on the first day. Counsel decides what must be reported, when, and to whom, and engaging forensic firms through counsel can matter for how investigation findings are treated. Do not make public statements or notify customers before that conversation.

You should have: an incident team and out-of-band channel; affected systems isolated with evidence preserved; logs exported beyond the attacker's reach; an initial hypothesis of entry point and scope; counsel engaged and notification obligations identified; and a plan for coordinated eradication once scope is understood. Most of that is only achievable quickly if the incident response plan, contacts, and forensic retainer existed before the breach. The first day of a real breach is a poor time to discover that nobody knows who the company's lawyer is, or where the firewall logs are kept.