If you’re following security and compliance best practices, you know that you need a business continuity and disaster recovery (BCDR) plan in case a disaster occurs. What you might not know is how the hell you’re supposed to put together a robust business continuity plan without losing your mind.
It’s possible to do the bare minimum and basically follow a fill-in-the-blank template — which is certain to leave you at risk. It’s also possible to go down the rabbit hole into a never-ending universe of scenarios to prepare for.
Neither option is optimal for your business or your personal well-being. Instead, I recommend a process that gives you the level of detail you need without overdoing it. While this won’t be a quick and easy exercise, it will give you the greatest results for your time — and you’ll be able to sleep well at night knowing you have a usable plan.
Let’s take a look at the best practices that TCT recommends.
Identify Your Business Lines
What are the various business lines of your organization? Let’s say your business has an e-commerce platform, provides several services, and has a call center. There’s also your corporate headquarters and operational facilities to consider.
Potential disasters could be very different across each of those business lines. Organize the major elements of your business and identify the various realms that you need to focus on for your business continuity plan.
Review Your Operational Structure
When a disaster occurs, your business could be interrupted in any number of ways. You’ll need to identify how business happens within each of the lines of business you identified earlier.
Create (or dust off) the following documentation:
- Network diagram. A physical, logical network diagram shows how all your assets are related to the business line that you’re analyzing.
- Data flow diagram. This shows what data is coming from where, who it’s processed by, where it’s going, how it moves, and where it’s stored.
- Vendors and third parties. Identify who is involved in a particular line of business so that you can have coverage for each of your service providers.
After you’ve taken a first pass at these documents, interview the personnel who are part of these various workflows. Ask them to review the diagrams and vendor lists. Is there anything incorrect or missing? Are there functions that haven’t been captured?
Review Your Organizational Structure
The operations and infrastructure are only part of the equation. Your people are your most important factor in the daily running of your business. Whether it’s the janitor or your CEO, each person plays a key role to keep your company functioning.
Review the organizational structure of your organization. What happens if the people in various roles suddenly aren’t there one morning? What do you do then? Who takes over for this or that role? Is there important information that the person in this role has that no one else has?
The idea is to look for single points of failure, not only in terms of operations but also in terms of knowledge and data.
Identify Risks and Responses
At this point you’re ready to put together the compendium of all your analysis — and it’s going to be a lot. This is when the real decision-making comes into play. You’ll need to figure out how to package it all up in a way that’s usable and not overwhelming.
You don’t want a 1,000-plus page document with every possible scenario known to man. Instead, the final document should be an easy-to-use guide that tells you clearly and simply what to do if specific scenarios occur.
Create categories of disasters, or levels of incidents, with some type of description that allows you to delineate between categories or levels. Maybe level 1 is the holy crap level — for example, your entire e-commerce platform just went down. And maybe level 4 is the red flag level — such as some suspicious activity that should be investigated, undetermined if it warrants an alarm.
Once you have your categories and levels, take all the information you’ve assembled and slot it into that framework. As you do this, you may find that your categories and levels need some refining, and this will be an iterative process as you work through it.
For each category/level, create a simple framework:
- Personnel and roles involved
- Actions to take
- Reporting structures
Balancing all the risks that you identified and putting them into categories and levels allows you to organize your approach for BCDR incident response in a way that’s sane and clear.
Use TCT Portal for a Business Continuity Boost
How Much Is Too Much?
How do you know if your business continuity plan is detailed enough without going overboard? If you download some online template and essentially just fill in the blanks, you probably aren’t doing enough.
On the other hand, if you find yourself generating unique, scenario-based documentation for each individual scenario or risk, then you’re probably going down the rabbit hole.
You should be able to find multiple scenarios that can be handled with a similar framework. Group them into the same category and move on. Start with scenarios that you’re most likely to encounter. Once you find yourself planning for scenarios that require some major assumptions, you’ve probably reached the stopping point.
One thing to remember: you don’t have to have your business continuity plan finalized all at once. Do your due diligence in year one to get the most critical scenarios in place, then continue to work at it on an ongoing basis (at least a semi-annual regroup, but preferably quarterly). And always review your plan annually to make sure everything is still relevant.
Certainly, as you declare incidents ranging from fit hitting shan down to investigation needed, perform post-action analysis to determine whether you need to enhance your existing plan documentation.
Creating a proper business continuity plan isn’t easy or quick. That said, I recommend spending the most time in the discovery and analysis activities so that you can translate it into something robust and useful for your organization.
Get equipped with insider expertise
Subscribe to the TCT blog