6 Ways to Create an Incident Response Plan That’s Actually Effective

By Mike Wilkinson

By Mike Wilkinson

Mike Tyson famously said, “Everyone has a plan until they get punched in the mouth.” That applies to the world of boxing—and to the world of cyberattacks. Many companies have an Incident Response (IR) plan in place. But those plans don’t always hold up when an actual cyberattack occurs.

At Avertium, we carry out hundreds of IR engagements a year, so I’m highly familiar with what makes IR plans useful—and what doesn’t. Strong IR plans can help eliminate headaches and wasted time and help your organization more effectively respond in what is typically a very stressful situation. Here are six things you need to do to craft an effective incident response plan.

  1. Establish your escalation points. One of the most useful parts of an IR plan is guidance on your escalation points. That is, “If we reach this point, these are the people we need to contact and these will be the next steps.” It provides the triggers that will cause the next level of action.
  2. Include contact information. It’s a common scenario: A company suffers a breach and needs outside help. Someone in IT places a phone call and gets asked whether the company has cyber insurance. They know it does … but the finance team purchased it, and the IT department knows nothing about it. That’s an avoidable situation. Your IR plan should contain the contact information for everyone who might be needed, from your service providers to key employees to outside counsel to, yes, the insurance provider.

    The list of contacts should appear in an appendix at the back of the plan, which makes it simple to consult in the heat of the moment, as well as easy to update. Elsewhere in the document, use generic titles rather than names so that you don’t have to refresh the entire document any time an employee or vendor changes.

  1. Define the communication parameters: One incident sticks in my mind. A client detected a ransomware outbreak on a Friday night and called us by Sunday afternoon. They had been working on the issue for 40 hours straight, or so I thought. It turned out that senior management’s understandable concern about the situation had caused them to hold hourly update calls, meaning the tech team was unable to focus and work on investigating and resolving the incident for more than about 30 minutes at a time.

    Define how information and updates will be shared, to whom, and how often. Set the cadence up front so that expectations can be managed: For instance, a daily update call unless something critical is uncovered that requires action on the part of a larger group.

  1. Word choice, and word count, matter: Avoid too much legalese or language that’s tough to parse. Keep it readable. Consider using bullet points. Look for the happy medium between an IR plan that’s overly brief and sparse and one that’s too lengthy, where you have to read through 10 pages of instructions before you can get anything done.

    Keep it as simple and precise as possible: for X type of incident, Y is the response group and their responsibilities, and Z are the steps they take. Consider having a one- to two-page high-level policy that sets out your organization’s principles—the things the business is most concerned with.

  1. Get broad input: When you’re writing the IR plan, get input from all the stakeholders. That sounds basic, but I’ve often seen plans where it’s obvious the legal or risk team put it together without consulting others. It needs to contain more than just the technical or legal response.
  2. Give it a test run: Practice makes perfect. Once you think you’ve got it, practice your plan. Pick some scenarios and work through them using the plan to figure out whether it works or not. You may run across systems that maybe haven’t been identified or people whose contact details you didn’t include.

These exercises can also be valuable ways of unearthing issues unrelated to the IR plan. For instance, in working through a ransomware scenario your IT team may realize there is sensitive information being stored on a system where it shouldn’t be, or that the data retention time isn’t adequate considering the amount of time that can pass between compromise and detection. It may highlight an opportunity to make a fix or fixes that will actually make you less vulnerable.

Being hit with a cyberattack can be a scary and confusing time; coming up with an IR plan shouldn’t be. If you let the above tips shape your process of creating or updating one, you’ll be in good shape.

Mike Wilkinson leads Avertium’s Cyber Response Unit, which is dedicated to helping clients investigate and recover from IT security incidents on a daily basis. He has been conducting digital investigations since joining Australia’s NSW Police Force, State Electronic Evidence Branch in 2003, where he led a team of civilians in one of the world’s largest digital forensic labs, and has led Incident Response teams in Asia, Europe, and the Americas.


No posts to display