This article is part of an Essential Guide, our editor-selected collection of our best articles, videos and other content on this topic. Explore more in this guide:
3. - Network disaster recovery planning and building resilient networks: Read more in this section
- Business continuation and disaster recovery tips for your WAN services
- WAN optimization products unshackle disaster recovery
- How to deal with failback problems
- Local area network disaster recovery planning
- Designing a resilient WAN
- What to do when remote employees overload your VPN
- Ensuring reliability in your organization’s voice/data network
- A template for your network disaster recovery plan
Explore other sections in this guide:
- 1. - Good planning and management are key for business continuity and disaster recovery success
- 2. - Recent storage and server developments ease BC/DR planning
- 4. - Security an important part of BC/DR planning
Most organizations depend on voice and data communications, and also have local area networks (LANs) and wide area networks (WANs). With such a critical and strategic investment in networking, how you do protect those valuable investments from unplanned disruptions due to carrier problems or equipment malfunctions? Furthermore, is your network infrastructure secure and protected from unauthorized access, viruses or attacks by hackers? Critical network infrastructures and associated assets must be protected with disaster recovery plans.
In this article and associated network disaster recovery plan template, we’ll examine the issues that should be addressed when preparing and deploying a network disaster recovery plan for voice and data communications.
Network disaster recovery planning not always a priority
When it comes to network infrastructures, disaster recovery planning isn't often a huge priority. Network security, by contrast, is usually a high priority because a porous perimeter spells doom for most organizations. Preventing unauthorized access by hackers and other criminal types, and introduction of viruses and denial of service (DOS) attacks are usually high priorities that get management attention.
On the voice side, growing acceptance of voice over IP (VoIP) technology has increased the importance of robust network security initiatives. As VoIP is simply another application using existing network resources, it has vulnerabilities that must be addressed the same as other network-based systems.
Older PBS systems typically used separate network facilities and did not overlap with data networks. However, as it became more cost-effective to share voice and data traffic over digital T-1 lines, the risks to voice communications systems increased. Today, with voice, data, Internet access and other network services often sharing the same network resources, it is even more important to protect network access lines and also the interface devices (e.g., routers and switches) that support these services.
Getting started with network disaster recovery planning
Before you get started creating your network disaster recovery plan, read these important caveats:
1. Take the disaster recovery planning process seriously. If you want to protect your network infrastructures and related assets from unplanned events that could disrupt network operations, you need a plan. It doesn’t have to be hundreds of pages long. A one-page plan with the right information can be more valuable than a voluminous document that nobody can use.
2. Use business continuity (BC) standards as a starting point. Almost two dozen BC/DR standards are available worldwide.
3. Keep it simple. Depending on how your voice/data/Internet/wireless networks are configured, your plans will need to reflect that same level of structure and complexity
4. Limit content to actual disaster response actions. Assuming you are creating a plan to respond to specific network-related incidents, include only the information needed for the response and subsequent recovery
5. Keep the plan up to date and test often. Once the plan is complete, exercise the plan at least twice annually (more often if your network configuration changes frequently) to ensure that the documented procedures make sense in the sequence indicated
6. Be flexible. A single disaster recovery template may not be applicable to all networks, especially if your organization has many corporate locations served by the network and multiple data centers; you may want to consider more complex templates, specialized network DR software or consultants experienced in network disaster recovery.
Network disaster recovery plan components
Next, we’ll examine the structure and content of the network disaster recovery plan template, indicating key issues to address and activities to perform.
- Initial data. Once you have identified primary and backup networking staff to contact in a network disruption, position their contact data at the front of the plan, so you won’t have to waste valuable seconds paging through a lengthy document.
- Revision management. Have a page that reflects your change management process
- Purpose and scope. Provide details on these attributes, as well as assumptions, team descriptions, a list of terms, and other background information.
- Emergency instructions on how to activate the plan. Provide data on circumstances under which the plan will be activated, including outage time frames, who declares a disaster, who should be contacted and response procedures to be used.
- Policy information. If the IT department has a BC/DR policy, be sure to include relevant policy information; this is also a good place to reference the use of standards documents
- Details of the plan. If possible, provide step-by-step procedures, as these are easier to follow than broad general statements such as “reconfigure network channels to alternate location” which may require significant detail to complete properly. In addition, describe how often the plan is to be reviewed and updated, and by whom.
- Checklists and flow diagrams. Assuming a network disruption has occurred, identify steps to address it; these can be in the form of checklists (useful to keep track of scheduled and completed tasks) and flow diagrams that provide a high-level view of response and recovery
- Information gathering. Information needs to be gathered before officially declaring a network disruption; this includes network performance data and first-hand reports from IT staff and employees and first responders (if needed); convene meetings as soon as possible with key IT network emergency team members to evaluate the facts before proceeding to a declaration.
- Declaring a disaster. Once initial facts on the network disruption are obtained, the plan should list actions to take when it becomes necessary to declare a network disaster.
- Recovering from a disaster. Once the situation has been brought under control, subsequent parts of the plan should provide instructions on recovering and restoring network operations, restoring network connectivity devices, and related activities
- Appendixes. Detailed appendixes are provided at the end of the template; these include lists and contact details on all IT and non-IT emergency teams, primary and alternate network vendors, alternate network configuration data, and other relevant information. It is very important to keep this information up to date.
The process of developing a network disaster recovery plan should be a relatively easy process. Plan complexity may increase, however, if you have a very complex network with multiple technologies and a complex topology. The keys to success include defining step-by-step response and recovery procedures, validating these activities through tests, and keeping the plan up to date.
About this author: Paul Kirvan, CISA, FBCVI, CBCP, has more than 20 years experience in business continuity management as a consultant, author and educator. He has been directly involved with dozens of IT/telecom consulting and audit engagements ranging from governance program development, program exercising, execution and maintenance, and RFP preparation and response. Kirvan currently works as an independent business continuity consultant/auditor and is the secretary of the Business Continuity Institute USA chapter. He can be reached at email@example.com.