Turn a business impact analysis into an information-system contingency plan

A contingency plan should explain how an information system will support prioritized business needs through disruption and restoration. Copying a generic recovery template cannot establish those priorities or reveal the people, data, facilities, providers, and technical dependencies unique to the service.

The NIST planning method

Source fact: NIST SP 800-34 Rev. 1 provides guidance on the purpose, process, and format of information-system contingency planning. It relates contingency plans to incident response, disaster recovery, emergency management, organizational resilience, and the system development life cycle.

Source fact: NIST describes a planning process that includes policy, a business impact analysis, preventive controls, recovery strategies, plan development, testing/training/exercises, and plan maintenance. The business impact analysis connects business processes to supporting system components and helps determine priorities and contingency requirements.

Build from business impact

DSE recommendation: begin with business owners and document the service delivered, the effect of interruption or incorrect data over time, dependencies, seasonal constraints, manual alternatives, and the conditions required for safe operation. Avoid assigning recovery targets because another organization uses them.

Identify business processes and the system components, identities, data, networks, facilities, staff, and suppliers that support them.

Prioritize those components using the documented business impact and dependency order.

Evaluate preventive controls that can reduce disruption or improve availability.

Select recovery strategies that are feasible within resource, architecture, safety, contractual, and support constraints.

Document activation, notification, assessment, recovery, validation, reconstitution, and return-to-normal procedures.

Assign plan ownership, training, exercise frequency, evidence, finding management, and change triggers.

Exercise decisions and dependencies

DSE recommendation: test whether the team can reach the plan, obtain credentials, contact providers, recover required configuration and data, communicate without normal channels, and validate the business process. A tabletop can test authority and coordination; a technical recovery test can prove procedures and dependencies. Neither automatically proves the other.

Update the plan after architecture, application, identity, provider, facility, staffing, data, or business-process changes. Track unresolved exercise findings as operating risk with accountable owners.

Applicability and limits

This 2010 publication was written for U.S. federal information systems. Nonfederal organizations can adapt the method, but should not present it as a private-sector mandate. Cloud and SaaS services, modern identity dependencies, current cyber threats, and present legal or contractual requirements need separate current analysis. Vendor recovery documentation and shared-responsibility terms still apply.

Official reference

NIST SP 800-34 Rev. 1 — information-system contingency planning and business impact analysis guidance.