Most companies think about a security incident the way they think about a fire drill they've never actually run: they assume someone will know what to do when it happens. In practice, the first hour after something goes wrong is usually chaos, not because the threat is unusually sophisticated, but because nobody had already decided who does what, in what order, before the moment arrived.
That gap is rarely about technology. It's about the absence of a rehearsed plan, and it's one of the clearest ways to tell a managed security provider that reacts from one that's actually prepared.
An employee notices something odd: a file they didn't touch has changed, a login alert from a city they've never visited, a system running unusually slow. They mention it to their manager. The manager isn't sure if it's serious, so they email IT. IT opens a ticket. Somewhere in that chain, twenty or thirty minutes pass before anyone with the authority to act even knows there's a problem, and by then whatever was happening has often already run its course.
None of the people in that chain did anything wrong. The company simply never decided, in advance, what "something looks off" should trigger. There was no fast lane between "employee notices" and "someone starts containing it."
The damage in most incidents isn't done by a single dramatic action, it's done by the accumulation of everything that happens while nobody's responding. A compromised account left active for three hours can reach far more systems than one shut down in ten minutes. A ransomware process left running overnight can encrypt what would have taken minutes to isolate that afternoon.
This is the part that gets lost when companies evaluate security purely on tools and coverage. A managed security provider can have excellent detection and still leave a company exposed if the plan for what happens after detection is loose, undocumented, or dependent on whoever happens to be reachable that day.
It's not a binder that sits in a shared drive untouched until the day it's needed. By then nobody remembers where it is or what page to open. A response plan that actually works has a few concrete things in place before anything goes wrong: a named point of contact who can be reached at any hour, pre-agreed authority to isolate a system or disable an account without waiting for a chain of approvals, and a communication sequence that tells leadership what's happening in plain language while containment is already underway, not after.
The difference shows up in the first conversation after an incident. A company with a real plan says "we isolated it at 9:14, here's what we're seeing, here's what's next." A company without one says "we're still trying to figure out what happened."
Larger enterprises build response drills into their operations because regulation and scale require it. Smaller companies often assume their managed security provider has this handled implicitly, without ever asking what the actual sequence looks like or timing how long it would realistically take.
That assumption tends to hold right up until it's tested for real, at which point the gap between "we have a security provider" and "we have a response plan" becomes very expensive, very fast.
We treat incident response as something to rehearse, not just document. That means a named escalation path that doesn't depend on one person's availability, pre-authorized steps to contain a threat immediately rather than waiting on approval chains, and clear communication with leadership from the first minute not the first day. The goal isn't just catching problems. It's making sure the response is already decided before the moment it's needed, so the technology a company relies on keeps working quietly in the background, the way it should.
Ask what would happen right now if someone flagged something suspicious at 4:45 on a Friday. Who gets the message? How long before someone with authority is looped in. What gets shut down, and who's allowed to make that call. If those answers take longer than the incident would, that's the gap to close and it's exactly the kind of gap a genuinely proactive managed security provider is built to close before it's tested for real.