It’s a day like any other. You stopped to get your coffee and muffin on the way to the office, and you’ve been reviewing and answering email all morning. Suddenly you’re being inundated with alerts indicating some sort of problem in your production systems, which could mean none of the people in your office can access the resources necessary to their work. Or worse, your customers may not be able to access your application, or e-commerce site. But you’re keeping it cool, because you know you’ve got a Business Continuity Plan in place for an event like this, and the applications and services may already be up and running on your stand-by systems. From the customers’ or workers’ point of view, there may have not been any interruption at all. Right?
Creating a Business Continuity Plan (BCP) takes time, and resources, but in the long run, it’s in your company’s best interest to have a plan for how to respond to various threats, such as fire, flood, cyberattack, power outage, single point of dependency and more. And it’s not just a one-time thing. It needs to be continually tested, verified and updated as your organization evolves. Business interruptions can be costly, in lost revenue, lost work, and potentially loss of reputation.
Steps to Creating a Business Continuity Plan
There are several steps to this cycle of planning:
- Solution Design
- Testing & Acceptance
(Image borrowed from Wikipedia)
During the analysis phase, there are several areas to be aware of.
- Do you have a current inventory of equipment, both physical and virtual, upon which your business applications are running, or are being hosted.
- What applications and databases are running, and on which equipment?
- Where are the points of failure in this stack? Who are the vendors involved, or other necessary suppliers?
- Is this all documented, and backed up, with off-site copies?
Now that you have that information in hand, what would be the impact of a service disruption? Hopefully you’ve already done the work to determine your Recovery Point Object (RPO) and Recovery Time Objective (RTO) , which help determine what that impact is, monetary or otherwise. What kind of threats might your organization, or it’s data, be subject to? Consider external and internal threats; natural disaster, human error, equipment failure, corrupted data etc.
Armed with the information gathered during the Analysis phase, you can now design your solution. This can consist of multiple levels, depending on your business needs. SHARE (a volunteer-run user group for IBM mainframe computers) created seven tiers of disaster recovery in 1992 that outline levels of preparedness. This may start with creating high availability systems in your environment; if one server fails, there’s another to pick up the slack. On the other end of the spectrum are highly automated solutions that allow systems and applications to be restore much faster and more reliably than a manual disaster recovery procedure.
Now that you’ve planned out your design, you have to build it. This includes acquiring the materials required (hardware, cloud, complicated facility or hosted datacenter etc.), installation, documentation, training, and adding staff if necessary.
Testing & Acceptance
The solution now needs to be tested, verified and accepted by the organization. Testing can consist of tabletop exercises where a small group focuses on a specific aspect of the BCP, medium exercises where several teams focus on multiple pieces of the BCP, or complex exercises where there is no warning given and an actual disaster recovery is completed.
During a complex exercise the applications and data should be tested and verified to be accurate and working properly. Each test is an opportunity to verify that the process is accurate and complete, that all necessary information is gathered in the appropriate place, that the proper notifications have been made at the appropriate time and an estimate of how long the process takes.
Now that you have the wrinkles ironed out, it’s important to keep your BCP up to date. This is accomplished by reviewing the documentation included in the plan and updating as necessary for accuracy, reviewing it with staff, and training staff as required. The solutions used must be tested and verified, as well as the procedures used for recovery. This should be done at least once, or twice a year for best results. Documentation should be updated at these times with information regarding who is responsible for completing which tasks, new terminology that should be defined in the policy, updating distribution lists as needed and any other important information. In addition to the maintenance tasks involved with the BCP, there’s also the maintenance of the environment, to include anti-virus updates, security patch deployments for applications and operating systems, and hardware and application monitoring.
Having a Business Continuity Plan is critical to keeping your business functioning and growing, no matter its size. At iuvo Technologies, we understand the importance of your business and are ready to help keep your business growing. Please contact us with any questions you may have. We are happy to help.