About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.
A cyber recovery runbook is a short, usable record of who may decide, what must be true before the next action, and where the decision is written down. It is not a transcript of every command a platform can run. NIST SP 800-184 says this about itself: the publication is not an operational playbook. It is guidance for writing customised playbooks before the event. A playbook, in that guide, is an action plan with the steps an organisation will follow to recover. Those steps include major phases, and exit criteria for each stage, such as telling the people who must know. The same guide says many of the underlying procedures will be technical, and that they should be automated where you can so a tired team makes fewer mistakes. Automation and commands live in the procedures you have tested. They do not belong as untried recipes pasted into the document you will open when the directory is down.
NIST SP 800-61 Rev. 3 describes playbooks the same way: actionable tasks for a scenario, easier to use than a policy essay. Executing the recovery portion means selecting, scoping, prioritising, and performing actions securely, verifying integrity, declaring the end against criteria, and finishing the record. People with a recovery duty are told, in advance, which authorisation each part needs. The end of recovery is declared on criteria, and an after-action report covers what happened, what was done, and what was learned.
The September 2023 #StopRansomware Guide tells you to follow your approved incident response plan, and it offers a checklist as the recommended companion, not as a substitute for priorities you have already set. It wants a hard copy and an offline version, written approval from the chief executive or equivalent, and a communications plan with holding statements whose level of detail you have already agreed. NIST IR 8374r1 adds the ransomware-specific contents: roles, a decision strategy, the critical services that set priority, an out-of-band path, and an exercised plan.
This article is the contents page and the rule for what a page may say. It does not repair a disk, a boot loader, or a directory forest.
Two documents, not one encyclopaedia
SP 800-184 separates a recovery plan, which records strategies and decisions, from the playbook you execute, and it says not to duplicate every contingency plan you already have. The test is whether the necessary information is documented, easy to reach, and actionable. Apply that test by splitting the paperwork.
The decision runbook is what a commander can hold. It names authorities, gates, records, and stop rules. It is stable across ransomware, a destructive wipe, and a suspected quiet intrusion, even when the technical annexes differ. It is the document that must exist on paper and offline, because CISA and IR 8374r1 both expect the electronic copy on the affected network to be unavailable or unwise.
Scenario annexes hold the procedures for one kind of event: which tools your team has actually licensed and exercised, which images you build from, which backup product's catalogue you export. SP 800-184 says each playbook can focus on a scenario while the fundamental activities stay similar. An annex that contains commands nobody has run in a test is not an annex. It is a rumour. SP 800-184 is blunt that organisations should not take shortcuts through the procedures they did define. The matching rule is to leave undefined procedures out, rather than to invent them in the annex for completeness.
Our recommendation, not a heading in the NIST guide: if a page does not change a decision, delete it from the decision runbook. Vendor manuals remain vendor manuals. The runbook points at the tested annex by name and version. It does not absorb it.
What every decision page contains
Use one shape so people can find the authority at 02:00. SP 800-184's list of plan contents is the source of the fields. The labels below are an editorial arrangement of that list.
| Field | What it must say | What it must not say |
|---|---|---|
| Decision | The question, in one sentence. Example: which copy is eligible to stage. | A tour of the product. |
| Authority | The role that may decide, and the deputy. SP 800-184 asks for two or more named managers who may activate the plan, with contacts. | "The backup team", with no names and no out-of-band number. |
| Inputs | The records required before the decision is allowed. A catalogue classification, a staging result, a legal view. | "Use your judgement" with no input named. |
| Stop rule | The condition that forbids the next action. Our recommended implementation makes missing prerequisites explicit instead of treating them as a pass. | A stop rule that can be overridden by the same person without a record. |
| Record | Where the decision, the time, and the name are written, on a system that does not depend on the tenant you may have lost. | A chat channel that disappears, or a ticket system behind the downed identity provider. |
| Exit | What becomes true if the decision is yes, and which page is next. SP 800-184 wants exit criteria per stage. | A yes that silently includes three further changes, such as a network join and a password reset. |
These six decision areas provide one compact starting structure. Expand or subdivide them for the estate’s dependencies, legal obligations and decision owners; NIST specifies no six-page limit.
- Activate. Who may start recovery, how they are reached without mail, and what activation does not permit. Activation is not a restore.
- Communicate. The holding statement, the first-hour call list, and the rule that staff instructions match the technical plan. Public remarks stay with the approved message.
- Select a copy. The inputs are the catalogue classification and the reachability of each copy. The stop rule is an empty candidate set, which is reported, not papered over with the newest job.
- Stage. The inputs are the chosen copy and the acceptance criteria. The exit is permission to place that system on the recovery segment, not permission to join production.
- Change a boundary. A route, an agent, a directory join, or a returned token. One change per decision. SP 800-184's scenario restores infrastructure before applications and requires a security sign-off before network operations resume.
- Declare the end of tactical recovery. SP 800-61 Rev. 3 and the CISA checklist both require criteria and a designated authority. The criteria should include the gates above, not only "users can log in". SP 800-184's termination steps add a stand-down and continued monitoring for persistence. Ending the tactical phase is not the end of the strategic work: lessons, root-cause fixes, and the improvements IR 8374r1 expects you to feed back into the plan.
Aim for concise decision pages. Put detailed screenshots and technical steps in accessible annexes when that makes the plan easier to use; the format is an editorial choice.
Tactical pages and the strategic half
SP 800-184 splits recovery into a tactical phase, which returns capability, and a strategic phase, which improves the estate so the same event is harder. The runbook that people carry is the tactical one. The strategic half is a scheduled review, not a chapter the incident commander reads while systems are still isolated. Mixing them produces a document that lectures about architecture in the section that should name a phone number.
The tactical runbook does include one forward pointer, because SP 800-61 Rev. 3's RC.RP-06 and SP 800-184's appendix both require a record of what was learned. Name who writes the after-action report, and the date by which the six decision pages are corrected. A lessons-learned meeting with no owner for the runbook change will repeat the blank page next time. IR 8374r1 says testing trains the people who must execute the plan and that processes have to be updated as tactics change. The strategic half is that update. It is not a second incident.
How the runbook survives the incident it describes
SP 800-184 says to protect the plan with the same care as a security plan, because it holds sensitive detail: contacts, locations of offline media, ways around normal processing. CISA wants a hard copy and an offline version, and executive approval in writing. Those are handling rules, and they are part of the design.
- The decision runbook's offline copy does not rely on the identity provider. Paper qualifies. An encrypted file qualifies only if the people named on page 1 can open it without that provider.
- The copy that contains safe locations and phone numbers is not the copy you email to the whole company. Staff receive the holding statement. Commanders receive the runbook.
- A version and a date are on the front. An exercise result that contradicted a page is either a corrected page or an open item. An uncorrected contradiction will be resolved, during the incident, by whoever shouts.
- Annexes that contain commands are versioned with the tool they were tested against. An annex for a product you migrated off last year is a hazard. Remove it. SP 800-184's warning against shortcuts cuts both ways: following a dead annex is not discipline.
IR 8374r1 says many of these preparations are within reach of a small organisation. A six-page decision runbook, a contact sheet, and one exercised annex for "we cannot trust the backup console" can be a useful initial set, with scope gaps recorded and addressed. A portal full of untested documents is not a more mature version of the same thing. It is a place to lose the phone numbers.
What you leave out on purpose
The runbook's authority comes from what it refuses to include.
- Operating-system repair sequences, boot repairs, and filesystem surgery. They are specialist procedures. Untested repair steps can damage evidence or the copy you have not finished classifying. If you have a tested procedure, it lives in an annex and the decision page only says when that annex may be opened.
- Directory-forest recovery, including authoritative restores. The decision page says when identity is allowed to become authoritative for other systems. The forest procedure, if you have one that has been rehearsed, is an annex with its own owner. It is not a section you compose from memory.
- Commands copied from a blog during the incident. They are not in the runbook because they were not in the exercise. SP 800-61 Rev. 3 allows the plan to change when facts change. The change is a new decision, recorded, not a new command executed because it was the first search result.
- A promise of a recovery time you have not measured. SP 800-184 treats recovery-time objectives as agreed planning targets, which must not be presented as measured or guaranteed recovery times, and it asks for workarounds when you will miss them. The runbook names the workaround and who tells the business. It does not invent a clock.
Hypothetical: the runbook's "restore" page is fourteen screenshots of a backup console, ending in "click recover". The console is the system that has just been encrypted, and the screenshots show the daily administrator's login. The page cannot be followed, and if it could, it would use the account you should be treating as suspect. Replace it with the select-a-copy decision, an authority, a stop rule for an empty candidate list, and a pointer to an annex that an exercise actually completed on a disconnected copy. The screenshots can stay in the annex if they still match the product. They are not the runbook.
Risks and limits
- A runbook that has not been exercised is a draft. IR 8374r1 and SP 800-184 both treat exercise as part of having the plan. This article did not run an exercise.
- Structure does not supply missing copies, missing keys, or missing deputies. A perfect page that names a person who left last year is a defect the strategic review exists to catch.
- SP 800-184 dates from December 2016. SP 800-61 Rev. 3, in April 2025, still cites it for recovery plans. The fictional scenarios in SP 800-184 are illustrations of the structure, not scripts.
- The CISA checklist is more specific about ransomware technical signs than a decision runbook should be. Keep those signs in the hunt annex. Let the decision pages consume the hunt's output.
- No claim is made that any particular template product or governance portal implements this shape.
Research and verification
This article was drafted with AI assistance on 11 November 2026 and independently reviewed against public sources on 13 November 2026. It is source research, not a lab-validated recovery procedure or evidence of a NetLeverage product capability. No article commands or recovery operations were executed.
Sources
Independently reopened 13 November 2026.
- NIST SP 800-184, Guide for Cybersecurity Event Recovery (December 2016).
- NIST SP 800-61 Rev. 3 (April 2025).
- NIST IR 8374r1 (June 2026).
- CISA, FBI, NSA, and MS-ISAC, #StopRansomware Guide (September 2023). Live official page independently reopened 13 November 2026.
This article was originally published on .