Creating an Incident Response Plan
- Written by: Ben Hall and Sammi LaBello
Is your business ready to handle a security threat? The more our Consultants talk with businesses from across the country, the more we find a lot of them don’t have an Incident Response Plan. If they do have one, it’s very minimal. Unfortunately, this is becoming the norm.
Creating an Incident Response Plan is more than just creating a peace of mind; it will also be a critical component in restoring what’s lost during a cyber-attack. Taking the time to prepare now will save you time, money and stress down the road.
Keys to an Incident Response Plan:
The Importance -
First, you probably want to know why you need an Incident Response Plan. Think of it as reassurance that in the case of an emergency fewer things are likely to go wrong. If a disaster occurs and you don’t have a plan in place, how will employees know what to do? Even if one person knows the protocol, you can’t rely on them being there every day. This checklist of do’s and don’ts will give staff a sense of control and confidence when they may have to face a crisis alone. It will also give management more freedom to leave the office without fear of total chaos while they’re away.
Second, if your business is a critical resource and you don’t have an appropriate plan in place, it could have a ripple effect on others. You could potentially lose revenue or harm customers. In turn, that may impair your reputation and cause long-term damage to your business.
Who Needs One -
The easiest response for this one is – Everyone! The exact plan will vary depending on the size of your organization and the level of risk you face. If your company has a lot of sensitive data, that means your security risk is higher. In that case, you want to have a very detailed Incident Response Plan in place. Larger businesses may be required to have an Incident Response Plan in place to meet a regulatory framework.
Every business needs to evaluate all levels of information security and who has access to sensitive data in order to determine what their plan should look like. There’s no “one size fits all”, but there are some good guidelines to follow!
What It Should Look Like -
This has been made slightly easier thanks to the National Institute of Standards and Technology (NIST) They have a checklist of how to handle an incident. (You can find that on Page 42 of the document linked here.) These basic guidelines are very helpful to anyone looking for some introductory guidance.
To prepare an Incident Response Plan, ask these questions about your business:
- Who are the critical staff?
- What resources are available?
- Who are the primary and secondary contacts?
- What is the backup process?
- How quickly would you recover from an incident?
- How could an incident impact future business?
If you can’t readily answer these questions, that’s a good sign you need to start working on an Incident Response Plan. While the variables will differ from one business to the next, the basic principles remain the same; know who’s in charge, what to do, who to contact, and how to handle the aftermath.
How to Prepare -
Before implementing an Incident Response Plan, there are a few things you should do to prepare. First, let your staff know what’s happening. It’s important they understand why the plan is being built. They should also be given the specific guidelines as to what their role will be during an incident. If necessary, there should be plenty of training involved. The pertinent staff should also be involved in the creation of the plan. The more involved people are in the process the more likely they will be invested in executing the plan when an incident comes up.
How to Update -
Your Incident Response Plan needs to be reviewed at least once a year. That’s also when you should be performing a test to make sure the procedures and people involved are prepared. Testing will help reveal any weaknesses in the process before real damage is done from a serious security threat.
While an annual review is important, you also need to do updates and reviews after any incidents that occur. If something goes wrong, it’s the perfect time to update and adjust the policy.
Recovery Process -
One of the biggest benefits of having an Incident Response Plan is having the steps laid out for the recovery phase. After a security incident, you may be stressed out and overwhelmed by what just happened. Being able to rely on an established plan will help keep you on track of what’s going on and focus on the tasks at hand.
A big component of recovery is the initial response. Be sure to isolate the affected system or systems to stop additional infections and prevent additional data theft. Disconnect the asset from the network. You should also start running scans and potentially run digital forensics (link to forensics page) checks to see how far the attack went and where it came from. Also, consult your legal or compliance team to review any regulatory impact that could also pose irreparable harm to the organization.
Encourage your employees to report problems right away. Affirm they won’t be in trouble for sharing what they discovered and that they’re helping the company by reporting any incident in a timely manner. Give them a channel to follow and train them on where and how to report properly.
Review the Aftermath -
After you’ve contained the problem and reported to the proper channels, an Incident Response Plan should also include steps for reviewing the aftermath of an incident. This is the time you go over the questions like, what went wrong? What went right? You should also establish a timeline of events to help answer these questions and see the bigger picture.
Reviewing the problem shouldn’t be your last step. Adjusting your Incident Response Plan should come next! As we discussed during the Update section, you should be making changes to your plan after any incident. If a step in the process didn’t go as planned, figure out why and start making changes.
If you need help setting up your Incident Response Plan, our cybersecurity experts work with organizations of different sizes and security needs.
