Guide to Incorporating Communications into Business Continuity Planning

The sheer number and magnitude of recent disasters has companies wondering if they could stay in business after a catastrophe. But lightning strikes, power outages, snow storms, and viruses are far more likely to occur than big, news-making disasters—and any disaster can leave a company crippled. Your best defense: a comprehensive, tested, and practiced business continuity plan that kicks in whether the crisis is big or small, natural or man-made.

Communications Help Recovery Efforts
When an emergency occurs—whether you lose one key individual, one strategic system, an entire building, or a whole network—communications is the most critical element for enabling people to effectively manage and recover from the disruption.

In this Guide, Avaya explains how to accomplish continuity planning for telecommunication systems.

Action Steps
The best contacts and resources to help you get it done

Assess Risks and their Potential Impact on your Business

A Risk Assessment helps you identify and understand potential risks to your business so you can work to mitigate them.

I recommend: Visiting the Business Continuity Institute, which reports that only 2% of companies' business continuity plans actually consider the value of their telecommunication systems.

In assessing risks, natural threats are probably the easiest to recognize. Businesses in the Caribbean know they're at risk for hurricanes, California faces forest fires and earthquakes, much of Southeast Asia experiences monsoons, and so on. These natural threats are usually well understood.

IT related threats are more difficult to recognize. This is especially true of security threats that could affect voice communications when voice traffic is transported over IP networks. Viruses, worms and denial of service attacks are a constant and growing threat to businesses.

Your risk assessment should have three phases:

1. Examine policies. Does your company have policies, do the policies protect your important assets, and are the policies enforced?
2. Look at communications architecture. The architecture should reflect and enforce the policies.
3. Study the vulnerability of devices on the network. Do they have the latest software patches required to prevent exploitation? Since new vulnerabilities are reported every day, this is an ongoing battle.

Risk assessments of technology infrastructure require a thorough search for single points of failure (SPOF). For your telecommunications infrastructure, methodically trace the call path from end to end. A thorough assessment requires tracing the call path both inside your facilities and outside through facilities that are owned and operated by your telecommunications service provider.

After defining the call path, each element in the call path should be evaluated in terms of its importance to your business. For example, a PBX is more important to the business than an individual telephone because a failure of the PBX results in a loss of telephony services to all employees, while a telephone affects only one employee.

Also consider the likelihood of failure for each element. Any single point of failure is a potential risk, but SPOFs with higher likelihood of failure are greater risks.

Do a Business Impact Analysis

A Business Impact Analysis looks at the potential impact of threats to your business.

I recommend: Reading "Ten Steps to a Successful Business Impact Analysis" at the TechTarget Data Center to learn more about the benefits of a BIA and how to perform one.

A Business Impact Analysis requires examining each of your major business functions to understand their reliance on resources, such as voice technology, and their importance to the business.

Specifically, you must determine what occurs when a particular business function is no longer available. Do you lose revenue, customers, or reputation? Are these losses permanent? How quickly do the losses occur?

Look at each business function, and work down to the specific technologies supporting those business functions. Once you know which business functions are critical and must continue to function during a disaster, determine the software and hardware required to support those functions.

Interviewing the managers of the organizations reveals the applications used and the servers that host those applications. Further questioning reveals whether there are manual procedures that can be used if an application is not available, the amount of downtime that can be tolerated, and the number of people who use the system.

Determine How Quickly Business Functions Must Recover

In addition to determining the technology required to support each business function, you must also figure out how quickly each business function requires recovery, and the relative importance of the business functions.

I recommend: Reviewing Avaya Communications Continuity Consulting designed to assist managers who need to prepare for recovery from a communications disruption, outage, or disaster.

In determining how quickly business functions must recover, focus on three objectives:

• Recovery Time Objective: How fast do you require a business process to be operational after an outage?
• Recovery Scope Objective: What are the key departments and systems that need to be recovered?
• Recovery Point Objective: What is the time between system backups?

Recovery Time Objective:
The amount of revenue lost over time during a disaster varies from company to company, depending on the nature of the business. A catalog retailer, for example, generates revenue from a continuous stream of transactions. If the call center is down, the retailer begins to lose money immediately. If the items sold are commodities, customers simply purchase items from a competitor. In other words, the purchase is not postponed, it is lost. Companies with unique products, or with more loyal customers, lose revenues more slowly.

If you anticipate a precipitous drop in company revenue (and other intangibles), you need a recovery strategy that allows you to recover critical systems quickly. If revenues will drop slowly, a more conservative strategy is appropriate.

The faster a company needs to recover, the more it will cost. Companies need to balance their potential losses against the cost of a recovery strategy.

Recovery Scope Objective:
A recovery plan that includes every employee is very costly. It makes sense to prioritize business functions in terms of their importance and select the functions that must be recovered first.

For telecommunications infrastructure, the first consideration is determining the number of people who need a working phone following a disaster. Your phone system may support 300 handsets during normal business operations, but do you really need all of those handsets to be available when you are recovering from an outage?

Analyze your major business functions to determine which are critical to your business.

Create a Recovery Plan

