After the drill: evidence, the review and findings that get fixed

This article is for the drill lead and for the manager who receives the result. A recovery drill is only as valuable as what is recorded during it and what is changed afterwards. It describes how to capture evidence while the exercise runs, how to run the review, and how to write findings that actually get fixed.

The record is the product

When a drill ends, the restored copy is deleted, the isolated environment is torn down, and the participants go back to their day jobs. What remains is the record. If the record is a paragraph that says “drill completed successfully”, the organisation has bought itself a feeling. If the record contains times, identifiers and observed problems, it has bought something it can use: a baseline to beat next time, a list of fixes, and honest evidence for anyone who later asks what was done.

So treat the evidence as a design requirement, decided before the drill starts, as covered in designing a recovery drill.

Capturing evidence while it happens

The scribe’s job is to produce a contemporaneous log. Reconstruction from memory the next day is unreliable, and people unconsciously tidy the story. A log line needs a time, an actor and an event. A short example from a database restore drill:

09:02  Lead   Scenario declared: primary storage lost. T0.
09:04  Op     Opened runbook v7 (printed copy). Cannot find restore host IP in prerequisites.
09:09  Op     Asked scribe to look up host IP in CMDB. CMDB unreachable (hosted on lost storage).
09:15  Lead   Host IP provided from lead's notes. DEVIATION 1: not in runbook.
09:21  Op     Restore of orders.dump started. Backup ID and time noted: nightly-2026-10-08, 01:00.
10:03  Op     Restore complete (42 min). pg_restore reported 0 errors, 2 warnings (see below).
10:07  Ver    Newest order timestamp in restored copy: 2026-10-08 00:58.
10:19  Ver    Order lookup check passed on 3 of 3 sample orders.
10:20  Lead   Clock stopped. Elapsed 78 min.

Several habits make this log worth having:

• Record the restore point as an identifier plus the time it represents. The job’s start time and the data’s as-of time can differ; the gap between the as-of time and T0 is your measured recovery point.
• Mark deviations as they occur. Anything the operator did that was not in the runbook, or any place the runbook was wrong, gets a label. The deviation count is the headline metric for the document’s quality.
• Capture output, not just conclusions. Save the terminal transcript or paste the key lines. Screenshots help for graphical tools. Redact credentials, tokens and personal data before storing; assume the record will be read by more people than took part.
• Take the baseline before. Row counts, file counts or checksums recorded before the drill give the verifier something to compare with. If no baseline exists, say so in the record.
• Time the stages, not only the total. Detection and declaration, mobilisation, transfer, rebuild, verification. The breakdown shows where the time goes and where to invest.
• Log the dead time. Waiting for a person, a credential, an approval or a download is often the largest component and appears nowhere in a summary that says only “restore took 42 minutes”.

When the exercise is evidence for someone else (an auditor, a customer, an insurer), add the scope in plain words: what was in scope, what was out, which scenario, which environment, who took part. Make it clear that it was an exercise. Save the finished record in a place with controlled access, finalise it after the review (so it is not edited later), and keep it as long as your own retention rules require.

The review meeting

Hold the review soon after the drill, ideally within a few days, while details are fresh and before the log’s abbreviations stop making sense. Invite everyone who took part, including the verifier and scribe. The government emergency-exercise world calls the output an after-action report and improvement plan; you do not need that formality, but the pairing of what happened with what we will change is the right shape.

A workable one-hour agenda:

1. Restate the hypothesis and the result. Read the objective and the measured times side by side: target RTO against measured elapsed time, target RPO against measured recovery point. State whether the success criteria were met, using the criteria written beforehand. Do not move the goalposts afterwards.
2. Walk the timeline. The scribe reads the log. Participants correct and add. Pay special attention to gaps in time.
3. Identify what went well. Briefly, and specifically, so those practices are preserved.
4. Identify problems. For each deviation or delay, ask what happened, why, and what would have prevented it. Ask “why” until you reach something you could change, usually two or three levels deep.
5. Agree actions. Each with an owner and a date.
6. Decide the retest. Which finding must be proven fixed, and how.

Run the meeting as blameless. The question is never “who got it wrong?” but “what made the wrong action easy, or the right one hard?” If people expect to be blamed, they will edit their accounts, and the next drill will be a performance.

Writing findings that get fixed

A finding should be an observation plus an impact, not an accusation or a vague hope. Compare:

• Weak: “Runbook needs improvement.”
• Useful: “The restore host address was not in the runbook; the operator spent 11 minutes obtaining it from the lead’s personal notes, and the usual source (the CMDB) was unavailable in this scenario.”

Classify findings by what has to change, since that determines who owns them:

Class	Example	Typical owner
Documentation	Missing host address; step out of order	Runbook owner
Access and secrets	Restore credential not retrievable without the failed system	Security or platform lead
Technical	Restore slower than target; backup missing a data set	Service engineer
Process and authority	Nobody sure who may declare a disaster	Service owner or manager
Target	Measured time exceeds the stated RTO	Business owner (decides: fund, relax, or accept)

Targets deserve separate treatment. When a measured figure misses the stated target, the engineers cannot resolve it alone, because the choices (spend money, change the target, accept the risk) belong to the business owner. Present the number and the options plainly. See RTO and RPO for how to keep stated, estimated and measured figures separate.

Rank by consequence for the next real recovery, not by how easy the fix is. A missing credential path that would block recovery outright outranks a ten-minute inefficiency. Then give each action:

• A single named owner (a team is not an owner).
• A due date.
• A verification method: how will you know it is fixed? “Updated the runbook” is an edit; “the runbook step was followed by a different operator in the next drill with no deviation” is verification.

Track the actions somewhere people already look, such as your ticket system, and report progress to the same people who received the drill result. Unresolved actions from a previous drill should be the first agenda item of the next one.

Reporting upward without overclaiming

The summary for management has to be short and has to be true. State:

• What kind of exercise it was and what it covered, in a sentence.
• The measured result against each target, with the date.
• The most consequential findings and what is being done.
• What has not been tested.

Avoid the temptation to compress a mixed result into “successful”. If the data restored but took twice as long as the target, that is a result, and the business owner needs it. Equally, avoid language that implies more coverage than you had: a restore of one database does not demonstrate that the organisation can recover. Say which parts were demonstrated. The same discipline protects you when the report is quoted later by someone who did not read the caveats.

Closing the loop

The review ends with a retest, not a report. Schedule it before leaving the meeting: a short drill that targets the findings, repeated until the same step passes without a deviation. Then fold the lessons into the standing programme: update the runbook, adjust the cadence if a system proved fragile, and change the next scenario so that you are testing something new instead of the thing you already fixed. The tabletop and restore testing articles describe two ways to do the next round.

Common mistakes

• Writing the record afterwards from memory. Details evaporate and the story improves.
• A pass/fail verdict with no numbers. It cannot be compared with the next drill.
• Findings without owners or dates. They will not be done.
• Fixing the document but never retesting. An edit is not a verified fix.
• Letting the author of the plan chair the review. Use someone for whom a poor result is not a personal failure.
• Keeping the evidence only on the systems that may be lost. Store the record where it survives your scenario.
• Quoting a tabletop as a technical result. Discussion-based exercises verify nothing about restores.

What to do next

Take your last exercise, or your next one, and write three things before it starts: the timestamps you will log, the baseline you will capture, and who will chair the review. Use the printable drill checklist to keep the day on track and the drill planner to list the evidence your plan should capture; the planner prepares a plan and records nothing about any drill that actually takes place.