Writing a Disaster Recovery Plan
Writing a Disaster Recovery Plan
Regardless of the industry; businesses rely on data and technology of some sort. Technology has one certainty; it’s likely to fail sooner or later. This is where a Disaster Recovery Plan is required.
A quick Google search shows various sources indicating that an IT outage could potentially cost a business anywhere between $7000 to $10000 per minute of downtime. With data being the life blood of any business; a disruption of that proportion is enough to not only cripple – but kill off a business if left unchecked.
IT outages happen to everyone
With the knowledge that IT outages will eventually happen; be it a natural disaster, hardware failure or man made (terrorist attack or sabotage). The outage may not even be caused directly; but via a service provider (just as emergency services in Australia recently found out when Telstra equipment was damaged preventing emergency calls to be received).
It’s down to a businesses responsibility on how it reacts to such an event. The process of preparation, defining the steps required to ensure business critical systems and processes are restored efficiently and effectively is known as disaster recovery planning (or DR planning).
The process of DR planning is not a simple one. It takes time, effort and vast knowledge of the entire business. It’s especially tough on small businesses where resourcing isn’t as handy. A DR plan is an insurance policy as such; which can be tough to figure out return on investment.
If you’re reading this; chances are you’ve already found the endlessness resources available online to help create a disaster recovery plan.
So what exactly is a Disaster Recovery Plan?
All this talk about disaster recovery planning and disaster recovery plans; and we haven’t even told you what a disaster recovery plan is.
A DR plan is a document of all the processes that were decided upon during disaster recovery planning. Placing everything in writing and formalising it as part of business on how to handle a disruption to IT services.
At the heart of any good DR plan are two key factors. These are the Recovery Point Objective (RPO) and the Recovery Time Objective (RTO). While it sounds complicated; it’s not really:
RPO: The maximum age a backup can be before it doesn’t meet business requirements. E.g. If a business isn’t able to afford to lose 24 hours of data; then the RPO is 24 hours.
RTO: The time that is acceptable between the disaster occurring to normal operations resuming.
Documenting your Disaster Recovery Plan
There are usually a lot of moving parts when it comes to restoring IT services. This means that even a SMB could have a very lengthy and complicated DR plan to document. Although there are common structures which can be used to help break the different pieces down. There are many different ways to structure the DR plan; however the following is a favorite of Test My Backups:
Introduction: Outlines the document objectives, scope (including IT services covered, with RPO and RTO for each one). Include document version tracking here as well.
Role & Responsibilities: For any plan to work successfully (particularly in a disaster); everyone involved needs to know:
What they’re to do.
What their focus is.
Include both internal and external stakeholders that are required to execute the DR plan, their contact details, and a detailed outline on what they need to do in the event of a disaster.
Disaster Response: Outline at which point the DR plan is to be executed; and what communication methods are to be used to notify internal employees (including management); and external parties such as customers.
Disaster Procedures: Detailed; step by step processes to restore affected IT services. This can be a temporary fix; the main aim is to restore services to a working order as quickly as possible.
Additional Information: Lists, forms and documents relevant to the disaster recovery plan. May include evacuation maps; alternate DR sites for staff to work from, etc.
Testing your DR plan
As with most policies; they’re looked at when they’re written then filed away until someone needs to refer to them. The same thing happens to disaster plans all the time. Testing regularly gives an opportunity for staff to practice without the stress and panic factor. It also gives a chance to revisit the document and make necessary changes. Businesses are always growing and changing. If the disaster processes don’t change along with the business – it’s no longer fit for purpose. This then causes confusion and panic during a live disaster; the last place you need these pressures to occur.
The important part of testing a disaster plan is to make it as close to a real disaster as possible. As a last thought; if relying on backups then testing their recovery capability should become a priority as well.
Need help with documenting your disaster recovery plan? Download our template for free.