Nobody likes to think about bad things happening. It can be scary, nerve-racking or even downright depressing. Unfortunately, bad things do happen. So the question is, wouldn't you rather be prepared for those things if and when they happen? To have a plan in place so you and everyone in your company isn't running around with their hair on fire?
Enter the Incident Response Plan (IRP for short) which helps you do exactly that.
What is an Incident Response Plan
At it's core, an Incident Response Plan is a device to help you prepare for situations and events which could potentially damage your company. As mentioned above, it's intended to prevent everyone from running around with their hair on fire in the event of a catastrophe by providing a set of procedures to follow in the event of said catastrophe.
More than that, the creation and maintenance of an IRP is a fantastic exercise for table topping various scenarios and finding potential blind spots within your organization, and resolving them before they become a real problem.
IRPs are a core part of the "Assume Breach" business security and continuity model. That is to say, bad things happening is more a matter of "when", not "if", so it's best to be prepared and know how to respond to those situations when they do occur.
What should I put in my plan?
IRPs work well in conjunction with a Business Impact Assessment when first setting one up. In fact, we recommend completing a BIA first, if you haven't already, to identify the critical points of your company. After that, frame your initial IRP around scenarios involving your most critical infrastructure and personnel.
For example, if your company manufactures things, a ransomware attack against the storage system where you keep your designs and documentation would be devastating. Going through a mock example of this scenario (called "table topping") will help you develop a strategy and action plan to deploy in the event a ransomware event does happen. Not only that, it can also help clarify processes and items to put in place now to help mitigate the chances of a ransomware attack happening in the first place.
IRPs shouldn't be strictly about IT or cybersecurity either, although they do tend to relate to technology very closely. Notice I mentioned personnel earlier? An IRP should cover scenarios in which one or more key personnel become incapacitated or, worst case, die. What happens if your receptionist, who also doubles as your book keeper, gets hit by the proverbial bus? Assuming you're a business owner reading this, what happens if you become unavailable? What employees need to fill what roles? How will things be communicated to your customers (will things need to be communicated?)? What accounts and processes do you maintain sole access over which could be a major headache for your employees or anyone tasked with filling your role if you get abducted by aliens tomorrow?
Identifying these scenarios and working through them as an exercise, then putting the results on paper goes a very long way to being prepared for those situations, should they occur. So be as thorough as possible when coming up with situations which could occur and putting them in your IRP. That said, try not to get super specific about any given scenarios. Excess details can sometimes lead to redundancy and you don't want to have to go through a 5,000 IRP book containing 25 different ransomware scenarios just to find none of them fit your exact situation. Keep details light and focus on the broad strokes, especially in the early stages. You can always add more detail later.
How often should I revisit my plan?
An IRP is a living document. As your business grows and changes, so will your IRP. While some situations will never change, the response to them may. We recommend revisiting your plan at least once a year, but more frequently is even better. Early on, you may find it's better to work on it once a month until it reaches a more mature level, at which point you can dial back the cadence a bit.
Another important time to revisit it is after any sort of situation actually occurs which is, or should be, in your plan. Did you have an entry in your plan for what happened? If so, how did your plan fare? What did well? What could be improved? If not, what did you do throughout the scenario that worked and can be implemented into a plan for next time? What should you do different to help mitigate or prepare? Turn those lemons into lemonade!
Who should I have help me with my plan?
This is an excellent question. Creating an IRP is a daunting task, especially if you try to go at it alone. A good starting point to deciding who should be involved with creating the plan is determining who will be the major players in some of the scenarios it contains. Some examples would be any business partners or C-level execs if you have them. Any departments which may be affected (accounting, engineering, etc). Do you have a business advisor or coach? Bring them in and ask them about it. If you're a smaller, one-owner/sole-prop company, consider bringing your spouse or other close relative into the process if part of the plan may involve them (especially important when it comes to personnel issues).
And while an IRP doesn't strictly pertain to IT. A good IT partner can be a major benefit as technology is intertwined in just about every aspect of modern business. For example, we've helped many of our clients make sure they are set up to be able to efficiently execute their IR Plans in the event they're needed, even helping perform "dry runs" of different situations to help spot issues or weaknesses and help bolster their overall strategy. IRPs can be a daunting task at first, so don't hesitate to reach out for help if you think you need it.