NIST SP 800-34: Contingency Planning and Disaster Recovery for IT Systems

NIST 800-34, formally Special Publication 800-34 Revision 1, is the US National Institute of Standards and Technology's Contingency Planning Guide for Federal Information Systems. Published in 2010, it remains one of the most practical and widely used references for planning how IT systems recover from outages, cyberattacks and disasters. It gives a step-by-step process, clear definitions of recovery terms, guidance on strategies by system impact level, and ready-made templates.

Although written for US federal agencies, it is used by organisations worldwide because it is free, detailed and maps directly to the contingency planning controls in NIST SP 800-53, which FedRAMP and many security frameworks rely on. This guide explains the seven-step process, the business impact analysis, the main plan types, the structure of an information system contingency plan, testing and maintenance, and how to apply it to modern cloud and SaaS systems.

What is NIST SP 800-34?

SP 800-34 Rev. 1 provides instructions, recommendations and considerations for federal information system contingency planning. Contingency planning, in NIST's terms, refers to interim measures to recover information system services after a disruption, such as relocating systems to an alternate site, recovering functions using alternate equipment, or performing functions manually. The guide supports the contingency planning (CP) control family in NIST SP 800-53 and integrates contingency planning into the NIST Risk Management Framework.

Revision 1 superseded the 2002 original. It focused the guide on the information system contingency plan (ISCP), explained how it relates to other organisational plans, and added templates for low, moderate and high impact systems. No newer revision had been published as of October 2026.

Who should use it?

• US federal agencies and their contractors, under FISMA and agency policy.
• Cloud service providers seeking FedRAMP authorisation, which requires a contingency plan aligned with NIST controls.
• Organisations using NIST SP 800-53 or 800-171 as their control framework.
• IT teams anywhere looking for a structured, free method and templates for disaster recovery planning.

Is it mandatory or voluntary?

For federal agencies, it is the expected guidance for meeting mandatory SP 800-53 contingency planning controls under FISMA. For everyone else, it is voluntary. Auditors and customers often accept plans based on SP 800-34 as evidence of good practice.

The seven-step contingency planning process

1. Develop the contingency planning policy: a formal policy that gives authority and guidance, defines roles and sets requirements such as testing frequency.
2. Conduct the business impact analysis (BIA): identify mission and business processes supported by the system, the impact of disruption, recovery priorities and resource requirements.
3. Identify preventive controls: measures that reduce the effects of disruptions and can increase availability and reduce costs, such as uninterruptible power, fire suppression, redundancy and backups.
4. Create contingency strategies: recovery approaches that ensure the system can be recovered quickly and effectively.
5. Develop the information system contingency plan: detailed guidance and procedures for restoring the damaged system, based on its security impact level and recovery requirements.
6. Ensure plan testing, training and exercises: validate recovery capabilities, prepare staff and improve the plan.
7. Ensure plan maintenance: keep the plan current with system changes and organisational improvements.

The business impact analysis

The BIA correlates the system with the processes it supports and characterises the consequences of disruption. SP 800-34 describes three steps: determine mission and business processes and recovery criticality, identify resource requirements, and identify recovery priorities for system resources. It defines key time measures:

Term	Meaning
Maximum tolerable downtime (MTD)	The total time a business process can be disrupted before unacceptable consequences.
Recovery time objective (RTO)	The maximum time a system resource can remain unavailable before it affects other resources, processes and the MTD.
Recovery point objective (RPO)	The point in time before an outage to which data must be recovered, defining acceptable data loss.
Work recovery time (WRT)	Time needed after systems are restored to verify data and resume normal processing.

RTO plus WRT must fit within the MTD. The BIA template in SP 800-34 helps capture these values with process owners.

Preventive controls

Some disruptions can be prevented or reduced. Examples in the guide include uninterruptible power supplies and generators, air conditioning with redundancy, fire and water detection and suppression, heat-resistant and waterproof containers for backup media, off-site storage of backups and documentation, technical security controls and frequent scheduled backups. In modern systems, preventive controls also include redundancy across availability zones, automated health checks and protections against ransomware.

Recovery strategies by impact level

SP 800-34 links recovery strategies to the system's FIPS 199 security impact level for availability. Higher impact systems need faster recovery and more resilient options. Strategy areas include:

