The First 24 Hours: What to Actually Do When You've Been Breached

Most businesses have some idea of how to avoid getting hacked. Far fewer have any idea what to do in the hours after they discover it has already happened.

That asymmetry costs money. The difference between a well-handled incident and a badly-handled one is rarely the sophistication of the attacker. It's whether the people responding knew what to do in the first hour, or whether they spent that hour improvising — deleting things, rebooting servers, and unintentionally destroying the evidence they'd need later.

This is a practical walkthrough of that first day. Not the theory of incident response, but the sequence of decisions, in roughly the order you'll face them.

Before anything else: two rules that shape everything

Don't power anything off.

This is the instinct almost everyone has, and it's usually wrong. Shutting down a compromised machine wipes the contents of memory, and memory is where a lot of the useful evidence lives — running processes, active network connections, encryption keys, credentials, malware that never wrote itself to disk at all.

Disconnect from the network instead. Unplug the ethernet cable, disable the wireless adapter, or isolate the machine at the switch or firewall. The system stays running, the attacker loses their connection, and the evidence survives. If you have EDR software, most products can isolate an endpoint remotely while keeping it live for analysis, which is the ideal version of this.

The exception is active, spreading ransomware. If files are visibly encrypting right now, containing the spread outranks preserving evidence, and pulling power is defensible. That's a genuinely narrow exception, though — not a general licence.

Assume you're being watched.

If an attacker has your email, they can read your incident response discussion in real time. This happens more than people expect, and it hands them a significant advantage: they know what you've found, what you haven't, and exactly when you're about to lock them out.

Move coordination to an out-of-band channel immediately. Personal phones, a messaging app on personal accounts, or a conference bridge nobody set up through the compromised system. Do this at the start, not after you realise you should have.

Hour one: establish what you're actually dealing with

The first hour is about orientation, not remediation. Acting decisively on a wrong understanding is worse than acting slowly on a correct one.

Confirm it's real. A meaningful share of reported incidents turn out to be something else — a misconfiguration, a legitimate admin action nobody recognised, a false positive from a security tool. Spend ten minutes verifying before you trigger a full response, because a false alarm that shuts down operations has its own costs and makes people slower to report next time.

Work out the category. The response diverges sharply depending on what you're facing, and the main branches are:

Business email compromise — someone has access to a mailbox, usually to intercept or redirect payments. Look for unexpected mail rules, unfamiliar sign-in locations, and sent items nobody wrote.

Ransomware — encrypted files, ransom notes, systems unavailable. Time-critical and operationally disruptive.

Data exfiltration — data has been copied out, often with no disruption at all. The hardest to detect and the one with the heaviest legal consequences.

Credential compromise — someone has a valid login and is using it. Often the precursor to one of the above.

Insider incident — a current or former employee. Handle differently; involve HR and legal before IT takes visible action.

Establish the timeline. When did it start? This question drives everything downstream — how far back your logs need to go, which backups are trustworthy, and what your notification obligations look like. Initial estimates are almost always wrong in the same direction: the intrusion started earlier than you think. Median dwell time for attackers before detection is measured in days to weeks, not hours.

Identify what they could reach. Not what you know they took — what the compromised account or system had permission to access. That's your worst-case scope until evidence narrows it, and you should plan against it.

Write things down as you go. Every action, with a timestamp and a name attached. This feels like bureaucratic overhead in the middle of a crisis and it is the thing you will be most grateful for afterwards, in insurance claims, regulator conversations, and any litigation. Use a document nobody can edit retroactively.

Hours one to four: contain it

Containment means stopping the bleeding without destroying your ability to understand what happened.

Isolate affected systems at the network level, as described above.

Reset credentials, in the right order. Start with the most privileged: domain admin, cloud root and admin accounts, service accounts with broad permissions. Then the accounts you know are compromised. Then everything else, in a planned wave rather than a panic.

Critically, a password reset alone often isn't sufficient. Existing sessions can survive it. Force a global sign-out across all devices, and revoke refresh tokens, OAuth grants, application passwords, and API keys. An attacker holding a valid session token doesn't care that you changed the password.

Check for persistence. Competent attackers plan for you locking them out, so they leave a way back in before you notice them. Look for: new user accounts, especially privileged ones; mail forwarding and inbox rules; new OAuth applications authorised against your tenant; MFA devices registered that nobody recognises; scheduled tasks and cron jobs; new SSH keys; API keys and access keys created recently; firewall rule changes; VPN accounts.

This step gets skipped constantly, and skipping it is why organisations get re-compromised a week after declaring the incident closed.

Preserve evidence before you clean anything. Snapshot affected virtual machines. Export the logs you have — and check retention windows immediately, because if your logging keeps thirty days and the intrusion started forty days ago, you need to know that now rather than in three weeks. Capture memory from key systems if you have the capability or someone who does.

Enforce MFA everywhere if it isn't already. Mid-incident is an unpleasant time to roll this out, but it's the single most effective control against the credential reuse that follows most breaches.

Hours four to twelve: bring in the right people

Your insurer, first. If you hold cyber insurance, call the notification number in your policy before engaging any external help. Most policies require you to use their approved forensics and legal panel, and hiring your own firm first can reduce or void the claim. This is the mistake that costs the most money and the one people make most reliably, usually with good intentions.

Legal counsel, early. Beyond the obvious reasons, engaging counsel early can bring the forensic investigation under legal privilege in some jurisdictions, which matters if the incident ends up in litigation. Counsel also owns the notification analysis, which is a legal question rather than a technical one.

