Case Studies

Why a disaster recovery plan is so much more than a ‘nice to have’

cristina-gottardi-462734-unsplash_1400x875_acf_cropped

Why a disaster recovery plan is so much more than a ‘nice to have’ 

Businesses are increasingly dependent on the real-time processing made possible by their IT and technology, and our reliance on the online world makes the permanent availability of IT systems even more important. Whilst we like to think that we’ve got everything in hand and that our systems are robust and reliable, businesses need to be prepared just in case the IT and technology systems supporting critical business functions decide not to play ball. Cue disaster recovery – a subset of business continuity focused on planning for the worst (how to continue with business as usual if your IT services fail). 

However secure we might think we are with our business set-up, no business is immune to disruptive events. The key is to know what to do when problems occur so that costly downtime and the negative effect on customers is minimised. 

So, what is disaster recovery? 

In a nutshell, disaster recovery means the policies and procedures companies have in place to enable the recovery or continued use of vital technology infrastructure and systems following a disruptive event. This event could be natural (e.g. a fire or flood) or man-made (e.g. ransomware attacks, infrastructure failure, failed change implementation and upgrades, etc.). One recent high-profile example of IT upgrades causing unforeseen problems is TSB. The bank has been struggling with major meltdown after the recent migration of some of the bank’s services to a new platform caused half of its online banking customers to be locked out of their accounts, and gave many customers access to other people’s accounts, including account numbers and sort codes. 

The planning and implementation of disaster recovery solutions is something we have a lot of experience of, and flooding seems to be a particular theme. Thankfully, the robust back-up procedures (a pre-prepared server for recovery purposes) we recommended to a client enabled us to get them back up and running just four hours after a major flood that damaged a whole rack of servers, including their exchange server. And we have had more than our own fair share of experience with flooding in our own Bristol offices, which has given us the opportunity to see how good we really are at dealing with a crisis (and, quite frankly, we impressed ourselves!).  

Developing a disaster recovery plan 

Whilst it’s tempting to think that it will never happen to us, and it’s not the most fun in the world developing a contingency plan for something we hope will never happen, we all know that clear thinking isn’t likely to reign when IT systems have failed, customers are calling in en masse to report problems, and the atmosphere is thick with stress and tension. Best practice (and plain logic, really) calls for the development of a disaster recovery plan before the worst has happened in order to: 

  • identify potential threats; 
  • outline the steps that will be taken to minimise risk; 
  • establish the procedures to occur after a disaster. 

Some key points to consider: 

  • It is fundamental to any disaster recovery plan to know whether you will bring disrupted services back online, or whether will you switch to a back-up system. What action will be taken, by whom, and when? It’s all too easy to spend hours or even days trying to fix the problem before making the decision to go to disaster recovery – which may take still longer to implement. Your DR plan should take into account how long it takes to bring DR online, and what the triggers are to put it things motion. 
  • Crucially, how will your disaster recovery plan be tested, and changes be made? It’s one thing producing a theoretical plan, but it’s impossible to know whether it is reasonable and fit-for-purpose unless it is regularly and thoroughly put through its paces. 
  • How will the disaster recovery plan be kept up-to-date, and who will have responsibility for this? The Dr plan should be updated every time there are changes to the infrastructure, and this should be built into the change management process. 
  • What are your key business functions, and which IT systems are these supported by? What are the risks to these business processes if the IT systems fail? 
  • Who are the key people with responsibility for implementing a disaster recovery plan and what training/documentation will they require in order to carry out their part in the disaster recovery process? 
  • When should a disaster recovery plan be triggered, and how and when should staff, customers, suppliers and stakeholders be informed? 
  • Which external suppliers/stakeholders would you need to contact in case of an IT outage? 
  • Where/how will staff work if the business premises become unusable? 

Taking swift and timely action is key, and the only way to ensure this during a crisis is to have a robust and well thought out disaster recovery plan to follow.  

We have developed processes for drilling into the critical services in your business, finding the single points of failure and calculating the time to recovery in different scenarios, and we have a well-defined template for building a DR Plan that will ensure that you and your staff know what to do and when in the event of disaster falling. Let us help … 

Check out our disaster recovery product 

Our Partners