• Backup and recovery: backup frequency, scope, media, off-site storage and restoration methods aligned with the RPO.
• Alternate sites: cold sites, warm sites, hot sites, mirrored sites and mobile sites, ranging from basic space to fully redundant real-time operations.
• Equipment replacement: vendor agreements, inventory or existing compatible equipment.
• Roles and responsibilities: recovery teams with clear leaders and alternates.
• Cost considerations: balancing the cost of strategies against the impact of downtime.

Today, cloud regions, infrastructure as code and managed replication often replace physical alternate sites, but the same logic applies: the higher the impact, the faster and more independent the recovery capability must be.

The information system contingency plan

The ISCP is the core document. It has supporting information and three main phases, plus appendices:

• Supporting information: purpose, scope, assumptions, system description and roles.
• Activation and notification phase: criteria for activating the plan, notification procedures and outage assessment.
• Recovery phase: sequence of recovery activities and detailed procedures to restore the system, prioritised by the BIA.
• Reconstitution phase: validating the system and data, testing functionality, returning to normal operations, and deactivating the plan with documentation and lessons learned.
• Appendices: contact lists, vendor details, BIA results, detailed procedures, system inventories, interconnections, test and maintenance schedules and associated plans.

NIST provides ISCP templates for low, moderate and high impact systems, which many organisations adapt.

Related plan types

The guide explains how the ISCP relates to other plans:

Plan	Focus
Business continuity plan	Sustaining mission and business processes during and after disruption.
Continuity of operations plan	Restoring an organisation's essential functions at an alternate site (federal context).
Crisis communications plan	Internal and external communications during an event.
Critical infrastructure protection plan	Protecting national critical infrastructure components.
Cyber incident response plan	Detecting, responding to and limiting the effects of malicious cyber events.
Disaster recovery plan	Relocating systems to an alternate site after major disruptions to facilities.
Information system contingency plan	Recovering a specific information system.
Occupant emergency plan	Safety and evacuation of personnel.

Roles and recovery teams

The guide recommends defining roles and responsibilities clearly before an incident. A contingency planning coordinator maintains the plan. A system owner or designated authority decides when to activate it. Recovery teams are organised around tasks, such as management, damage assessment, operating systems, applications, network, database, data recovery, testing and customer communication, each with a leader and alternates. In small organisations one person may cover several roles, but each role should still be named so that responsibilities are clear during the pressure of an outage. Contact lists, including after-hours numbers and vendor support contacts, belong in the plan appendices and must be kept current.

Interconnections and dependencies

Few systems recover alone. SP 800-34 asks planners to document interconnected systems, external services and data feeds, and to consider their recovery priorities. A system restored before its authentication service, database or upstream data source may not be usable. Modern dependency maps should include cloud services, identity providers, DNS, certificate authorities, secrets managers, payment gateways and messaging services. Recovery sequences in the ISCP should follow these dependencies, and contracts with providers should state their own recovery commitments.

Testing, training and exercises

Plans must be tested to identify gaps, and staff must be trained in their roles. SP 800-34 describes tabletop exercises, which discuss scenarios, and functional exercises, which simulate operations, including full-scale tests involving actual recovery. Tests should cover notification procedures, system recovery on an alternate platform, internal and external connectivity, system performance on alternate equipment, restoration of normal operations, and backup data and media. Results and lessons learned should update the plan. SP 800-53 sets testing frequency expectations for the CP controls, and higher impact systems require more rigorous testing.

Plan maintenance

The ISCP must be reviewed at least annually and whenever significant changes occur in the system, processes, organisation, or recovery strategies. Maintenance includes updating contacts, procedures, dependencies, vendor information and the BIA, and distributing changes to those who hold copies.

Mapping to SP 800-53 contingency planning controls

The CP control family in SP 800-53 includes controls such as contingency planning policy and procedures (CP-1), contingency plan (CP-2), contingency training (CP-3), contingency plan testing (CP-4), alternate storage site (CP-6), alternate processing site (CP-7), telecommunications services (CP-8), system backup (CP-9) and system recovery and reconstitution (CP-10). SP 800-34 explains how to meet them in practice.

Applying SP 800-34 to cloud and SaaS