Forensics, if the scope warrants it. Small, clearly-bounded incidents can be handled internally. Anything involving data exfiltration, ransomware, or an unclear scope needs people who do this professionally. Your MSP may be able to handle the response or may coordinate a specialist — either way, that relationship should be established before you need it, not discovered during.

Law enforcement. Reporting is generally advisable and sometimes required. In the UK, that's Action Fraud and the NCSC; in the US, the FBI's IC3; in the EU, your national CERT. They rarely recover funds, but reports feed intelligence that helps others, and some insurers require it. For fraudulent payments, contact your bank immediately — the window for recalling a wire transfer is measured in hours.

The notification clock

This is where a technical incident becomes a legal one, and the deadlines are shorter than most people realise.

GDPR requires notification to the supervisory authority within 72 hours of becoming aware of a personal data breach, unless it's unlikely to pose a risk to individuals. That clock starts at awareness, not at the point you finish investigating. If you don't have complete information at 72 hours, you file what you have and supplement later — you don't wait. Where there's high risk to individuals, they must be notified too, without undue delay.

Sector rules stack on top. Financial services, healthcare, and critical infrastructure typically have their own regulators and their own, often shorter, timelines.

Contractual obligations are easy to forget. Many B2B contracts contain breach notification clauses with deadlines tighter than any regulation — sometimes 24 hours. If you process data for clients, you're a processor under GDPR, and you have an obligation to notify them without undue delay so they can meet their own deadlines. Someone should be reading those contracts on day one.

The general principle: notification decisions are made by legal counsel based on the facts, and the bias should be toward earlier and more transparent rather than later and defensive. Regulators consistently treat delayed or misleading disclosure more harshly than the breach itself.

Ransomware: the specific decisions

Don't pay reflexively, and don't rule it out reflexively either. It's a business decision informed by legal advice, and there are jurisdictions and circumstances where payment is itself unlawful — particularly if the group is under sanctions.

Payment also doesn't reliably work: decryptors are frequently slow, incomplete, or broken, and a meaningful proportion of victims who pay get hit again.

Check whether a free decryptor exists. The No More Ransom project maintains tools for a number of ransomware families. It costs five minutes to check.

Test your backups before you trust them. Two questions matter: are they clean, and are they reachable? Modern ransomware groups specifically target backups before triggering encryption, and they often dwell in the environment for weeks first — which means your recent backups may already contain their access. Restore to an isolated environment and verify before restoring to production.

Assume data was stolen, not just encrypted. Double extortion is now standard practice: exfiltrate first, encrypt second, threaten publication. This turns a business continuity problem into a data breach with full notification obligations, and it's why paying doesn't make the legal problem go away.

Communication

Internally, say something quickly even if you can't say much. A short, honest message beats silence. Silence produces speculation, and speculation leaks. Tell people what's happening in general terms, what you need them to do, and when they'll hear more. Give them a specific channel for reporting anything unusual they notice.

Prepare external communications before you need them. Customers, partners, and press may all need a statement, and drafting under pressure produces things you regret. Legal reviews anything that goes out.

Never speculate publicly about scope or cause. The single most damaging pattern in breach communications is confidently understating the impact and then revising upward repeatedly over the following weeks. Each revision destroys more trust than the original disclosure would have. Say what you know, say what you don't, and commit to updating.

Watch for follow-on fraud. Attackers and opportunists both exploit the confusion. Expect phishing that impersonates your incident response, and warn staff and customers accordingly.

Mistakes that make it worse

A short list, all of them common.

Rebuilding a compromised machine immediately, destroying the evidence needed to understand the intrusion. Resetting one compromised password and considering the matter closed, without checking for persistence. Discussing the incident on the compromised email system. Waiting to notify because you want complete information first. Engaging your own forensics firm before calling the insurer. Restoring from backups without verifying they're clean, and reintroducing the attacker to a freshly rebuilt environment. Skipping documentation because there's no time — there is never time, and it's still the wrong call.

After the first day

Once containment holds, the work shifts to eradication and recovery: removing every foothold, rebuilding from known-good images rather than cleaning in place, restoring in a planned order, and monitoring intensively for signs of return.

Then the part that most organisations skip. A blameless post-incident review, held within a couple of weeks while memory is fresh, asking three questions: how did they get in, why didn't we notice sooner, and what would have limited the damage? Blameless matters — if the review becomes an exercise in assigning fault, you'll get a sanitised account and learn nothing worth knowing.

The output should be a small number of specific, owned, dated changes. Not a fifty-item wishlist that gets filed and forgotten.

The uncomfortable truth about preparation

Everything above is significantly easier if some of it was decided in advance.

You don't need an elaborate incident response plan. You need a single page, printed and stored somewhere that doesn't depend on your network being up, containing: who to call in what order, with phone numbers; your insurer's notification line and policy number; the out-of-band communication channel; where the logs live and how long they're kept; and who has authority to make the expensive decisions — take systems offline, engage forensics, notify customers.

Then walk through a scenario once a year with the people who'd actually be involved. Ninety minutes, around a table, talking through what each person would do. Every organisation that does this discovers something broken — usually that a critical decision has no clear owner, or that the backup nobody's tested doesn't restore.

Discovering that in a meeting room is inexpensive. Discovering it at 3 a.m. on the worst day of your professional life is not.