Edit: If you missed the LIVE show, don’t worry. We recorded it for you and have the video embedded at the bottom of this post. Or, if you prefer, listen to the podcast version on Apple and Spotify.
When our customers are going through Business Impact Analysis (BIA) it’s pretty common for them to ask us for guidance. They want to know what we’ve learned from others so they can avoid some mistakes.
We hope the information below is helpful and we’d love to hear your feedback.
Without question, the following are the top 3 most common mistakes we’ve observed from teams going through a BIA. The bad thing about these mistakes is that they end up being very costly to the organization and to the people involved.
Course-correcting after these issues takes real budget and time. For some, these have led to a false sense of security that left them open for cyber attacks and disrupted operations. For those in risk management leadership, careers have even taken a side-step because these mistakes were not caught quickly enough.
We don’t want to scare anyone, but we do want to point out that there are real consequences with these things and they should be taken seriously.
1. Be brutally honest through the whole process.
We should state upfront that we’re not talking about malicious dishonesty here. What we typically see (because it always comes out later) is that someone wasn’t completely honest about how much improvement was really needed in a certain area. Or just how broken something actually was. Or that something was completely missing, had never been done, or just hadn’t been done in a while.
You can chalk this up to a bunch of different reasons. Culture in the company, politics, pride, or someone just simply deciding they don’t want to work on that thing.
Before the BIA process gets going, everyone needs to come to an agreement that the findings in the process are not a judgment on current employees or past employees. The BIA shouldn’t be a positive/negative judgment at all. It should be accepted as the state of which things currently are. A starting point for moving forward. That’s it. Figure out what’s working, not working, broken, missing, needs updating, etc. Then prioritize and assign next step tasks.
This should be the first thing you put serious time into with those going through the BIA process.
Leaders should make every effort to make sure their teams understand they can be fully honest and transparent. If this can’t happen, your BIA is flawed from the very beginning and you will most likely miss some of the most important risks that should be focused on.
2. Not documenting stated goals.
The point of going through a BIA is to understand where the risks are, and how they should be prioritized so that everyone is working towards a common goal. During the process, many goals associated with the outcome of the BIA may be discussed. If they’re not documented and agreed-upon, there is a high probability of many people leaving the process with different understandings of what the group as a whole should be working towards, and what each of them individually should work on first.
Documenting goals as “top 3 items” for a BIA process may seem overly simple, but we see this skipped all the time. Everyone leaves the BIA process thinking that everyone else is on the same page as they are. But, in fact, they all have a slightly different understanding of what the goals and next steps are. This leads to wasted time in areas that may be a low priority to company leadership and leaves top risks exposed.
3. Not discussing risk tolerance and choosing an improper risk level.
Before an assessment begins and risks are discovered, the group should come to an agreement on how to score risk and rank it for prioritization. This means coming up with a scoring system that is based on your particular business context. Business context includes the goals of your company, how critical a particular entity is to operations, and how tolerant of risk the business leaders are at that time.
While this document is specific to IT security, this guide from The University of Iowa is a great template to help you get started with your threat matrix (scoring system). Some questions you may ask when discussing risk tolerance for critical infrastructure might include:
- Does this entity have physical access to your facility?
- Does this entity provide services critical to operations?
- Does this entity have a direct remote connection into the company’s network?
Risk tolerance is going to be different in every organization. It’s something that will change and develop inside each organization as company culture evolves, or when regulations get updated, the economy shifts, and a long list of other variables. It’s important to discuss this and acknowledge the tolerance of risk in some areas and lack of tolerance in others.
Just like with tip number 1, this needs to be documented. If the discussion doesn’t happen, and the ranking/scoring system isn’t documented, you’re going to end up assigning risk scores that are higher or lower than they should be. You and the other teams involved will end up putting time into lower priority areas that should be invested elsewhere and, once again, leaving the door open to unwanted cyber activity in critical areas.
Conclusion
We hope this post was helpful. If you’ve never run a business impact analysis and you feel stuck on where to get started, this National Institute of Standards and Technology (NIST) doc will be helpful. Essentially, the document teaches you how to know what area of the business to focus on first, find the risks there, and understand how to know when you’ve hit your goals.
Hint: skip to Appendix B near the end of the doc and you’ll find specific info on running a BIA.
If you’d like to learn more and ask questions, get a calendar invite for the 20 minute AMA session on August 5th here. We’ll be looking forward to seeing you there.