• Treat cloud regions and accounts as alternate sites, and document how failover works.
• Define RTO and RPO per service and match replication and backup schedules to them.
• Include identity providers, DNS, secrets management and third-party APIs in the dependency inventory.
• Write recovery procedures as runbooks, ideally automated, with manual fallbacks.
• Cover ransomware scenarios with immutable backups and clean rebuilds.
• Test restores and failovers regularly and record results for audits.

Documentation you will need

• Contingency planning policy.
• BIA with MTD, RTO and RPO.
• Preventive control inventory.
• Recovery strategy decisions.
• ISCP with appendices.
• Test plans, after-action reports and training records.
• Maintenance and review records.

Timeline and cost considerations

For a single system, a BIA and ISCP can be drafted in a few weeks using NIST templates. The main costs are recovery capabilities, such as replication and standby environments, and the time to test. The guide encourages balancing these costs against the impact of downtime established in the BIA.

Common mistakes

• RTOs set by IT without asking business owners about MTD.
• Ignoring work recovery time, so restored systems still miss business deadlines.
• Plans that list steps no one has tried.
• Out-of-date contact and vendor lists.
• No reconstitution phase, leaving systems in a fragile temporary state.
• Treating incident response and contingency planning as unrelated.

Best practices, tools and technologies

• Use NIST templates as a starting point and adapt them to your architecture.
• Store plans where they are reachable during an outage.
• Automate backups, replication monitoring and failover.
• Run tabletop exercises quarterly and technical tests at least annually.
• Align with ISO 22301 and ISO/IEC 27031 if you also hold ISO certifications.

We document architectures, automate backups and failover, and write and test recovery runbooks through our maintenance and support and migration services.

How it relates to other frameworks

Framework	Relationship
NIST SP 800-53	Contingency planning controls that SP 800-34 helps implement.
FedRAMP	Requires contingency plans and testing for cloud services.
ISO 22301	International business continuity management system standard.
ISO/IEC 27031	International guidance on ICT readiness for business continuity.
IT disaster recovery planning	Practical synthesis of recovery expectations across standards and laws.

Real-world example

A SaaS company preparing for FedRAMP Moderate authorisation, with an engineering team in India, runs a BIA for its platform: customers can tolerate eight hours of downtime (MTD), so it sets an RTO of four hours and an RPO of one hour, leaving time for data verification. It uses the moderate impact ISCP template, documents activation criteria, recovery steps for a regional failover and a ransomware rebuild, and reconstitution checks. It runs a tabletop exercise each quarter and a full failover test each year, and the assessor reviews the results against CP-2, CP-4, CP-9 and CP-10.

Next steps

1. Write or update the contingency planning policy.
2. Run a BIA with business owners.
3. Choose strategies by impact level.
4. Draft the ISCP from NIST templates.
5. Test, train and review annually.

Frequently asked questions

What is NIST SP 800-34?

NIST's Contingency Planning Guide for Federal Information Systems, describing how to plan and test recovery of IT systems.

What is the current version?

Revision 1, published in May 2010 with updates later that year. No newer revision has been published.

Is SP 800-34 mandatory?

It is expected guidance for US federal agencies meeting SP 800-53 controls, and voluntary for others.

What are the seven steps?

Policy, business impact analysis, preventive controls, contingency strategies, contingency plan, testing and training, and maintenance.

What is the difference between MTD and RTO?

MTD is how long a business process can be down; RTO is how long a system can be down, which must fit within the MTD with time for work recovery.

What are the phases of an ISCP?

Activation and notification, recovery, and reconstitution.

Is a disaster recovery plan the same as an ISCP?

No. A DRP covers relocation after major facility disruptions, often for several systems; an ISCP covers recovering a specific system.

Does NIST provide templates?

Yes. SP 800-34 includes a BIA template and ISCP templates for low, moderate and high impact systems.

How often should plans be tested?

At least annually for most systems, with frequency and rigour set by SP 800-53 controls and the system's impact level.

Can non-US companies use SP 800-34?

Yes. It is freely available and widely used as a practical method worldwide.

What is reconstitution?

The final phase of an ISCP, in which the restored system is validated, tested and returned to normal operations before the plan is deactivated.

How does SP 800-34 relate to incident response?

Incident response handles detection and containment of cyber events; the contingency plan restores systems when an incident causes a disruption.