A disaster recovery plan (DRP) is a great way to stay proactive about your data security. But a DRP is no good unless you test it—you have to make sure it actually works, after all.
There are some things you can do during your drill to ensure you get results—good or bad—that are reliable. The goal is to test whether the plan is effective as drafted or if something specific needs to be changed to improve it.
There are a lot of factors in play with a DRP, so it pays to be methodical.
Define your goals
First, before you conduct a test, you should define your goals.
We’re not talking about goals like “Have the server back up in 20 minutes.” For the tests they will be more like “How good are communications between departments?” or “How does stress make the IT team interact with each other?”
Your goal is to answer those questions, whatever they may be. Strategic questions that give you an idea of how prepared you really are. You want to test different variables to see how they influence your DRP’s execution.
Your IT crew will be trying to get the server up quickly, but you’ll be observing their performance through the lens of “communication.” Do they ask for help when they need it? Do they keep the other departments in the loop? Can they document what they’ve done and what worked?
You need to think of all the angles that could cause problems and test for each one.
Related: 7 typical disaster recovery plan mistakes (and how to fix them)
Get the team together
This may seem like a no-brainer but get the team together and on the same page.
If anyone is out of the loop, it creates a point where communication could break down. If everyone is on the same page from the beginning, everything will run more smoothly.
You may also want to include backup personnel, just so that they have an idea of what they are supposed to do. Running a disaster recovery plan 100% from the documentation can be difficult even without the pressure that a disaster provides.
Run different types of tests
There are all kinds of tests to you run, ranging from a simple conversation walking team members through the process to a fully simulated disaster.
Don’t rely on just one kind of test. You want a variety.
This is important because it will give you a more well-rounded idea of how your DRP will actually function. Sometimes what makes sense in one test doesn’t make sense in the another. Or what the technicians might do to provide a hasty fix might violate compliance regulation.
You can use the culmination of all that data to make your DRP as solid as possible.
Related: Disaster recovery testing: A vital part of the DR plan
Run tests often
If it’s been more than a year since you’ve run a test, do you know if it’s still applicable? How much could change in your company in a year? Or six months? In one month?
You don’t have to test every day, but decide on an interval that makes sense based on how you do business and how often your network configuration, staff, tech tools and compliance requirements change.
Take good notes
Good documentation of these tests is a must. Not only will it help you remember what exactly happened when, but it will help anyone else who reviews the test see the results, which keeps everyone on the same page.
Post-test assessment
Of course, you want to take any new insights learned during testing into account to make your disaster recovery plan better. Valuable data does no good for anyone just sitting in a drawer.
This is especially important when things go wrong during a test.
If the downtime is double what was expected or if a new aspect comes up that no one saw before, then it is important to determine what caused the holdup and how you can overcome it in the future.
What if the disaster that you’ve been planning for happens tomorrow?
In conclusion
Communication is paramount.
Whether that means meetings with the team or solid documentation. A good DRP drill should be about setting everyone up for success so you’re well prepared for whatever the future holds.
We’ve covered a lot of ground, but everything really just boils down to the scientific method: Ask a question, perform a test, observe the results, refine your understanding.
Disaster recovery is a lot like science in many ways, so treat it like science. Reach out to experts in the field and ask for guidance if you need it.