NIST SP 800-34 Rev. 1 defines a seven step contingency planning process: policy, business impact analysis, preventive controls, recovery strategies, the plan itself, testing and training, and maintenance. A small team can follow the same order in a few weeks by keeping each step short and tied to real systems.
What the document is
SP 800-34 is NIST's contingency planning guide for federal information systems. You do not need to be a federal agency to borrow its structure. It is a public, plain description of how to prepare for disruption, and many security and resilience programs echo the same order of work. Using it as a checklist is not the same as claiming any attestation or certification, and you should not describe it as one.
The seven steps, translated
| NIST step | What NIST says it does | A small team version |
|---|---|---|
| 1. Policy statement | Gives authority and guidance to build a plan | One page: who owns continuity, how often you test, who can declare an incident |
| 2. Business impact analysis | Identifies and prioritizes systems that support critical processes | A ranked list of services with an agreed downtime tolerance for each |
| 3. Preventive controls | Reduce the effect of disruptions | Backups, redundancy, monitoring, access to recovery credentials |
| 4. Contingency strategies | Ensure quick, effective recovery | Choose a recovery approach per service, such as restore, rebuild or fail over |
| 5. The plan | Detailed procedures for restoring a damaged system | A runbook per top service, written for someone who did not build it |
| 6. Testing, training, exercises | Validate recovery, prepare people, find gaps | A timed restore and one tabletop each quarter |
| 7. Maintenance | Keep the plan current | A review date on each runbook and a trigger to update after changes |
A four week schedule
Week 1: write the policy page and list your services. Rank the top five by how soon customers would notice a failure.
Week 2: for those five, run the impact analysis conversation. Ask the owner how long each can be down and how much recent data can be lost. Record the answers using the terms in our post on RTO, RPO and MTD.
Week 3: check preventive controls. Are backups running, encrypted and restorable? Can the people who need recovery access reach it when the identity provider is down? Choose a recovery strategy per service and write it down.
Week 4: write one runbook for the top service and test it with someone who has not used it. Record what they stumbled on, fix it, and set the next review date.
Making each step hold up
- Keep the policy short enough that people read it.
- Put names and roles, not just team labels, in the plan, with a backup for each.
- Store the plan where you can reach it when your main systems are unavailable. A runbook kept solely on the system that failed is no help. Our post on recovery tools that depend on the failed system covers this.
- Treat testing as the step that proves the others. NIST describes testing as validating recovery capabilities, training as preparing people and exercises as finding gaps.
A worked example: ranking five services (step 2)
This example is hypothetical. A twelve person company lists its services and asks one question of each: if this stopped today, how soon would a customer notice, and how bad would it be?
| Service | Customer notices in | Impact | Rank |
|---|---|---|---|
| Sign in and sessions | Minutes | Customers locked out | 1 |
| Core API | Minutes | Customers cannot do their work | 2 |
| Billing jobs | Days | Late invoices, recoverable | 3 |
| Support desk | Hours | Slower replies | 4 |
| Internal analytics | Weeks | Reports delayed | 5 |
The team now writes a contingency plan for the first two. For the rest, a short note with a recovery contact will do. That is the point of the business impact analysis in NIST's process: it directs effort to where it matters.
What a one page plan for the top service contains (step 5)
Below is a skeleton you can copy into your own tools.
- Purpose and scope: which system, which environments.
- Roles: incident lead, technical lead, communications owner, each with a backup.
- Activation: the conditions that start the plan and who may declare it.
- Recovery steps: the numbered procedure, written for a person who has not done it before, with the command or screen for each step.
- Dependencies: what must work first, such as network, identity and storage.
- Verification: how you know the system is correct again, not just running.
- Return to normal: how you resume the usual process and record what happened.
- Contacts and locations: where credentials and backups are, and how to reach people when chat is down.
Our post on what goes in a business continuity plan has further detail.
Testing and training (step 6)
NIST separates three activities. Testing validates that recovery works. Training prepares the people who will carry it out. Exercises find gaps in the plan. A small team can cover all three with a simple calendar:
| Activity | Example | Frequency |
|---|---|---|
| Test | Timed restore of the top service into an isolated environment | Quarterly |
| Training | A new on call engineer walks through the runbook with a mentor | At onboarding |
| Exercise | A one hour tabletop on a failed dependency | Twice a year |
Record the date, the people, what went wrong and what changed. The record is the proof you did the work, and it feeds step 7. Our post on choosing between a tabletop, a functional drill and a game day helps you choose.
Maintenance (step 7)
Plans go stale when the system changes. Add a line to your change process: when you change architecture, vendors or access, ask whether the plan needs an update. Put a review date on every runbook. Assign each plan an owner who is accountable for the date, not just for writing it once.
Try it yourself
Open the framework mapping demo and look at how controls and evidence are connected to a framework. Think of each step above as something you could attach evidence to, such as a policy page, a ranked list or a test record.
Click through it at your own pace, or open it full screen.
Quick check
Is following SP 800-34 a certification?
No. It is guidance, not a certification or an audit. You can use its process to organize your own work and to explain it to customers, while being clear that you are using it as guidance.
Do I need all seven steps for a small product?
Yes in spirit, but each can be one page. The impact analysis and the testing step usually deliver the most value.
Do customers expect this exact framework?
Customers usually ask whether you have a tested recovery plan, not which document you used. Using a public guide helps you structure the work and explain it, while avoiding any claim of compliance or certification.
Sources
- NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems
- NIST CSRC publication page for SP 800-34 Rev. 1
Last reviewed: 19 October 2026.
