The First 60 Minutes After a Cyberattack Decide Everything

Nobody plans to be breached at 8:47am on a Tuesday.

But that's usually how it happens - quietly, in the background, while everyone's just trying to get through their inbox. Someone opens an attachment that looked routine. A login alert gets dismissed because it looked like a false positive. A server starts behaving oddly and nobody's quite sure whose job it is to check.

By the time most businesses realise something is genuinely wrong, the clock has already been running for a while. What happens in the next sixty minutes usually decides whether this becomes a contained incident or a very bad quarter.

And here's the uncomfortable part: what separates the businesses that recover quickly from the ones that don't isn't luck, and it isn't budget. It's what they'd already decided before it happened - who gets called first, what gets isolated, and how quickly the right people find out.

Most businesses have a vague plan. Very few have tested one.

Why the first hour is different from the rest of the incident

Once a breach is confirmed, everything that follows - forensics, recovery, insurance claims, regulatory notifications, client conversations - is shaped by decisions made in the first hour. Move fast and correctly, and you're containing a problem. Hesitate, or move fast in the wrong direction, and you're often making it worse: shutting down the wrong system, alerting an attacker that they've been spotted, or losing evidence that would have told you exactly how they got in.

The first hour isn't about solving the problem. It's about stopping it from getting bigger while the right people get involved. Below are the five decisions that matter most - and the ones we see missing most often when we sit down with a business after the fact.

1. Who gets the first call

In a real incident, minutes matter, and "figure out who to call" is not something you want to be doing under pressure. Most businesses assume this is obvious - "IT will handle it" - but if IT is you, a part-time contractor, or a small internal team without incident response experience, the honest answer is often "handle it slower than the situation allows."

A tested plan names a single point of contact and a clear escalation path in advance: who's called first, who they call next, and who has the authority to make the next set of calls without needing everyone's sign-off first.

2. What gets isolated and what doesn't

The instinct in a panic is often to unplug everything. That's rarely the right move. Shutting down systems indiscriminately can destroy the evidence you need to understand how the attacker got in, and it can take down parts of the business that were never actually compromised.

The better approach is targeted isolation: cutting off the affected device or segment from the rest of the network while keeping unaffected systems running. This requires knowing your network well enough, in advance, to make that call quickly — which is exactly the kind of thing that's much easier to plan calmly on a Tuesday afternoon than to work out live during an active incident.

3. Who tells your team?  your customers?  and when?

Silence looks bad. So does panic. The businesses that come out of an incident with their reputation intact are usually the ones who had already decided, in advance, what gets communicated internally, what (if anything) gets said externally, and who has the authority to say it.

This matters more than it sounds. Say too little, too late, and it looks like a cover-up. Say too much, too early, before you actually know what happened, and you can create legal and regulatory problems that outlast the original incident. A tested plan has draft communications ready to adapt, not written from scratch under pressure.

4. Whether you can actually trust your backups

Almost every business that fails to recover from a serious incident had backups. Very few had tested whether those backups could actually be restored, under pressure, within a timeframe the business could survive.

"We have backups" and "we know exactly how long recovery would take, and we've proven it works" are two very different statements — and the gap between them is usually only discovered at the worst possible moment. This is the decision that should be answered well before an incident, not during one.

5. Who actually has the authority to make the call

This is the one that trips up more businesses than any technical failure. In the middle of a real incident, someone needs the authority to say "isolate this system," "notify the regulator," or "bring in external forensics" = without waiting for a meeting that can't happen fast enough.

If that authority isn't clearly assigned in advance, decisions get delayed while people work out who's allowed to make them. In an active incident, that delay is often the most expensive part of the entire event.

The gap between "we have a plan" and "we've tested a plan"

Most businesses we talk to do have something written down - a document, a policy, a page in an employee handbook. Very few have actually run it: sat the right people in a room, walked through a realistic scenario, and found out where the plan breaks down before a real attacker finds out for them.

That's the difference that actually matters. A plan that's never been tested is a guess dressed up as a strategy. A plan that's been walked through - even once, even informally - tends to reveal the gaps (the contact who's left the business, the backup that's never been restored, the "who decides" question nobody's actually answered) while there's still time to fix them.

The first sixty minutes after a breach will happen exactly once, and there's no version of events where you get to practise it live. The businesses that come out the other side intact are the ones who practised it beforehand instead.

If you're not sure your business could answer all five of these questions right now, that's worth finding out by getting in touch with our trusted team of experts

‍