Having strong, tailored business continuity (BC) plans in place are critical to a business’ survival. But it’s not just enough to have them in place. They must also continually evolve in step with your business.
Most companies recognize the importance of performing a business impact analysis (BIA) prior to creating a BC plan. The BIA identifies core business activities, the cost of disruption to each of these processes and the resources needed to support them. What most companies miss is how regularly they should be conducting a BIA.
According to a recent Forrester report on the State of Disaster Recovery Preparedness in 2020, most organizations don’t conduct BIAs with any consistency. Instead, they’re treating it like a one-time practice or something that can be done sporadically. That’s a mistake.
Here are five reasons why you must perform a BIA on a regular basis.
1. Uncover new and updated application interdependencies
BIAs establish your organization’s key products and services and determine the impact of a disruption. But it also goes beyond that – to the application interdependencies.
Your main applications are likely built around other supporting applications that allow them to function successfully. If you remove one of those supporting applications from the equation, your main application won’t continue to operate properly.
If you’re not mapping out these interdependencies, then you don’t know how the failure of a particular application may disrupt your other applications and key business processes. The same goes for adding new technologies to your environment. The more Software as a Service (SaaS) solutions you have, the more external dependencies you’re reliant on. And that increases your potential points of failure.
Performing a BIA helps you get to the bottom of that – you can identify the resources that key activities depend on, determine their respective availability requirements and address them as needed. Regular BIAs track the evolution of those interdependencies as you add, subtract and alter applications so your BC plan is always up to date.
2. Understand third-party vendor risk
While a BIA focuses on your own applications and facilities, it also looks at the third-party vendors you work with – particularly the ones you depend on.
What would happen to your business if one of these vendors had a disruption? Do they have a BC plan in place? Have they tested it? If not, how would their downtime impact your organization’s regular workflow, and could you still perform your day-to-day duties without fail?
Just like your applications and systems change over time, so do your vendors – and we’re not just talking about replacing one vendor with another. Their own interdependencies and BC plans are constantly evolving as well. If you’re not keeping up with these changes, then you’re putting yourself at risk.
You need to know that your third-party partners will be there when you need them. A BIA evaluates your third-party risk to determine any blind spots that might put your organization in jeopardy. The more your vendors change, the more you need to stay on top of them.
3. Calculate the cost of downtime
Not only do you need to know what your key applications are, but you also need to know how their downtime affects your business. The cost of a disaster is often tied to duration.
What happens if you lose a core application for a few minutes? What about for a few hours? The two incidents could have drastically different effects on your business.
Because some applications are more critical, tiering them for recovery can reduce expensive downtime – Tier 1 is reserved for the most critical applications, followed by Tier 2 and Tier 3.
As your organization evolves, so will your mission-critical applications, and you need to constantly re-evaluate your recovery strategy using a BIA.
That way, you can identify the impact levels – based on time – for each event, determine the necessary recovery objectives, create strategic recommendations for increased business resilience and availability, and put these practices into place.
4. Factor in new applications or consolidate resources
How critical is a new application to your business? How does it fit into your recovery strategy? What are the new interdependencies?
When you roll out new applications, everything changes. New applications tend to have tentacles that reach into all your processes. If you don’t stay on top of these changes, then you won’t know how a disruption might impact your key business activities.
The same goes for the consolidation of your systems, environments and facilities. For example, it’s likely that your BC plan relies on multiple buildings. If you shut down one location, you may have removed an entire contingency plan.
Conducting regular BIAs will help you stay mindful of how adding or reducing resources affects your overall resiliency.
5. Tie business needs to IT’s resilience posture
Performing BIAs gives the business side of the company a chance to weigh in on what IT and vendors are doing to support them, from the tiering of applications to contractual guarantees from critical vendors.
For instance, if the business side requires certain applications to remain available, a BIA will show whether they’re in the cloud with real-time backup and replication as a Tier 1 application should be. The same level of criticality can be weighed and measured against vendors as well, ensuring there’s either a guarantee of availability or a secondary vendor to serve as a backup.
BIAs confirm that IT’s resilience posture properly aligns with your current business needs.
Disruptions come in all shapes and sizes. Many of which you cannot control. The only thing you can control is how prepared you are when they do inevitably happen.
If you want to lessen the effect and duration, you must continually update your BC plans as your business changes. The first step to achieving this is with a BIA. It helps you identify key business processes and application interdependencies, while determining what it will cost your organization if any part of your business goes down.
But a BIA is not a one-off activity. It must be conducted regularly to address any changes to your environment, including the addition of critical applications, switching vendors, consolidating facilities or systems, and more. Only then can you ensure your organization is resilient enough to withstand anything that comes its way.