How can IT managers respond to ensure the success of their disaster recovery and business continuity plans?
In a recent blog post we wrote, “our 24/7, just-in-time, next-day-delivery, rising-expectations world, organisational tolerance for downtime is constantly shrinking. This means Return Point Objectives (RPO)s and Recovery Time Objectives (RTO)s are shrinking commensurately – placing ever-greater pressure on both disaster recovery and business continuity planners and operational leaders.”
We promised then to look at how to respond to this challenge and ensure the success of your disaster recovery and business continuity plans. This blog outlines key ways to do this.
This is Grant McGregor’s list of eight factors that will make a decisive factor in the success of your business continuity and disaster recovery plans.
This is the single most important factor when it comes to creating (and implementing) business continuity and disaster recovery plans.
The business must take a lead in defining what it would take to keep the business operational in the event of a disaster. However, as we’ve noted elsewhere, given the increasing dependence of many businesses on IT, much of the disaster recovery planning will fall to the IT department.
Clear communication between the business and IT is, therefore, essential.
The business needs to be realistic about what it would take to resume operations following a worst-case scenario.
This can be a daunting task; there is much to consider. If you haven’t attempted this kind of planning before, we recommend seeking expert help.
Return Time Objective (RTO) and Recovery Point Objective (RPO) are both terms that come from IT.
• Return Time Objective is the measurement of how long it takes to get things up and running again from the point disaster recovery is invoked.
• Recovery Point Objective is the measurement of how far back you are prepared to lose data.
While these terms have their roots in the disaster recovery processes for IT systems, it can be helpful to think about all elements of your business continuity planning in these terms (e.g. the people, premises, phone lines and physical assets as well as the IT systems).
The important thing to note is there isn’t going to be a single RTO and a single RPO for the whole business. Each system is likely to have its own measurements. For example, while your online shopping system might require a RPO of seconds, some of your back office processes might stand a much longer RPO.
Setting realistic RTOs and RPOs will require some hard talking between IT and the business: “If we lost x hours of trading data, how much would it cost us? And y hours? And z hours?” and “If we were out of action for x hours what would it mean? Or y days?”
The success of this process will depend on combining a clear overview of business processes with a good understanding of system architecture and how decisions about one system could affect another.
Close collaboration is as important during the implementation of your BCDR plans as it is in the planning stage. Your plan therefore also needs to set out who is responsible for doing what and when: where are the decision points and who makes the call?
Few businesses can afford to have an entire fail-over office sitting in mothballs waiting for a full fail-over event. That means you will need to seek third parties that can support you in the case of a disaster.
To some extent, from a systems point of view cloud computing has made disaster recovery planning far simpler. Architecting a seamless multi-cloud solution where your VMs and instances are replicated across multiple clouds builds in a resilience which can answer some of the requirements of business continuity. However, high availability and resilience are not the same as disaster recovery or business continuity. They do not answer questions over RPOs in the case of (malicious) deletion or corruption of data.
Plus, of course, not all businesses are running all systems either in the cloud or in virtualised architectures.
Grant McGregor consultants can provide assistance with the specifying, or selection of an appropriate BCDR solution.
Unless you have tested everything together at once, you don’t have a BCDR plan. Only by testing the full fail-over scenario do you have any idea whether your plan works.
Make sure all involved parties are involved in the test process – your lines of responsibility need to be tested as much as anything else.
Systems, software, apps and platforms are added to the IT landscape on an almost daily basis. Staff turnover continues to increase. Business processes are evolving at a vast rate of knots; so what was your most important go-to-market channel yesterday might not be next month.
The speed of change organisations are grappling with makes it more important than every that you revisit your BCDR plans regularly.
As we’ve said before, if you haven’t tested your BCDR plan, it’s meaningless. It is probably unrealistic to test each time you update your plans.
However, until you test, you don’t know your plans are going to work.
Therefore, you need to develop a testing schedule that reflects the speed and scale of change and the risk you are, as an organisation, prepared to take.
Of course, there is another important step... It's not Step 9 or one step in the above sequence of 8... but it probably fit into all of the above steps.
What is it?
Make sure those involved in the plan are involved in, and understand the plan every step of the way. Make sure that other stakeholders, staff, customers are informed as appropriate and keep the communication clear and suitable. Especially when testing and adjusting the plan, ensure that changes or new expectations are set via good, clear communications.
And above all, don't over-complicate (or oversimplify) it all.
If you would like help drawing up BCDR plans, sourcing suitable BCDR solutions or testing your BCDR plan, Grant McGregor can help. Speak with one of our consultants by calling 0808 164 4142.