We typically look toward disciplines such as social media, mobile computing, cloud, the Internet of Things and...
geospatial technologies, as the drivers and enablers of our increasingly digital world. These technologies are profoundly impacting how we work, live and play, often blurring the lines between those traditional modes of managing our work-life balance.
As we become more "digital by nature," we also become more dependent upon data and, in some ways, less dependent upon applications. In our workspace, the trend seems to clearly be moving away from large expensive bespoke applications in favor of off-the-shelf, in-the-cloud or software-as-a-service modes of processing. In our personal lives, we are seeing an explosion of free or inexpensive applications designed to occupy our increasingly available leisure time, pay our bills, track the status of our travel plans, monitor our health and fitness, order our food and meals, and soon even drive our cars, to name just a few.
According to Statista, as of July 2015 there were a combined total of almost 4 million applications offered through the app stores of Google Play, Apple, Amazon, Windows and Blackberry. That's a lot of Angry Birds but, more importantly, bespoke applications have commonly evolved into near-utilities and, most importantly, the intrinsic value of the technology is increasingly becoming less about the process (the application) and more about in the data.
Disaster recovery/business continuity plan and cyberthreat landscape
The need to manage and protect both business and personal data (as clearly differentiated from the software) has never been more important. A disaster recovery/business continuity plan that does not account for our dependence on data puts the enterprise, its employees and customers at risk.
Consider this trend in the context of an increasingly dangerous cyberthreat landscape, courtesy of the Identify Theft Resource Center. As of December 29, 2015, 177.8 million records were exposed by 780 breaches last year.
Looking at these recent incidents of identity theft (a major intersection of business and personal data), it becomes clear that having a well-designed disaster recovery/business and personal continuity plans at the ready is critical to the health, vitality and sustenance of our work, our lives and even to our play.
According to the Insurance Information Institute, an official website of the Department of Homeland Security, approximately 40% of businesses struck by a significant disaster never resume operation.
Most readers will be relieved to know that I have absolutely no intention of using this space to outline the key elements of a disaster recovery/business continuity plan. There are many great resources available that will provide that information in much more detail than time or space permit here.
I felt that it would be more valuable to you to share a few principles and practices that I have employed throughout my time as a technology executive and enterprise leader that might help you to design, implement and/or refine a better plan for when (not if) disaster strikes next.
Disaster recovery/business continuity plan: Best practices
- A good disaster recovery/business continuity (DR/BC) plan is not a deliverable, it is a collection of artifacts that represent the state of things at a point in time within an ongoing carefully managed process. You cannot treat the creation of a DR/BC plan as a once and done piece of shelfware that is created to satisfy an audit requirement. If you do, both the plan and your job will likely have a short effective life span.
- A good disaster recovery/business continuity (DR/BC) plan is not an IT plan, it is a business plan that has significant IT components. As discussed above, more and more focus needs to be placed upon data recovery beyond ensuring that programs and processes are returned to operational status. The plan should be scenario-based and aligned to the likelihood of varying levels and types of risks as specified by documented business impact analyses and business risk assessments.
- A good disaster recovery/business continuity (DR/BC) plan must include explicitly prioritized goals and performance objectives that can be articulated in both quantitative and qualitative terms. The Department of Homeland Security recommends the following objectives as guidelines:
- Protect the health and safety of people (employees, visitors, contractors, etc.).
- Minimize product/service disruption.
- Protect facilities, physical assets and electronic information.
- Protect the organization's brand, image and reputation.
- A good disaster recovery/business continuity (DR/BC) plan must be an end-to-end plan that usually begins and often ends with a customer or significant stakeholder, not with the execution of a program or update to a database. Just because the system is up and running does not mean that staff can get to work or customers can get to the point of sale, e.g. following a hurricane or blizzard.
N.B. Before there was mobile banking via the Internet, I was involved in a DR/BC effort at "BigWorldBank," as I refer to it now, where, following a major hurricane that devastated significant portions of the South, the CIO arrived at the CEO's office triumphantly proclaiming "... all our branches are up and running!" We all looked at him as if he had lost his mind. What he should have said was "all of our branch technology is functional but, because of the storm, roads are washed out and bridges have collapsed and none of the staff can get to work nor can customers reach our branches." Together we formulated a plan to put branch systems and ATMs on semi-tractor trailers and bring the bank to the customers, thereby creating the first truly mobile bank!
- A good disaster recovery/business continuity (DR/BC) plan must include all critical aspects of the supply chain as part of the end-to-end process. Having the assembly line up and running is not terribly useful if there aren't parts available to feed the manufacturing process.
- A good disaster recovery/business continuity (DR/BC) plan must include a robust communications plan to ensure that all appropriate levels of internal management, customers and external stakeholders can be notified as quickly as possible so that their expectations can be effectively managed. Clearly, minimal disruption to key stakeholders should be a major objective of any good plan.
- A good disaster recovery/business continuity (DR/BC) plan must be regularly tested and tests should include all aspects of end-to-end business processes, IT readiness, facilities readiness and staff readiness. All phases of each test should be well-documented including those aspects that succeeded as well as those that failed. Post-test results should be discussed by business and IT and discussions should explicitly address areas for improvement.
- A good disaster recovery/business continuity (DR/BC) plan must include appropriate budget to carry out the necessary testing and plan enhancements that are identified. The establishment of a DR/BC oversight committee and the appointment of a program coordinator are standard practices in most organizations.
- A good disaster recovery/business continuity (DR/BC) plan must meet regulatory requirements. These baseline requirements will differ by industry and should be thought of as the minimal acceptable plan. In many organizations, meeting regulatory requirements is considered necessary but not sufficient.
- A good disaster recovery/business continuity (DR/BC) plan must be explicitly covered within documented and officially accepted enterprise standards, policies and procedures. Documentation regarding all aspects of the plan, testing and implementation, enhancement and on-going maintenance should be made available for review and comment by internal and external auditors and regulators, as appropriate.
Let me know what you think. Post a comment or drop me a note at firstname.lastname@example.org. Discuss, debate or even argue -- let's continue the conversation.
Recent SearchCIO columns from Harvey Koeppel:
ITSM roadmap for a digitally-enabled business environment
CIO checklist for protecting the cyber-landscape