Untested plans are simply assumptions, not capabilities. Don’t fall into the psychological trap of feeling comfortable with your recovery posture without fully validating all defined flows. Not just once at the beginning, either, while you’re first setting things up; this testing needs to be ongoing at a relatively frequent cadence. Technologies and environments change, named employees leave, and runbooks become stale for both of these reasons. A solid but untested plan can become useless much faster than one often expects.

So test, test, and keep on testing. Tabletop exercises can validate procedural logic, but they can’t effectively flag nitty-gritty infrastructure gaps that only surface during actual recovery flow attempts. Full simulations reveal a lot more, but they also cost more – run a quick cost-benefit analysis for your org to determine ideal frequency, but ultimately you should be running both. Specifically assign a named owner to every exercise to tabulate learnings and drive documentation and process updates flagged as necessary.

Of course, simulations are only half the battle; real-world incidents are also unnervingly capable of exposing gaps that even the most extensive exercises miss. Because of this, they are often some of the best learning opportunities available. By policy, a blameless post-mortem should be required after every real-world recovery to discuss what worked, what failed, and whether any changes are needed to existing runbooks, policies, etc.

The term blameless was bolded intentionally – people operating in an environment without this as a foundation can become worried about retaliation or judgment. This often makes them much more likely to hide useful information to protect themselves, resulting in the loss of critical learning opportunities and potential process improvements.