Problem solve Get help with specific problems with your technologies, process and projects.

Week 26: Contingency planning

In this week's column, Shelley Bard outlines strategies on how to come up with sound contingency plans.

June is the start of hurricane season. Have you considered how much your company would lose if its systems couldn't process information for 24 hours due to natural disaster? Don't forget to add your time to recover data and bring the systems back up; then add intangible costs of what employees can't be doing due to recovery efforts. This information can drive management's decision to support a hot, warm or cold backup site. In addition to management, companies insuring your business operations will also want to see how you will continue to provide services in the event of a catastrophe, as will your stockholders if your company is publicly traded.

Contingency planning refers to interim measures to recover IT services following an emergency or system disruption. Whether you call it a Continuity of Operations Plan, Disaster Recovery Plan, Contingency Management Plan or Business Continuity Plan, you need to map out how you will continue operations in the event of a problem caused by a natural disaster (weather doesn't cover earthquakes), the ever-present "backhoe-cutting-the-cable" problem, terrorism or just plain stupidity. Review your contingency plan and update it -- what new systems are unaccounted for in the outdated plan?

Industry practices divide recovery actions into phases. The three commonly used phases include:

1) Notification/Activation: Describes the process of notifying recovery personnel and performing a damage assessment.

2) Recovery: Discusses a suggested course of action for recovery teams and personnel to restore IT operations at an alternate site or using contingency capabilities.

3) Reconstitution: Outlines actions that can be taken to return the system to normal operating conditions.

If you have an up-to-date plan, when was the last time you practiced or invoked it? Any lessons learned from that experience? Add the observations to the plan or as an appendix to document the evolution of how you will do business in the event of a loss.

Management support is vital and must demonstrate a firm commitment to contingency planning by promoting objectives and including responsibilities to attain those objectives in job descriptions, for example, and supporting the creation, exercise and updating of the plan.

If you are planning a recovery center, consider this: In April, the Securities and Exchange Commission approved rules which require National Association of Securities Dealers and the New York Stock Exchange members to develop business continuity plans by late summer. Under the new rules, the plan must address various aspects of business continuity, including data backup and recovery, mission critical systems, alternative communications between the firm and employees and customers, and how the company will assure its customers' prompt access to their funds and securities in the event the company is unable to continue business. Customers also must be provided a summary of the business continuity plan.

Finally, if you contract out some or all of your support through other agencies or companies, you have the right, and the obligation, to carefully review their contingency plans and see where your operations fit into the picture. Compare their plan to what is promised in the provider agreement to verify they can deliver.

More information
NIST Special Publication 800-34, Contingency Planning Guide for Information Technology Systems, is a helpful document that addresses specific planning recommendations for seven IT platform types. It offers templates for preparing a plan and a Business Impact Analysis, FAQs, personnel considerations in contingency planning and resources for additional information you can use to tailor a plan for your organization. FIPS PUB 87, "Guidelines for ADP Contingency Planning," though dated 1981, still has good information in it and can be found at

About the author
Shelley Bard, CISSP, CISM, is a senior security network engineer with Verizon Federal Network Systems (FNS). An information security professional for 17 years, Bard has briefed and written infosecurity assessments and technical reports for the White House and Department of Defense, special interest groups, industry and academia. Please e-mail any comments to

Opinions expressed in this column are those of Shelley Bard and don't necessarily reflect those of Verizon FNS.

Last week: Completing the risk assessment -- steps nine and 10
Next week: Credentials: To be or not to be certified?

This was last published in June 2004

Dig Deeper on Information Security Incident Response-Information

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.