This infographic was created from content from our new blog series that focuses on disaster recovery planning. While most steps may be self-explanatory, I highlighted a few important points for each step below.
1. Conduct an asset inventory
You must fully understand what you have living in and on your network before walking through the process of building your plan. Look at everything from old servers that have been stuck in random closets to your highest priority applications. Once you have a lay of the land, you will need to identify any dependencies (i.e. SharePoint Server 2013 is dependent on Windows Server and SQL Server so those need to take priority in this circumstance).
2. Perform a risk assessment
Many people interchange risk assessment and business impact analysis and there’s plenty of heated commentary and opinions on best practices for this arena. That’s not something I’ll get into now, but I’d encourage you to do some research if you’re serious about starting this process. Simply put, the purpose of this step is to understand the potential risks that may impact your business, and the likelihood of them doing so.
3. Define criticality of applications and data
This is when you have a heart-to-heart discussion with all key stakeholders and application owners. Everyone will think their app is the most important so you’ll want to refer back to your asset inventory, ask the right questions, and make a collective decision. This is an essential part of any IT disaster recovery plan.
4. Define recovery objectives
RTOs and RPOs should be included in this phase of planning. How much downtime can you afford? How soon will you be able to get back online after a major outage or disaster? Since you’ve already defined which apps are most critical (see step 3), this phase delivers a plan that matches IT capabilities with the needs of application owners and key stakeholders.
5. Determine the right tools and techniques
Just like you can’t get to Europe from the US in a rowboat, you can’t restore a mission-critical app in 15 minutes without the right tools. Figure out what you have today, and whether that will ensure your ability to successfully execute against your disaster recovery plan. If you want to begin replicating data to a secondary location, you will not only need the right hardware and software, but also the right techniques.
6. Get stakeholder buy-in
Remember that heart-to-heart chat in step 3? Use what you’ve learned along the way to re-connect with key stakeholders and get their buy-in on your plan. Oh, and I’d suggest getting this in writing.
7. Document and communicate your plan
Once everyone is on the same page, you need to write your plan down and make sure it’s in the hands of anyone who has a vested interest in the success of your company. This may not need to get to the frontline sales makers, but that’s ultimately your decision. The point is to communicate with everyone, not to assume everyone knows what you planned in secret meetings and conference calls.
8. Test and practice your disaster recovery plan
Set some time aside to test your assumptions and see if the plan you’ve collaboratively created actually works. You’ll likely find a few things that will need adjustment. If you run into problems, great! I don’t know about you, but I’d much rather work through a problem in a test than a real world crisis.
9. Evaluate and update your plan
Review the plan you currently have in place to ensure that it’s still meeting business needs. In a perfect world, your business would be growing and thriving. The timing will depend on your business, but some firms test twice a year, and some need to test much more frequently.