Disaster Recovery and Business Continuity Planning, are buzz words that can be seen and heard everywhere, and are on everyone’s to-do list, but as a practice these terms are commonly misunderstood.
There are a few areas that you should clearly define at the initial stages when thinking about your Information Technology and Services Disaster Recovery Plan (DRP). Firstly, set a scope for what your DRP will cover. There are a million “what-ifs” that could be explored but it’s wiser to plan for fire and flood before looking at what a Martian invasion could mean to your business.
Once the scope and severity of different scenarios are defined, you can prioritize systems based on factors such as what they will require for resources and your ability to survive with or without them during an interim period.
Finally, define how the restoration will happen and then simulate a given disaster scenario. This process will be on-going and permanent. As you add new systems, new locations, and new people you must continually test and refine your DRP. These components of planning will bridge into a larger Business Continuity Plan as your DRP matures and the scope of the plan develops.
In many organizations, the operations are automated and the business depends on technology to the point where IT services and operations are one and the same.
Typical initial planning on a Disaster Recovery Plan will focus solely on the redundancy of the server and network systems that the business currently uses. This planning is extremely important and should definitely be a high priority but this is not, in itself, a Disaster Recovery Plan.
A server failure or component malfunction in the IT environment is just one possible disaster. Having redundant servers, a backup device, and two Internet connections is little help when water rushes into the room that they are all stored in. This is where defining “disaster” begins. Flood, fire, theft (whether theft of physical IT components or theft of data), and electrical failure are common starting points and can serve as a mental exercise to understand what role IT plays in the business and what could potentially fail. When you define a recovery from a fire, it will mirror many potential scenarios where a disaster destroys your primary server location.
Once you’ve picked your list of disasters, you should try to assign a likelihood and severity to each. If your servers are running offsite at a location with fire suppression and secured access you might want to rate fire and theft as lower risk but if this same location has communications equipment in the basement, flood may be of a higher likelihood and severity. Verizon ran much of its fibre optic network in the basements of Manhattan towers and was severely impacted during Hurricane Sandy.
With a list of potential disasters, likelihoods and severities, you can start to look at prioritizing your varying IT services. Many businesses rely much more heavily on e-mail to function than they realize, and will want to make this a key recovery that is deliverable within hours of a disaster.
Being able to communicate with team members, vendors, and customers is even more critical during a disaster. This is a component that can be mitigated in advance by using services that route mail through offsite servers that can be accessed using a web browser when your primary e-mail server is offline. After e-mail is restored, it is likely you will want to look at what is required to restore your data and access to your primary business applications or your vital Enterprise Resource Planning (ERP) system.
Each firm will have unique requirements but it is much better to decide in advance which services are needed most. Having that debate in a chaotic environment after a disaster will not be effective at all.
Getting this far is a big step but the most important thing of all is to continually test and refine your Disaster Recovery Plan. A simple fire simulation will expose key weaknesses in your plan and will prepare your key DRP stakeholders for their role in any future recovery efforts. Organizations have realized some very basic but critical flaws during simulations; in some cases, the DRP was a digital Word document and was stored on a server that was destroyed, and in other cases all the cell phone numbers for recovery team members were stored on the mail server that went offline. It’s a lot easier to laugh at and to rectify these mistakes when you find them in the aftermath of a simulated fire and not the real thing.
For any operation that doesn’t yet have a DRP, this can all seem like a lot of work without any immediate pay off, but the most important step in any plan is to just get started. Talk to your IT team or service provider and plan even just a single disaster scenario and take action on some of the deliverables you discover. Offsite backups or failover Cloud services can be small expenses when compared to the risk of your business being offline for days or weeks.
If you need more information or have any questions, feel free to contact us at 780.466.6204, or [email protected].
Thanks to Darren Buma of KWB Chartered Accountants for providing much of this content.
