Every company needs an up-to-date DR/BC plan

Disaster Recovery (DR) and Business Continuity (BC) planning must be more than a business school exercise or something reserved only for the largest or most heavily regulated companies. Gartner reports that 40 percent of small and midsize organizations go out of business if they cannot get to their data within 24 hours following a crisis. The US National Fire Protection Agency found that 43 percent of companies never resume business following a fire. Those numbers would be lower if more companies maintained current DR/BC plans and tested them regularly.

For the purposes of this article, let’s consider the following definitions:

• Disaster Recovery — the ability to restore critical IT business functionality and data after an event or chain of events that have rendered a company unable to perform critical business operations.
• Business Continuity — the ability to provide a minimum level of business operations in the face of any event, whether planned or unplanned, that disrupts the normal course of operations related SOP.

Planning before disaster strikes

Once a problem arises that can shut down your business, it is too late to start DR/BC planning. When an emergency hits, you need the right people and the right data in the right places fast. The IT team could be working in different locations with different systems and tools. To do this right, they will have needed the chance to practice before facing the real thing.

Finally, you need to plan in advance how people will communicate. In an emergency, the usual lines of communication are disrupted. Setting up alternative means of communications and informing those involved takes time.

DR/BC planning is NOT a technology problem

Today’s technology options for midsize and small organizations include:

• Readily available, low cost, disk-to-disk systems and virtual tape libraries
• An increasing number of cloud-based and managed service options
• New communication options including cellular, WiFi, Blackberry/smartphones and social networks

A lack of technology does not hinder recovery from an emergency; rather, it is a lack of planning. If the technology isn’t ready when an emergency hits, it is because no one planned, prepared, followed through and tested it.

Six mistakes that hobble disaster recovery

DR/BC planning is a serious enterprise business planning initiative on which the very survival of the organization rides. Senior management and employees must be involved and committed to the plan. Following are six common planning mistakes that quickly will derail the DR/BC effort.

1. Poor business impact assessment — the planning team fails to recognize all the likely threats and disruptions that could realistically impact the business. They fail to understand and identify the organization’s true recovery and continuity needs or perform a sufficient gap analysis to determine what must be covered. Furthermore, they fail to accurately classify business processes, systems and data to assess which are mission-critical and prioritize around them. From an IT standpoint, the planners fail to define the recovery point objective and recovery time objective or every application in accordance with its priority.
2. Inexperienced DR/BC planners and project managers — the key to effective planning is to anticipate what can go wrong and what is needed. Often, the newest or least valuable people are assigned to DR/BC planning. Instead, companies must staff the team with seasoned veterans who know the business and who have been through disasters and disruptions before.
   If you don’t have experienced people, bring in experienced consultants to guide you through the process. An experienced consultant will help you identify all critical systems and create detailed plans to recover them to the current state. Asset management tools can help here, but they often fail to capture important details about software revisions and such.
3. Lack of committed resources and budget — this must not be a cheap or one-off effort. The DR/BC team must be broad enough (pulled from different departments), large enough and supported sufficiently to dedicate the necessary time and effort. The cost of DR/BC planning must be budgeted annually because the business changes constantly.
4. Failure to plan alternate communications — you will need to reach your people although they may be scattered by the emergency. Your phone system may be down. Your primary carrier may be out. You need to line up multiple communication options and make sure everyone knows the options and has the appropriate phone numbers, web addresses, and contact information to get in touch and stay in touch.
5. Insufficient and infrequent testing — plans are only good when they work, and testing is the only way to ensure they will. The rule of thumb is to fully test the entire plan annually. However, if something changes between tests, you want to revise that part of the plan and test it before the annual test. There is nothing worse than getting to a remote recovery site only to discover it hasn’t enough space for your people or has the wrong systems.
6. Poorly documented, outdated plans — the business changes, people come and go, systems are added and removed. The plan must be thoroughly documented at the start and updated every time something changes. Otherwise, you could find the plan counting on an employee who might have left the company four months earlier.

Although DR/BC is an enterprise responsibility, it remains IT’s role to make sure every business application has a viable disaster recovery plan in place. There is nothing magic to DR/BC. It follows the basic blocking and tackling of all good business planning exercises. It doesn’t necessitate buying costly technology or contracting with costly host sites. Rather, it requires sound planning around business needs, the active support of top management and sufficient resources to do the job. Experience does count. If you don’t have people experienced in DR/BC planning, bring in consultants who have the necessary experience.

By Mark Teter, Chief Technology Officer, Advanced Systems Group.