All Blogs
You get a message from an employee that something looks off in their inbox. Or your phone buzzes with an alert you don’t recognize. In the first thirty seconds, you’re not sure if it’s nothing or if it’s the start of the worst week your business has had in years. Most owners have never genuinely considered what they’d do in this situation before it happened to them. If you’ve ever asked yourself whether your business is actually resilient or just lucky, this is the moment that question stops being theoretical.
Here’s what the last several years of incident response work has shown: the attack itself is rarely what does the most damage. The decisions your team makes in the next four hours are. This article walks through what those decisions actually look like, where they break down, and what changes if you’ve thought them through in advance instead of improvising them under pressure.
“Within 20 minutes of Microsoft publishing the logs, an M365 session can be hijacked. The attacker is in your mailbox doing damage in real time. Without the right detection layer in place, you find out later.” — Larry Schwartz, President & CEO, Midnight Blue Technology Services
The moment you notice a problem is rarely the moment the problem started. IBM’s 2025 Cost of a Data Breach Report puts a number on that gap. Across the roughly 6,500 breaches the report examined, organizations took a mean of 241 days to identify and contain an attack, split between 158 days to identify it and another 83 days to contain it once found. That’s the lowest in nine years, and it’s still eight months. Breaches that started with stolen credentials ran even longer, at 246 days on average.
My team has described the same pattern anecdotally from our own client base, putting the range we typically (but not always) see at somewhere between 100 and 200 days before an issue surfaces. What you’re calling the “start” of the incident is usually just the moment it became visible. Whatever happened before that point already shaped how bad it’s going to get.
An attacker who has landed inside a network is rarely in a hurry. The loud, obvious attacks, the ones that lock every file and drop a ransom note on the screen, tend to happen fast because that’s the point where the attacker wants to be noticed. Getting to that point is the slow part, and it’s the part nobody sees.
During those weeks or months, the attacker is mostly doing three things:
None of this is about speed. It’s about setup. The longer an attacker gets to do this undisturbed, the more of your network they understand by the time they decide to act, which is exactly why the moment of discovery so often comes with a wider blast radius than anyone expected. By the time you find out something is wrong, you may be dealing with someone who has a better working map of your systems than your own team does.
This is the part of an incident where nobody is fixing anything yet. The job in the first four hours is making the right calls, not solving the problem. There’s no single script that fits every business here. The right approach for your business should be built into your Incident Response Plan, and it can look different from one company to the next.
What doesn’t change is that someone needs to have already worked out who gets notified, in what order, and who ultimately decides whether a cyber insurance claim gets filed, with input from their IT partner. Three decisions carry the most weight once that chain gets tested for real.
The most common failure point is the notification chain itself. Someone calls the CEO. The CEO calls a vendor. Remediation starts before anyone has preserved evidence for the forensics or the insurance claim. The exact chain will vary depending on how your IRP is built, but here’s a typical sequence for an MBTS client, as an illustrative example:
Calling the carrier early in that sequence is what actually preserves both the coverage and the privilege. It’s not something you can go back and fix later if it’s skipped.
Even with a sequence like that mapped out, at MBTS we describe the internal version of this as a work in progress. What’s your PR around it, who do you tell, and how far are you allowed to go before you have to stop? That’s still a learning process for us.
That’s worth taking at face value rather than as a weakness. If a company that handles incidents for a living is still refining who gets told, in what order, and when, then assuming your own team would handle it smoothly under pressure is optimistic. Before an incident hits, a checklist like this is exactly what keeps the first hour from becoming a 10-hour mistake. The value isn’t having a perfect checklist. It’s having one written down before you need it, so your team isn’t improvising it under pressure.
The instinct in a client-facing business is to communicate fast and broadly. Unfortunately, that instinct can could backfire and cost you. Talking too soon, to the wrong people, in the wrong way, can complicate an insurance claim or create legal exposure that didn’t need to exist.
The most important thing to keep in mind: don’t post publicly, don’t send a company-wide email saying systems are down with speculation about why, and don’t tell staff more than they need to do their jobs until the scope of the incident is understood. Fewer people knowing the full picture before forensics has assessed it is a protection, not a secrecy problem.
Most cyber policies carry a notification window of 24 to 72 hours after discovery, and most business owners don’t have the number saved anywhere they can find it in a crisis.
What you say on that call matters as much as making it, and it’s worth having a basic call script prepared in advance so you don’t have to improvise under stress.
“We can guide them on how to answer. A little bit more legalese. Don’t say yes to that, say this, because we’ve seen times where somebody answered something they thought was truthful, and it backfired.” — Larry Schwartz
I remember a case where the attack itself was arguably unavoidable given the security controls in place at the time. The claim was still denied, and the business lost a significant sum of money, because the hygiene gaps the carrier found had nothing to do with how sophisticated the attacker was.
Once the first calls are made, the strongest instinct is to get back to normal as fast as possible. That instinct is usually wrong. Moving toward recovery before the scope is actually contained tends to make the incident bigger, not smaller.
MBTS has a case that illustrates this directly: a client whose employee was walking around with an infected thumb drive, combined with third-party vendor connections into the network that MBTS had already flagged and recommended closing. Containing the actual scope took 100 hours. The client fought the bill, even though we saved them from a much bigger expense.
The 100 hours it took to remediate that network was not the IT partner running up the clock. It was the direct result of third-party access that should have been closed months earlier. Cutting a corner on network hygiene before an incident doesn’t remove the cost. It just moves the bill to the worst possible moment to receive it.
Even businesses with good, tested backups face a gap between reliable backups and returning to normal. Recovery order, system dependencies, and the time needed to validate backup integrity all matter.
In our experience, a realistic return to operations is around 3 to 7 days for full restoration (initial access can return in 24 to 48 hours). The longest part of the process is validating backup integrity and confirming the threat actor is fully eradicated. All too often, clients are surprised when restoring too fast can cause reinfection and double the recovery time.
For a well-prepared 30–50 person firm specifically, that means often restoring within a day if backups are clean, but it can take weeks if forensics needs to get involved first. Forensics gets engaged when there’s ransomware, malware, or evidence of data theft.
Having backups is not the same as knowing how long a real restoration takes for a business your size, and not every incident needs outside forensics brought in. But some do, and the trigger is not always obvious in the moment.
These are specific triggers to look for:
A written plan doesn’t stop an attack. What it changes is whether your team rapidly executes something they’ve already walked through, or improvises the biggest decisions of the year under pressure.
The most common things that would be in a written plan are an acceptable use policy, an incident response plan, and policies around passwords and user access. There are about five to ten standard policies that people think they have. And even if you look at what they have, they’re pretty bad.
Not every business needs the same level of incident response planning. A 15-person insurance agency and a 90-person law firm with CMMC obligations are not solving the same problem. If you’re a small firm with no regulated data, a one-page response checklist that your whole team has actually walked through is a legitimate starting point. It doesn’t need to be a compliance framework built for a company five times your size. It needs to be tested.
This kind of planning isn’t something every client is handed by default. It’s not currently in our standard stack, but I include it where it makes sense. It’s not automatic, but it’s available for clients whose risk profile calls for it, built as its own package rather than bolted onto the standard offering.
If you don’t have a plan yet, you’re not behind some standard everyone else has met. Most firms your size haven’t done it either. The only real question is whether you find that out before an incident, or during one.
Across real incidents, the same three mistakes show up repeatedly, and they tend to come from good instincts applied at the wrong moment.
The first is powering off systems or deleting files the moment something looks wrong. It feels like the responsible move, but it’s usually the opposite. That action destroys the volatile memory and forensic evidence investigators need to figure out what actually happened. The better move is disconnecting the affected systems from the network while leaving them powered on.
The second is communicating too broadly before the scope is understood, something this article already touched on. It’s worth repeating here because it’s this consistent: talking too soon, with too many people, can trigger unnecessary panic, violate legal protocols tied to the investigation, and damage the insurance claim. Communication should stay restricted to the core incident response team and legal counsel until the facts are verified.
The third is restoring from backups too quickly, before containment and root cause are confirmed. Getting back online fast feels like progress. If the attacker still has access, a fast restoration just hands them a freshly rebuilt network to encrypt all over again. Containment and forensic validation need to come before recovery, not after.
None of these are complicated once you know them. That’s exactly why they’re worth having written down before the moment you need them, instead of relearning them during an incident.
If you don’t have an incident response plan, or you have one nobody has ever actually walked through under realistic conditions, the webinar on August 18 is the right next step. I’ll be covering this exact ground in Beyond IT: The Complete Business Resilience Strategy Every Leader Needs, including what your IRP needs to cover, how to test it, and what the first 24 hours should look like for a business your size.
[Register for the August 18 webinar, 11:00 AM EST →] Is Your Business Actually Resilient, or Have You Just Been Lucky?