NIST Special Publication 800-34 is the US National Institute of Standards and Technology’s contingency planning guide for information systems. It explains how to plan for keeping systems running, or getting them back, after a disruption such as a power failure, cyberattack, equipment failure or loss of a building. It covers a seven-step planning process, the business impact analysis, recovery strategies, and how an information system contingency plan relates to wider continuity and disaster recovery plans. It was written for federal systems but is widely used as a structure by other organizations. This entry is general information, not legal advice.
At a glance
- It is a planning guide, not a certification or a product requirement.
- The current revision, Revision 1 (2010), defines a seven-step contingency planning process.
- A business impact analysis (BIA) sets recovery priorities, downtime limits and data loss limits for each system.
- It distinguishes several plan types, from business continuity and continuity of operations to system-level contingency and disaster recovery plans.
- It includes sample plan templates for low-, moderate- and high-impact systems.
What problem it solves
Many organizations have backups and maybe a disaster recovery service, but no agreed plan for using them. When something fails, people debate priorities, look for passwords and vendor contacts, and discover that a critical system depends on another one nobody listed. Recovery takes far longer than the business can tolerate.
NIST SP 800-34 turns that into a repeatable process. It ties recovery targets to business impact, matches recovery strategies to those targets, and puts roles, contacts and procedures in writing before they are needed. Testing and maintenance steps keep the plan from going stale.
How it works
The guide’s seven steps are:
- Develop the contingency planning policy. Leadership sets the authority, scope and responsibilities.
- Conduct the business impact analysis. The organization identifies which systems support which business processes and sets limits such as maximum tolerable downtime, the recovery time objective (RTO) and the recovery point objective (RPO).
- Identify preventive controls. Measures such as backup power or redundant equipment reduce the chance or effect of an outage.
- Create contingency strategies. Backup methods, alternate sites, equipment replacement and supplier agreements are chosen to meet the recovery targets.
- Develop the information system contingency plan. The plan sets out roles and procedures in three phases: activation and notification, recovery, and reconstitution back to normal operation.
- Test, train and exercise. Tests check that recovery works, training prepares staff, and exercises such as a tabletop exercise expose gaps.
- Maintain the plan. The plan is updated as systems, staff and suppliers change.
The guide’s sample templates scale with the system’s impact level under FIPS 199, and its planning ties to the contingency planning controls in NIST SP 800-53.
Plan types
NIST SP 800-34 has no compliance levels. Its main structure is a set of related plans, each with a different scope. The guide focuses on the information system contingency plan and explains how it fits with the others.
| Plan type | What it covers | Typical owner | Typical evidence |
|---|---|---|---|
| Business Continuity Plan (BCP) | Keeping business processes going during and after a disruption | Business leadership | Approved plan, exercise records |
| Continuity of Operations (COOP) Plan | Restoring an organization’s essential functions at an alternate site; required of US federal organizations | Leadership, continuity team | Plan, alternate-site arrangements |
| Crisis Communications Plan | Internal and external communications during an event | Communications, leadership | Contact lists, message templates |
| Critical Infrastructure Protection (CIP) Plan | Protecting critical infrastructure components | Security, facilities | Asset and protection plans |
| Cyber Incident Response Plan | Detecting, responding to and limiting cyber incidents | Security team | Plan, incident records |
| Disaster Recovery Plan (DRP) | Moving systems to an alternate site when a major disruption denies access to the primary facility | IT operations | Plan, failover test results |
| Information System Contingency Plan (ISCP) | Assessing and recovering a single system, at its current location or an alternate site | System owner | BIA, plan, test results |
| Occupant Emergency Plan (OEP) | Protecting people in a facility | Facilities, safety | Evacuation procedures, drills |
When it matters for buyers
- When buying disaster recovery or backup services. Your BIA sets the RTO and RPO a provider has to meet; the plan defines how you invoke the service.
- When an auditor, regulator or customer asks for a contingency plan. A plan built on a recognized structure is easier to explain and defend.
- When moving systems to cloud or colocation. Recovery responsibilities shift, and the plan should show who restores what.
- When a provider holds critical data. Their recovery commitments become part of your plan.
Our disaster recovery as a service (DRaaS) overview covers providers that can meet the recovery targets a plan sets.
Questions to ask vendors
- What recovery time and recovery point can you commit to in the contract, and how are they measured?
- Who declares a disaster and starts failover, and how quickly can that happen?
- How often do you test recovery, can we take part, and will you share the results?
- Where is the alternate site or recovery region, and does it depend on any of the same facilities or networks as production?
- What do you need from us to recover our systems, and is that documented in a runbook?
- How do you return systems to normal operation after a failover?
How it differs from Business Continuity and Disaster Recovery (BCDR)
Business continuity and disaster recovery (BCDR) is the overall practice of keeping a business running and restoring technology after a disruption. NIST SP 800-34 is a specific published guide focused on the information system side of that practice: how to plan, document, test and maintain recovery for systems, and how those system plans fit with business continuity and other plans. Services such as disaster recovery as a service supply the recovery capability; the plan decides how and when to use it. The guide sits within NIST’s Special Publication 800 series.
Problems this helps with
- Our disaster recovery plan has never been tested and nobody knows who does what
- An auditor wants a business impact analysis and contingency plan for key systems
- Not sure how fast each system has to come back after an outage
