If a recovery pitch promises an instant return to work, test the last part of the claim. Can an authorized user complete the business task after the restore? Your disaster recovery runbook should put that acceptance check beside the recovery order and its owners, with a route to the detailed procedures. A server starting is an encouraging intermediate result.
I'd write the summary for the engineer taking over, then ask the client's business owner to check the acceptance condition. The page should show who can make the next decision. It shouldn't require the person running recovery to reconstruct the agreement from old emails.
Make the Page a Control Sheet
A short runbook coordinates this client's recovery work. Keep the detailed, tested technical instructions in maintained procedures and record where each is found. The summary is a route card; the detailed procedures supply the turn-by-turn instructions.
Don't make a one-page limit a reason to remove a necessary step. If the summary needs more room to be usable, give it more room. A readable reference to a controlled procedure is better than reducing a critical instruction to a cryptic abbreviation.
Confirm which disruption the runbook covers. A planned recovery exercise and recovery after a suspected compromise need different decisions before systems return to use. Refer the latter to the agreed incident response and recovery authority rather than treating every outage as a routine restore.
Start With the Business Result
Ask the client which activity must work first and what result will count as usable. Record the decision-maker who can accept that result. Don't infer priority from the size of the server or the order in the backup console.
For a hypothetical example, suppose the client needs its order-processing application before staff can resume dispatching orders. The acceptance check should exercise that business task through an authorized test user. A screenshot of the application login page wouldn't establish the same result.
Keep the client's recovery objectives beside the test evidence. A recovery time objective is the intended time to restore the service; a recovery point objective describes the point in time to which data must be recovered. Agree those objectives for the actual business need instead of inserting a standard promise into every client's page.
If the demonstrated result doesn't meet an objective, record the gap. Don't change the test label to make it pass. Take the needed service or budget decision back to the authorized client contact.
Fill the Summary With Named Decisions
Use this as a structure to complete for a particular client. Each row needs a named person or defined role with a current contact route. The technical procedure reference must identify the applicable version, rather than simply sending the engineer to a vendor homepage.
| Runbook Field | What to Write for This Client | Who Confirms It |
|---|---|---|
| Scope and Activation | The covered disruption, affected business activity, and authority to start this recovery plan | The client decision-maker and MSP recovery lead |
| Recovery Location and Access | The approved recovery environment and controlled route to the access needed | The responsible engineer |
| Dependency Order | The client-specific sequence, with each prerequisite and a reference to its tested procedure | The recovery lead with the relevant system owners |
| Step Acceptance | The result that permits the next dependent activity to proceed | The engineer assigned to that procedure |
| Business Validation | The approved test task and evidence of an acceptable result | The designated client representative |
| Staff Communication | Who sends the current status and the instruction on whether staff may resume work | The assigned communication owner |
| Return and Evidence | Authority to resume normal operation, remaining work, and location of the test or recovery record | The recovery lead and client decision-maker |
Keep passwords and recovery secrets in the approved access system, not copied onto the summary. Check that the authorized engineer can reach that system under the disruption being planned. A reference is only useful if its access path survives the scenario.
Check document access too. If the runbook is stored only inside the service being recovered, the engineer may be blocked before the first technical step. Provide an approved accessible copy appropriate to the client's security requirements and keep it current.
Write the Order From Dependencies
It depends on the application dependencies, the recovery location, and the access available during the disruption. That is why I wouldn't publish a universal server-start order. Identify what each activity requires before the next one can succeed, and verify those prerequisites in the exercise.
For the hypothetical order-processing application, record the supporting services its owner identifies and the test that establishes each is ready. Then connect them to the application recovery procedure. Don't assume that a dependency is healthy just because another engineer has marked a different server complete.
Write what happens if a prerequisite fails. Name the person who decides whether to retry or change the recovery approach. The next engineer shouldn't have to guess whether an incomplete step is optional.
Test the Handoff Through to Use
Have a qualified engineer use the written procedure in an approved recovery test. Make the scenario and isolation boundaries explicit so testing doesn't become an unplanned production change. Keep the real restore result with the procedure version used.
Record where the engineer stopped to ask for information. If the author had to supply an unwritten instruction, add it to the controlled procedure and check the affected step again. The author's memory isn't part of the backup service.
If the test stops at the machine booting, a user may be the first to discover that the business workflow still fails. Include the agreed business validation before treating the service as ready. Record what the exercise didn't cover as carefully as what it established.
Don't reuse the measured recovery time as a guarantee for a different disruption. The recovery target or available resources may differ. Keep the conditions of the test visible whenever you use its result to discuss the client's expectations.
Keep Communication Attached to a Decision
Give the communication owner an agreed update route and the next update point. Explain what is known and what is still being checked. An estimate should be identified as an estimate, with its basis, rather than quietly becoming a promise.
Prepare wording for staff before the exercise. It should say which service is affected, what action staff should take, and where the next update will appear. Use only approved alternate work arrangements; the recovery email shouldn't invite staff to invent their own data-handling process.
When validation is complete, obtain the recorded acceptance and tell staff what they may resume. Keep any restrictions explicit. A green recovery task in the MSP's system doesn't communicate permission to the client by itself.
The model's position is to fix service delivery before adding clients. Give maintaining and testing these procedures actual capacity in that delivery plan. Start by handing the draft to someone who didn't write it and checking the first place their next decision becomes unclear.
mspoutpost.com/articles/disaster-recovery-runbook-order-owners-and-acceptance
Written by Dana Kowalski
MSP Outpost publishes information, not legal, financial, insurance, tax or compliance advice, and reading it creates no professional relationship. For decisions about your business, talk to a qualified professional.