Adaptable recovery template for a small IT service. Fill it with verified internal details; the illustrative roles are not contact information.
Research-based; no hands-on test claim.Make the first page useful during an outage
Record the service name, runbook owner, version, review date and activation authority. Define the conditions that trigger recovery and who can declare an incident. Include a contact tree with primary and alternate roles, supplier contract references and an out-of-band communication channel.
Keep secrets out of the runbook. Reference the approved emergency credential process and verify that authorised responders can use it when normal identity services are unavailable. An inaccessible document repository can turn a good runbook into a missing dependency.
Recover in dependency order
Map the service to identity, network, DNS, storage, databases and external integrations. Restore the prerequisites before the application that consumes them. Name the exact supported procedure for each component and its expected output.
Use the sequence table as a template. Add the real system identifiers, acceptance checks and stop conditions. If a step fails, the next action should say whether to retry, roll back, select another recovery point or escalate. Avoid open-ended instructions such as fix networking.
| Stage | Owner role | Gate before continuing |
|---|---|---|
| Declare and contain | Incident lead | Scope, authority and communication agreed |
| Recover prerequisites | Infrastructure lead | Identity, DNS, storage and access verified |
| Restore data | Recovery operator | Correct point and destination confirmed |
| Validate service | Application owner | Business transaction accepted |
| Resume operation | Incident lead | Monitoring, communications and rollback ready |
Put decision gates around dangerous transitions
Before restoring over production or switching traffic, confirm the recovery point, current incident containment and the effect on data written since that point. Get the required business decision on data loss. Preserve evidence where an incident investigation is under way.
Define a return-to-primary plan separately from initial recovery. Moving traffic back may need reconciliation or another outage. Record who can approve failback and which measurements show that it is safe.
Exercise the document, not just the infrastructure
Ask a responder who did not write the runbook to follow it in a controlled exercise. Record every missing permission, ambiguous instruction and dependency that required outside knowledge. Measure the full recovery path against the service objective.
After the exercise, update the sequence and verify access to the revised copy. Set a review trigger for infrastructure changes and personnel changes, as well as a periodic date. Keep an offline or otherwise independent controlled copy and retire stale copies deliberately.