A continuation of sorts…
As we further consider the elements of the NIST CyberSecurity Framework (CSF) from Michael’s multi-part series, it is helpful to perform a deeper dive into the ideas of Respond and Recover (the last two elements of NIST CSF). If you haven’t read that series, you may want to check that out first: https://choosetcs.com/2022/01/19/nist_csf_guide/.
Business Continuity spans both Respond and Recover while, as its name suggests, Disaster Recovery is the plan to be used in the “worst day ever” type scenarios and lives in the Recover CSF category. Before we go further, I want us to stop for a second and nail down some basic terminology. You may be thinking at this point, “What is the difference between Business Continuity and Disaster Recovery?” Glad you asked. We often hear these used almost interchangeably, but they are distinct concepts. Even so, they are somewhat like peanut butter and jelly as BCDR is to PBJ. We think of them as one thing. Using the definitions from FEMA, Business Continuity as “The ability of an organization to provide service and support for its customers and to maintain its viability before, during, and after a business continuity event.” Further, it defines the Business Continuity Plan as “Process of developing and documenting arrangements and procedures that enable an organization to respond to an event that lasts for an unacceptable period of time and to return to performing its critical functions after an interruption.”
And since we will later address Disaster Recovery, let’s consider the following definitions. A Disaster is “A sudden, unplanned calamitous event causing great damage or loss. In the business environment: any event that creates an inability on an organization’s part to provide essential products and/or services for an indefinite period of time.” And a Disaster Recovery Plan is defined as “The management approved document that defines the resources, actions, tasks, and data required to manage the technology recovery effort.”
If you are a regulated business, you must have these plans in place. If you are non-regulated (does that even exist these days?), you would be well served to have these plans in place anyway. Increasingly, TCS is seeing these requirements called for in underwriting Cyber Insurance policies, so this and other security & compliance risk reduction measures are not viewed as optional in today’s cyber threat landscape. And unless you are just looking for a different career path altogether, we cannot emphasize enough the necessity to invest the time to get this right. The oft quoted statistic of “40%-60% of small businesses never reopen after a disaster” applies here.
The first step in solving any problem is recognizing there is one.
Your organization is at risk and you may not even know it. Do you have an up to date and tested Business Continuity Plan? If not, you may be missing critical details to keep your business running through a disaster. This is not a technology problem and is not the responsibility of your IT department (on staff or outsourced). This is a strategic imperative which much be owned from the top down. In short, it’s a business problem and risk reduction initiative.
The good news is if you are reading this, you are most likely not trying to restore order from chaos due to a disaster. But this doesn’t mean you should be comfortable with the status-quo. The calm BEFORE the storm is the best time to prepare. We often don’t see the disasters coming miles ahead.
TCS is not only experienced in developing and testing these plans, but in managing its clients through the worst possible events that can easily cripple a business – pandemics (we’ve got the t shirt), ransomware/crypto locker (check), server room floods, power outages, you name it. And believe it or not, you don’t have to reinvent the wheel to put your plan together. That said, your plan will not be cookie-cutter and must address your specific requirements. TCS recommends taking advantage of our Compliance as a Service (CaaS) program to provide fixed-fee consulting support for this and other regulatory compliance needs.
Whether you engage with TCS or do this yourself, be sure to allocate regularly scheduled time week over week. This is not something that will be assembled in a day and the effort will become part of your ongoing business process, not simply a dusty document in a binder on the shelf. It could take a few months the get through this the first time, but the important thing is to make steady progress and not think of business continuity planning as a box to check. It will be an iterative process and you will revisit, test, and update the plan at least annually. So put on a pot of coffee, roll up your sleeves, and let’s go.
I’m from the Government, and I’m here to help!
DHS has a government produced Ready.gov site with a useful Business Continuity Planning Suite. It can be downloaded here: https://www.ready.gov/business-continuity-planning-suite. When I first found this tool my thoughts turned to the famous President Ronald Regan quote, “The nine most terrifying words in the English language are, ‘I’m from the Government, and I’m here to help.’” In this case the government is quite helpful. This is a simple and effective tool and my next few articles will walk you through the process of developing your own Business Continuity Plan.
Now you could stop reading here and simply follow the steps outlined in the software. It’s actually a straightforward, but lengthy, process, so plan to do this in bite-sized chunks and not all in one week. The more thought and consideration paid to your business functions/data, personnel, and technology, the better aligned your plan will be with your needs when things hit the fan. This series of articles will highlight where to slow down and pay attention and where shortcuts can be made.
There Is No “I” In Team
The steps for building your own Business Continuity and Disaster Recovery plans will be covered in more detail in upcoming posts. A good idea for now is to assemble a small team for developing your plan and then you can divide and conquer the various tasks which we will outline later. Also, a smaller organization will end up with more overlap of roles and fewer teams defined within the plan, but to get things started, a small group with an Executive/Owner sponsor should lead the effort. This is a top-down strategic (company-wide) initiative and not something to be led from your IT group. They will be instrumental from an operations standpoint, and will need to be involved in development and (ultimately) executing the plan, but they will not have a complete view of your organization’s priorities, critical functions, and workflows.
Next week we will move on to installing the tool and familiarizing ourselves with the application so we can start making progress on developing the plans.
