How to build the foundations of your incident response plan in 4 weeks

1. The plan is outdated

On paper, there is often a plan. The problem is that the document no longer reflects reality. It was written for an old network environment, old systems or outdated responsibilities. Employees have left, suppliers have changed, and critical processes now operate differently. If people are forced to work with outdated information during a crisis, valuable time is lost.

2. The plan is unfamiliar

Sometimes the plan's content is still usable, but hardly anyone knows it. The people who need to take action have never really read the document, do not know where it is stored or do not fully understand their role. That creates uncertainty at the very moment when speed matters most. Who declares the crisis? Who makes decisions? Who informs the organisation? If that is not clear in advance, confusion begins immediately.

3. The plan has never been tested

A plan can look logical on paper and still fail in practice. You only discover that through testing. Does the out-of-band communication channel actually work? Can you assemble the crisis team quickly enough? Can the team set priorities under pressure? Without testing, these remain assumptions. And once a real incident occurs, improvisation takes over.

Start with the darkest scenario

Many organisations also build their incident response plan around a manageable scenario. An application fails, a supplier cannot deliver, or a process is temporarily delayed. But ransomware completely changes the starting point. You need to assume the opposite: that everything is down. No email, no telephony, possibly no ERP, and perhaps no certainty about which systems can still be trusted.

At that point, the question changes as well. It is no longer only about full recovery, but first about survival. How do you get through the day? Which business processes need to be restored first? How do you organise decision-making and communication when your usual tools are unavailable? That sounds drastic, but a usable plan does not have to be perfect. In a crisis, practicality matters more than completeness.

A workable foundation in 4 weeks

Organisations do not need months to build an initial, usable foundation for an incident response plan. By making clear choices and starting small, you can make a major difference in just four weeks.

Week 1: prioritise processes

The first week is all about focus. Which three business processes are so critical that they need to be restored first after an incident? Not ten, not five, but three. That decision forces prioritisation. At the same time, you need clarity on the minimum operational level for each process, the acceptable downtime, and who is responsible for recovery and decision-making.

Week 2: map dependencies

In the second week, attention shifts to dependencies. For each of those processes, you need insight into the people, systems, data sources and third parties required to keep it running. This is often where organisations realise how vulnerable they are. Processes are usually documented only for situations where everything works, not for when IT fails. That is why it is equally important to ask how a process could temporarily continue without digital support.

Week 3: create a compact plan

The third week is about the plan itself. It does not need to be a detailed playbook running to dozens of pages. In many cases, two short documents are enough. The first document should describe what needs to happen in the first hour: who can declare a crisis, how the crisis team is assembled, which out-of-band communication channel is used and who takes the lead on recovery and decision-making.

The second document should focus on the first twenty-four hours: what has been confirmed, what remains uncertain, which workarounds are being activated, who informs which stakeholders and which actions cannot be delayed if you want to prevent the situation from getting worse.

Week 4: test the plan

The fourth week is all about testing. A plan that has never been practised remains an assumption. Two short tabletop exercises are often enough to expose the biggest weaknesses. The first exercise shows whether the organisation can declare a crisis and gather the right people within fifteen minutes. The second test is whether the team can prioritise and make decisions under pressure, without getting stuck in endless discussions.

Leadership needs to be involved too

An important advantage of this approach is that incident response is no longer treated purely as an IT issue. In many organisations, crisis plans are written in such technical terms that management disengages. Yet the most important questions during a real crisis are rarely purely technical. Which processes need to come back first? Which risks is the organisation prepared to accept temporarily? What do we communicate to employees, customers and partners? And who makes those decisions?

Once an incident response plan is built around business processes, priorities and communication, it becomes much easier to secure leadership involvement. That is essential, because in a serious crisis, the most difficult decisions are not taken by IT alone, but by the organisation’s leadership as well.

Preparedness beats perfection

Organisations that want to become more mature will eventually need to invest in areas such as Business Impact Analysis, up-to-date network documentation, clear roles and regular exercises. But that should not be a reason to keep waiting for the perfect plan.

The first step is smaller and more practical than many organisations think. The goal is not to have a document on the shelf that theoretically covers everything. The goal is to make sure you do not have to start from scratch during a crisis. You need to know who should be involved, how to reach each other when the usual systems fail, and which processes need to be restored first. For that, four weeks is enough.