Let’s say it plainly: most incident response plans are theater. A PDF that was written at some point, sits in a SharePoint folder, and that no one would be able to find in a real emergency, let alone follow. The document exists so you can say in audits, "Yes, we have one." Not so that it works.

Harsh statement? Maybe. But we see it again and again. Companies with solid endpoint protection, regular patching, maybe even zero trust. (We wrote about it here, and why fewer tools often mean more protection.) Prevention is in place. What comes after, when something still happens, is a black hole.

And something will happen. That’s not fearmongering, that’s statistics.

Why does everyone confuse prevention with preparedness?

Because prevention feels good. Every new firewall rule, every security awareness training creates a sense of control. You are doing something. You are investing. You can point to dashboards.

Incident response is the opposite. It is preparation for the moment when all of that has failed. No one wants to plan for that. No one wants to think it through. It feels like defeatism.

But it isn’t. Prevention reduces the likelihood of an incident. Incident response reduces the damage. Both are necessary. But the ratio we see in practice is grotesquely imbalanced.

What is actually in your plan, and is it still accurate?

If you have an incident response plan: when was the last time you read it? We mean really read it, not "I know it exists."

A plan that works contains concrete escalation paths. Not "IT is informed," but: who exactly is called? At what number? Who decides whether systems are isolated? Who is allowed to do that without prior approval?

It contains roles with names and mobile numbers. Not generic job titles. Your incident commander resigned last year? Then your plan is waste paper.

It contains immediate technical measures. What is shut down first? What is intentionally kept online to preserve forensic traces? Where are the backups, and how long does restoration realistically take?

It contains a communication protocol. How do you inform the workforce without causing panic? When do you speak with customers, partners, the press? In Switzerland, there are legal reporting obligations; the NCSC must be informed in certain incidents. Who in your company knows these deadlines?

And it contains a documentation requirement. Everything is logged, because afterward you must be able to demonstrate—forensically, legally, and regulatorily—what happened and when.

Most plans we see have maybe two of these points even somewhat up to date.

Are 72 hours really that critical, or is that just drama?

It’s not drama. In the first 72 hours after an incident, the damage either actively spreads or is contained. Forensic traces are still fresh. Legal reporting deadlines begin to run. Your customers’ trust is being shaped.

We have seen companies that had a ransomware attack under control within 48 hours. The plan existed, it had been practiced, communication worked. And we have seen companies where operations were at a standstill for weeks. Not because of the complexity of the attack. Because of the complexity of internal decision-making paths.

If in a real emergency you first have to figure out who is actually allowed to decide, you lose hours you do not have. In our article on crisis decisions in 15 minutes, we dive deeper into this problem.

If the plan has never been tested, you don’t have a plan

This is the most uncomfortable point. An untested incident response plan is hardly better than none at all.

The mobile number of the external forensics service provider? Outdated. The backup system was migrated, but the plan was not updated. The communication template for customers is phrased in a legally sensitive way. You only find all that out when you test. And the wrong time to test is the moment a real incident is underway.

What helps instead: tabletop exercises. Structured simulations in which the relevant team walks through a scenario. No code, no real systems, but real decisions and real discussions. "Let’s imagine that this morning we received the following alert. What do we do next?"

These exercises take a few hours. The insights are almost always surprising. Yes, it is uncomfortable to find gaps. But better uncomfortable in the conference room than in a real emergency.

By the way, an incident response plan does not replace technical monitoring or basic backup and patching hygiene. What it does replace: improvisation under pressure. And that is worth a great deal. If you want to take that idea further, you can find more in our article on business continuity plans about why BCP and incident response must also be considered together.

The honest question

If, right now, at this very moment, a security incident is reported: do you know who calls, who decides, and what happens in the next 60 minutes? If the answer does not come immediately, that is no reason to panic. It is a reason to schedule a meeting this week and clarify exactly that.

If you’re not sure where to start, that is exactly the kind of conversation we help with. Not a sales pitch. An honest assessment of where you stand and what would make sense. Feel free to get in touch.