It is Monday morning. Ransomware has brought your organisation to a standstill. No email. No Teams. No access to ERP. Fortunately, an employee still has a printed Incident Response Plan. However, the plan is three years old, written by someone who no longer works for the organisation, and describes a network that has long since been structured differently. Meanwhile, the clock keeps ticking.
This is not a hypothetical doomsday scenario. It is the reality that incident coordinators and strategic advisors regularly face when supporting organisations during a real cyber crisis. On paper, there is often a plan. In practice, however, that plan turns out to be outdated, unknown, or never tested.
1. The plan is outdated
Often, something has been documented. However, it no longer aligns with reality. It was drawn up based on an old network environment, outdated systems, or responsibilities that have since shifted. Employees have left, suppliers replaced, and critical processes restructured. Anyone who has to work with outdated information during a crisis loses valuable time.
2. The plan is unknown
Sometimes the plan is still usable in terms of content, but almost no one knows that. The people who need to take action have never really read the document, do not know where it is located, or are insufficiently familiar with their roles. The moment speed is crucial, doubt arises.
Who declares a crisis? Who makes the decisions? Who informs employees, customers, and partners? If this is not clear beforehand, confusion begins immediately.
3. The plan has never been tested
An Incident Response Plan may seem logical on paper yet fail to work in practice. This only becomes clear during an exercise. Does the out-of-band communication channel actually work? Can you convene the crisis team quickly enough? Does decision-making hold up under pressure? Without testing, these remain assumptions. And as soon as a real incident occurs, improvisation takes over.
Start with the worst-case scenario
Many organisations write their Incident Response Plan based on a manageable scenario. An application fails. A supplier is temporarily unavailable. A process is delayed. With ransomware, that starting point does not work.
In that case, you must assume the opposite: everything is down. No email, no telephony, possibly no ERP, and limited certainty about which systems can still be trusted.
From that moment on, the question changes as well. It is not immediately about full recovery, but first about survival. How do you get through the day operationally? Which business processes need to be restarted first? How do you organize decision-making and communication when normal resources are unavailable?
That sounds drastic, but a usable Incident Response Plan does not have to be perfect. Especially in a crisis, workability is more important than completeness.
A workable foundation in four weeks
Organisations do not need months to lay a first, usable foundation for their Incident Response Plan. Those who choose wisely and start small can make a big difference in just four weeks.
Week 1: Prioritise processes
The first week revolves around focus. Which three business processes are so critical that the organisation must restore them first in the event of an incident? Not ten, not five, but three. Additionally, for each process, it must be clear what the minimum operational level is, how much downtime is acceptable, and who is responsible for restoration and decision-making.
Week 2: Map out dependencies
In week two, the focus shifts to dependencies. For each process, it becomes clear which people, systems, data sources, and external parties are needed to keep it running. It is precisely here that the vulnerability of organisations often becomes apparent. Processes are described for the situation where everything works, but not for the moment when IT fails. Therefore, it is also relevant how a process can function temporarily without digital support.
Week 3: Make a compact plan
The third week focuses on the plan itself. This does not need to be an extensive script of dozens of pages. Often, two compact documents are sufficient. The first describes what needs to happen in the first hour: who is authorized to declare a crisis, how the crisis team is convened, which out-of-band communication channel is used, and who is in charge of recovery and decision-making. The second focuses on the first twenty-four hours: what has been confirmed, what remains uncertain, which workarounds are being initiated, who informs which stakeholders, and which actions must not be delayed to prevent the situation from deteriorating further.
Week 4: Test the plan
The fourth week revolves around testing. An Incident Response Plan that has never been practiced remains an assumption. Two short tabletop exercises are often sufficient to reveal the most important weaknesses. The first exercise tests whether the organisation can declare a crisis within fifteen minutes and gather the right people. The second exercise shows whether the team can prioritize and make decisions under pressure, without getting bogged down in consultation.
The management must also be on board
An important advantage of this approach is that incident response does not remain a purely IT subject. In many organisations, plans are so technically oriented that executive involvement is lacking. Yet the most impactful decisions during a crisis are rarely technical.
Which processes need to be restored first? Which risks does the organisation temporarily accept? What do we communicate to employees, customers, and partners? And who makes the decision regarding this? Without the active involvement of the executive and board, incident response remains immature by definition.
As soon as an Incident Response Plan is built around business processes, priorities, and communication, that engagement does emerge. And that is essential in a serious crisis.
Preparedness trumps perfection
Those who wish to grow further in maturity will eventually invest in matters such as Business Impact Analysis, up-to-date documentation, clear role divisions, and periodic exercises. However, that should not be a reason to wait for the perfect plan.
The first step is smaller and more practical than many organisations think. The goal is not a document that covers everything in theory, but one that ensures you don't have to start from scratch during a crisis. It is knowing who needs to get on board, how to reach each other if standard resources fail, and which processes need to be restarted first.
Four weeks is enough for that.
Schedule an introductory meeting
Would you like to brainstorm about how your organisation can set up or refine a workable Incident Response Plan? We would be happy to take a look at what this might look like in your context.
Schedule an introductory meeting