Write down how to tactically implement the chosen recovery strategies that meet your recovery time and scope requirements. You'll create a document detailing the specific procedures your employees follow during a disaster.

I recommend: Reviewing a Sample Business Continuity and Disaster Preparedness Plan to help get organized and charge your brainstorming.

See how the San Francisco International Airport created first-class emergency preparedness. The airport worked with Avaya to perform continuity assessments and implement solutions.

See how the Utah Workers Compensation Fund improved its emergency response abilities starting with an Avaya business continuity risk assessment.

Start by thinking about a simple plan. During a business disruption—whether it’s a power outage or half of your call center agents get the flu—normal processes are interrupted. The equipment you normally rely on may be gone, the people you normally rely on may be unavailable, and the location in which you work may be uninhabitable. As a result, your normal business processes won’t work. Your continuity plan should define the backup business processes during such a disruption.

In your plan, include an inventory of critical infrastructure so you can begin to repurchase anything destroyed. Without an inventory, you must attempt to remember in detail all of the equipment used by your business.

Also create a personnel inventory that includes contact information for your employees. Determine who fulfills critical roles. Who installs and administers any new telecommunications equipment? What if your telecommunications manager is not available? Who fills in, and how do they know what to do? Document the telecom manager’s knowledge by creating detailed procedures for restoring damaged equipment. Think of this as a knowledge inventory.

While it is possible to create a continuity plan without investing in new technology, the best solution is to invest in appropriate technology that fulfills your requirements. Then, create a plan that documents your implementation of that technology.

Test Your Plan

It is essential to test your continuity plan to measure its accuracy and completeness, to reveal oversights, and to verify that the plan will actually work. Testing ensures that employees understand their responsibilities and how to carry them out. The more realistic the test, the better it prepares employees for an actual disaster.

I recommend: "Planning For The Unforeseen: Insuring Communications For All Contingencies," a Greenspring Partners white paper that reviews recent emergency situations, highlights lessons learned, and defines communications requirements at different stages in the emergency management process. Registration required.

To conduct a meaningful test, pre-test activities should include:

• Defining the test's scope, strategy, and methodology.
• Identifying all participants and stakeholders.
• Holding pre-test planning meetings.
• Developing a formal Test Plan with documented test objectives.
• Preparing the test environment, so you can monitor testing activities and record progress.

  Post-test activities should include:

• Reviewing all test activities, results, and open items.
• Developing and presenting a test report with results and recommendations for improvements.

  For thoroughness, perform three types of testing:

1. Table-top testing: A disaster scenario is presented by a moderator and recovery teams walk through their documented tasks.
2. Simulation: Simulate traffic volumes, rerouting, network responses, etc., to verify the telecommunications infrastructure can support the planned recovery.
3. Physical testing: Some or all of the recovery strategy is actually engaged, such as by the routing of actual telecommunications traffic to the alternate facility.

Tips & Tactics
Helpful advice for making the most of this Guide

• Emergency response is a good place to begin examining risk reduction strategies. Emergency response is the set of activities that occur immediately following a disaster-these activities relate to immediate dangers, not the restoration of business operations. The emergency must be reported internally and externally to the appropriate agencies. Your exact response procedures must be documented and tested. Testing trains employees to act appropriately.
• For emergency personnel to locate a person calling 911 for help, the caller's phone must be associated with its correct location, including the exact location inside a building. When a phone system is shared by multiple buildings, location information may be inaccurate. With a VoIP system, VoIP endpoints can be moved at will, making them difficult to locate by 911 systems. Test your system to see what happens when an emergency call is placed. To correct a location-finding problem, look into Enhanced 911 (E-911) solutions.
• An Emergency Notification System simplifies and speeds the process of notifying employees after a disaster. These systems store a database of employee contact information and dial, email, or page the entire list automatically. Good systems store several numbers for each individual and continue to dial until everyone receives the message. If individuals cannot be reached, the system logs the failed attempts and saves a log file.
• System backups should be stored off site so they are available during a disruption. The location of the backups and any instructions required to retrieve them must be documented and included in your recovery plan.
• Backing up a telecommunications server is fundamentally different from backing up other application servers. The typical procedure: back up a production server, storing the backup off site, and use the backup to bring up a replacement server. Usually, you can use the backup regardless of the replacement server's size. But a telecommunications replacement server must have the same number of handsets and port cards in the same slots as the production server, or the backup is useless.
• Reduce the risk of voice system failure by increasing the redundancy of critical system components. The critical components of a voice system are the server, the gateway and the stations. Since the stations only connect single users, redundancy is not usually a major concern, and can be solved simply by stocking extra handsets. The call server and the gateway are central to functionality, represent serious single points of failure, and should be redundant components.
• Traditional PBXs usually have redundancy built in to reduce the risk of system failure. But with a VoIP system, voice traffic traverses an IP network, rather than a dedicated voice network. If a VoIP voice system fails, the network can reroute traffic to a backup voice system. As a result, vendors of voice systems supporting only VoIP have focused their risk reduction efforts on architectures involving duplicate voice systems with redundant network paths. If the primary voice system fails, the secondary server takes over, and calls are rerouted to the secondary server.