Preparation

Preparation starts with knowing what you need to defend. What resources are at your disposal, the risk appetite of the company, what laws are relevant to your sector (don't think of the GDPR or NIS2 as something to add on, but use it as a guideline from the start).

Going back to the fire analogy, what would you save when a fire breaks out? What do you need to protect the most? What do you expect other people to do or not to do? Do you have support for your plans? Some companies might only need a very simple one pager incident response plan, for other companies, writing out each step in great detail and discussing all these details with everyone involved is the way forward. Maybe you need to write an executive summary of your plans. One document might not do the trick for everyone in the organization. That is something only you can find out. Try to answer the following questions.

Why

What are the reasons you want an incident response plan? - Minimize impact of an incident - Compliance/Regulatory requirements - You want to have "something" in case of emergency and not run around like a headless chicken

Who

Who do you need to convince? Who will be responsible for an incident? What do you expect from your coworkers? Who will take on what role during an incident? Who is reporting to who? And maybe: Who are you going to call? Who is responsible if everything goes wrong? Usually this is not the IT department. Who is going to keep a log of the incident and recovery? Who is going to communicate to customers or the press? What if people are sick or on vacation? Tools like a RACI matrix can help.

What

Think about what will help your organization before, during and after an incident. Is there a risk assessment? Do you know what the crown jewels are? Does the company have and want policies and procedures for incident response? Maybe the focus should be on training and awareness? You can write the very best policies and procedures, but are people going to follow them when the proverbial shit hits the fan? You cannot create a plan in a vacuum, this brings us back to the first two questions. What tools to you have at your disposal and who is going to use these tools. You might have the technical capability to isolate parts of your network, but can the IT staff also perform the task? Not just on a technical level, are they allowed to take down production machines? Who is responsible for this decision? These are the types of discussions that will gridlock you during an incident.

Think about

If you want to file a police report, think about what you might need for that at the preparation stage. It will save you a lot of work. If you want to take legal action in case of an insider threat, make sure you have talked to your HR department first and have (IT/personnel) policies that mention your employees are being monitored. What is expected from them and what isn't allowed. But also think about you or your employees during the preparation phase. Are you expected to work overtime during the incident? Who is going to approve the overtime? Who is going to check in to make sure you aren't overwhelmed or too stressed out?

Issues with a generic approach

Hopefully you start to see the issue with one incident response plan for every organization. A company with 5 employees and physical store and a website will have different needs than a company with 300 employees who rely on the uptime of their machines for production. Some guides will advice a jump bag with incident response tools, but do you know how to use them? It might be more cost effective to hire someone who does this work regularly. This is why the preparation phase is so important, the why, who and what determine the content of your incident response plan.