Most contingency plans fail their first real test because they were written from a template downwards, not from a business impact analysis upwards. NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems, sets out a seven-step method that runs from policy through business impact analysis, preventive controls and recovery strategy to an information system contingency plan (ISCP) that is tested and maintained. It also ships free templates for the BIA and for low, moderate and high impact ISCPs. This guide walks through the method and the templates as NIST wrote them, and shows how to apply a 2010 document in a cloud and ransomware era. It is for system owners, ISCP coordinators, resilience leads and assessors. Broader continuity practice is in the Business Continuity and Disaster Recovery Guide and the control requirements are in NIST SP 800-53 CP Contingency Planning; this page covers the NIST method itself.
Source note: quotations and section references are from NIST SP 800-34 Rev. 1 (May 2010, updated November 2010), as at November 2026. Confirm against the official text before relying on it.
Key takeaways
- Seven steps, in order. Policy, BIA, preventive controls, contingency strategies, the ISCP, testing training and exercises, and maintenance. Skipping the BIA is the most common reason recovery targets are wrong.
- MTD comes first, then RTO and RPO. The RTO must normally be shorter than the maximum tolerable downtime; the RPO measures tolerable data loss and is not part of the MTD.
- The ISCP is system-specific, not site-specific. A disaster recovery plan relocates a site and may activate several ISCPs; each ISCP recovers one system at its current or an alternate location.
- Impact level sets the bar. NIST ties backup strategy, alternate site type and exercise depth to the FIPS 199 availability impact: tabletop for low, functional with backup recovery for moderate, full-scale with failover for high.
- Still current, but dated. Rev. 1 (updated 11 November 2010) remains the final version on NIST's site, so pair it with SP 800-53 Rev. 5 control text and current ransomware recovery practice.
Status and scope of SP 800-34
The NIST CSRC page lists SP 800-34 Rev. 1 as final, published May 2010 and updated 11 November 2010, with no withdrawal or newer revision shown when checked in November 2026. Its supplemental material is four Word templates: a BIA template and contingency planning templates for low, moderate and high impact systems. The guide was written for federal systems, but its method is used widely outside government because it is free, detailed and maps directly to SP 800-53 contingency planning controls.
Two things have aged. Its control appendix lists SP 800-53 Rev. 3 baselines (CP-1 to CP-10), while Rev. 5 adds CP-11 Alternate Communications Protocols, CP-12 Safe Mode and CP-13 Alternative Security Mechanisms. And its backup technology examples (tape, optical media) predate cloud object storage and immutable backups. The method is unaffected; the technology examples need translating.
The seven-step process
| Step | SP 800-34 section | Output | Where it goes wrong |
|---|---|---|---|
| 1. Develop the contingency planning policy | 3.1 | Signed policy naming roles, scope, resource needs, testing and maintenance schedules | Policy exists but does not set testing frequency |
| 2. Conduct the business impact analysis | 3.2 | Prioritised processes, MTD, RTO, RPO, resource list, recovery order | Done by IT alone, without process owners |
| 3. Identify preventive controls | 3.3 | Measures that reduce outage likelihood or effect (power, fire, backups, redundancy) | Treated as a substitute for recovery planning |
| 4. Create contingency strategies | 3.4 | Backup and recovery methods, alternate sites, equipment replacement, cost, teams | Strategy chosen before the RTO is known |
| 5. Develop the ISCP | Chapter 4 | Plan with supporting information, activation and notification, recovery, reconstitution, appendices | Procedures written as summaries, not step-by-step checklists |
| 6. Ensure testing, training and exercises | 3.5 | Exercise records and after-action reports | Exercise depth not matched to impact level |
| 7. Ensure plan maintenance | 3.6 | Reviewed plan with record of changes and controlled distribution | Contact lists and inventories go stale |
NIST's sample policy statement expects the plan to be reviewed and tested at least annually, and its plan approval template has the approver attest that the ISCP "will be tested at least annually." Section 3.6 itself leaves the review frequency to the organisation, with more frequent reviews for moderate and high impact systems and after significant change. The policy language is also covered in the Backup and Recovery Policy Template.
Running the BIA the NIST way
The BIA (Section 3.2 and the Appendix B template) has three steps, and each produces a table in the template:
- Determine business processes and recovery criticality: list the mission or business processes the system supports, the impact of losing each one over time, and the estimated downtime each can tolerate. The template asks for impact categories (for example cost, with severe, moderate and minimal thresholds) and an outage impact table per process.
- Identify resource requirements: facilities, people, equipment, software, data files, system components and vital records each process needs.
- Identify recovery priorities for system resources: link resources to processes and set the restoration order and per-resource recovery time.
The three time measures need precise use:
| Term | SP 800-34 meaning | Who sets it | Example from the NIST template |
|---|---|---|---|
| Maximum tolerable downtime (MTD) | Total outage time the system owner or authorising official is willing to accept for a mission or business process | Process owner and authorising official | Pay vendor invoice: 72 hours |
| Recovery time objective (RTO) | "the maximum amount of time that a system resource can remain unavailable before there is an unacceptable impact"; normally shorter than the MTD | System owner, from the MTD | 48 hours |
| Recovery point objective (RPO) | The point in time before the outage to which data can be recovered; not part of the MTD | Process owner, from tolerable data loss | 12 hours (last backup) |
The gap between RTO and MTD is deliberate: it leaves time for decision-making, validation and the business catch-up work that recovery always creates. A practical BIA worksheet is in the Business Impact Analysis Template, and impact levels come from the categorisation covered in the NIST SP 800-53 Privacy Controls and FIPS 199/200 Categorisation Guide.
From impact level to strategy
SP 800-34 links the FIPS 199 availability impact to backup and site strategy (Table 3-2) and to exercise depth (Table 3-6). The original technology examples are shown with a modern equivalent; the equivalents are NHI Mgmt Group interpretation, not NIST text.
| Availability impact | NIST backup example | NIST site strategy | Modern equivalent | Minimum exercise (Table 3-6) |
|---|---|---|---|---|
| Low | Tape backup | Relocate or cold site | Scheduled backups to separate, access-controlled storage; rebuild from code | Tabletop exercise |
| Moderate | Optical backup, WAN or VLAN replication | Cold or warm site | Immutable backups plus replication to a second region or account | Functional exercise including recovery from backup media |
| High | Mirrored systems and disc replication | Hot site | Active-active or warm standby across regions, plus isolated immutable copies | Full-scale functional exercise with failover to the alternate location |
NIST adds two warnings that matter more today than in 2010. High availability targets of "99.999 percent or higher" are costly and should be limited to systems that cannot tolerate downtime. And high availability cannot replace backups, because corrupted data spreads across mirrored systems; the same is true of ransomware-encrypted data. See the Backup Security and Immutable Backup Guide.
Inside the ISCP template
The Appendix A templates share one structure, so a plan built from them is easy to audit:
- Introduction and concept of operations: background, scope, assumptions, system description, the three phases, and roles and responsibilities. NIST states that "A senior management official, such as the CIO, has the ultimate authority to activate the plan."
- Activation and notification: activation criteria (damage extent, mission criticality, an expected outage longer than the RTO), notification procedures for both notice and no-notice events, and outage assessment. NIST cautions that email receipt cannot be guaranteed, so do not rely on it alone.
- Recovery: sequence of recovery activities following BIA priorities, step-by-step recovery procedures with no assumed steps, and escalation notices.
- Reconstitution: validation data testing, validation functionality testing, recovery declaration, user notification, clean-up, backup of the restored system, event documentation and deactivation. The high impact template adds optional concurrent processing first.
- Appendices: personnel and vendor contacts, detailed recovery procedures, alternate processing procedures, system validation test plan, diagrams, hardware and software inventory, interconnections, test and maintenance schedule, associated plans, the BIA and a document change page.
The low and moderate templates differ in substance, not just length: the moderate template assumes alternate processing and offsite storage are required, adds an alternate storage, site and telecommunications appendix, and moves testing from a tabletop to a functional test with an outside or impartial observer.
The ISCP sits within a family of plans. SP 800-34 distinguishes the business continuity plan, continuity of operations plan, crisis communications plan, critical infrastructure protection plan, cyber incident response plan, disaster recovery plan and occupant emergency plan. An ISCP is invoked by several of them, so coordinate activation triggers with the Incident Response Plan Template and the Disaster Recovery Plan Template. The Colonial Pipeline ransomware attack shows why: an IT-side compromise led to an operational shutdown decision, which is exactly the hand-off between incident response, ISCP and business continuity that plan coordination is meant to rehearse.
How to implement: a phased approach
- Phase 1, foundations (month 1): issue the contingency planning policy, appoint an ISCP coordinator per system, and confirm FIPS 199 availability impact for each system in scope.
- Phase 2, BIA (months 1 to 2): run BIA workshops with process owners using the NIST template; get MTD signed by the process owner and authorising official before any strategy work.
- Phase 3, strategy and cost (month 3): choose backup, alternate site and equipment replacement options per impact level, using the Section 3.4.5 cost template to compare options.
- Phase 4, write the ISCP (months 3 to 4): start from the matching impact template; write recovery procedures as checklists that a competent person who did not build the system can follow.
- Phase 5, exercise (month 5): run the exercise level for the impact level, and produce an after-action report that feeds plan changes.
- Phase 6, maintain: review at the defined frequency and after significant change; track versions and distribution with the record of changes.
Pilot on one moderate impact system before rolling out. If a strategy fails its exercise, roll back to the previous documented strategy, record a plan of action and milestones, and re-exercise rather than signing off a plan that has not worked.
Decision guidance
- One ISCP per system or one per platform: NIST expects one per system, but shared platforms (a database cluster, an identity provider) justify a platform ISCP referenced by each dependent system's plan.
- Cold, warm or hot: let the RTO decide. If rebuilding takes longer than the RTO, a cold site cannot meet it however cheap it is.
- Small organisations: use the low impact template for most systems and invest the saved effort in one well-tested moderate or high impact plan for the system the business depends on.
- Cloud-hosted systems: keep the ISCP structure but write provider dependencies, region failover and account recovery into it explicitly; the provider's resilience does not replace your plan.
Where identity fits
Recovery depends on identities that are easy to forget: break-glass administrator accounts, backup service accounts, the keys that decrypt backups, and the identity provider itself. If the identity provider is down or compromised, nobody can log in to execute the plan. List these in the ISCP's inventory appendix, store recovery credentials offline, and test them in every exercise. See the Backup Identity Isolation Guide and IdP configuration backup and restore for Entra ID and Okta.
Detection and measurement
- Percentage of in-scope systems with a current BIA signed by the process owner.
- Percentage of systems with an ISCP exercised at the depth their impact level requires within the defined period.
- Achieved recovery time and recovery point in exercises compared with the RTO and RPO.
- After-action items closed within their target date.
- Percentage of ISCP contact lists and inventories verified in the last review cycle.
Monitor backup job success and restore tests continuously, because the ISCP assumes they work; a failed backup is a contingency plan failure that has not happened yet.
Framework mapping
| SP 800-34 element | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | ISO/IEC 27001:2022 Annex A |
|---|---|---|---|
| Policy (step 1) | CP-1 | ID.IM-04 | A.5.29 Information security during disruption |
| BIA and ISCP (steps 2 and 5) | CP-2, CP-2(1), CP-2(3), CP-2(8) | GV.OC-04 | A.5.30 ICT readiness for business continuity |
| Testing, training, exercises (step 6) | CP-3, CP-4, CP-4(1), CP-4(2) | ID.IM-04 | A.5.30 |
| Strategies and alternate sites (step 4) | CP-6, CP-7, CP-8 | PR.IR-03 | A.8.14 Redundancy of information processing facilities |
| Backup and reconstitution | CP-9, CP-9(1), CP-10, CP-10(2) | PR.DS-11, RC.RP-03, RC.RP-05 | A.8.13 Information backup |
| Executing recovery | CP-10 | RC.RP-01 | A.5.29 |
CIS Controls v8.1 Control 11 (Data Recovery) covers the backup elements at control level. ISO 22301 is the management system standard for the wider programme; see the ISO 22301 Business Continuity Guide.
Common failure patterns
- RTO set without an MTD: IT picks a number it can meet, and the business discovers in an outage that it needed recovery days sooner.
- Template filled, method skipped: the ISCP looks complete but its recovery order does not follow any BIA priority.
- Exercise depth below impact level: high impact systems that have only ever had tabletop exercises, never a failover.
- High availability treated as recovery: replication copies corruption and encryption to the standby, exactly as NIST warns.
- No reconstitution step: systems are brought back without validation data testing, so data loss or tampering is found weeks later.
- Stale appendices: contact lists, vendor numbers and inventories out of date because maintenance was never scheduled.
Practitioner checklist
- Download the current NIST BIA and ISCP templates from the CSRC page, not an old copy.
- Confirm the FIPS 199 availability impact for each system before choosing a template.
- Get MTD signed by the process owner and authorising official; derive RTO and RPO from it.
- Choose strategies that meet the RTO and can be shown to do so in an exercise.
- Write recovery procedures as step-by-step checklists with no assumed steps.
- Include validation data and functionality testing in reconstitution.
- List break-glass accounts, backup credentials and decryption keys in the ISCP and test them.
- Exercise at the depth the impact level requires and record an after-action report.
- Update control references to SP 800-53 Rev. 5, including CP-11 to CP-13 where relevant.
Standards and references
- NIST: SP 800-34 Rev. 1 Contingency Planning Guide for Federal Information Systems
- NIST: SP 800-34 Rev. 1 full text (PDF)
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
- CIS: Critical Security Controls v8.1
- ISO: ISO/IEC 27001:2022 Information security management systems
Related NHI Mgmt Group resources: NIST SP 800-53 CP Contingency Planning · Business Continuity and Disaster Recovery Guide · Business Impact Analysis Template · Backup and Recovery Testing Checklist