Share what you know with millions of people
Focus is the best place to turn what you know into remarkable content
0
Creating a disaster recovery plan
My company has requested that I lead our disaster recovery plan. I am prepared to take on the task, but I want to hear some insight from others who have completed the process. Are there any small technicalities that I should pay special attention too?
Events
- Dos and Don'ts of Small Business Marketing May 29 @ 11 am PT
- Lead Nurturing 202: The Next Generation May 31 @ 11 am PT
- The Tricks to Paid Media June 6 @ 11 am PT
- Display Advertising for Brand Awareness June 20 @ 11 am PT
Related Activity
10 Answers
I've spent much of my career designing critical incident response and recovery plans. Some of what people often overlook are major issues, as well as the minor ones. The list of detail items that are missed will fill way more space than is reasonable to try to cover here. Here are a few of the items that are too often overlooked or gauged poorly.
1. Evaluate the impact of a loss of access, people, service or the services your firm provides, not the cause for the disaster. Too many people look only at one causal event (e.g., fire, flood, internal water damage, etc.).
2. Evaluate the full scope of the event on the company, not on a single system. Consider integrated events, e.g., loss of facility access and data damage. Again, forget the cause, since a fire in the space a floor above yours might be as bad or worse as one in yours. Water damage, fire, and loss of access to the space doesn't much care where it started.
3. Include a combination of principles and specific actions. Too specific and the plan may not survive first contact with the enemy; too broad and few people will understand what their responsibilities are.
4. Include a media and public exposure analysis. If your data is breached, someone will want to know what you have to say about it. The person making those statements needs to be strong, polished, and prepared. As hard as it might be to sell, that is not always the CEO, President or Chairman.
5. Presume you will need to become operational in a disaster without assistance or funds from any insurance resource. Some events are not insured and others are sufficiently broad or of major impact that you cannot wait.
Ok, that's probably too many words already. If you want to contact me directly, I'll be glad to assist further.
David Mair
Any Plan has one thing in common, the undertainties, that sway you both ways while implementing that plan. Preferred approach is to have both Risk Analysis and Uncertainty Analysis before planning. Risk is Known, Uncertainty is Unknown or Ambiguous.
Trevor -
I work with all levels supporting DR. If this is an oversimplified answer I apologize - but it sounds like you may be starting from scratch here...
See link: http://en.wikipedia.org/wiki/Disaster_Recovery - this is a great place to wrap your head around the 50,000 foot view of what you may be headed over. If this is to general please let me know if there is anything that I can do to assist with general knowledge or resources.
Good luck and best regards,
Thom Duclos
Stephen,
I posted a small research piece on disaster avoidance and recovery on this site that you might want to take a look at.
pH
I think both Paul and David made some good commentary on this. Specifically, I would suggest you look at business continuity in the same exercise as disaster recovery. In essence you need your critical business components to be protected in one of the following ways:
1) Automatically resilient
2) Redundant
3) Backed-up and easily recoverable
4) Work-arounds
These concerns not only go for the systems side of the business since often the first things that come to mind are networks, servers, workstations, and circuits, but also you need to make sure that people and processes are planned for in the same ways.
Its not a small task and often one of the first things to be put on the back burner at least until that time that you have to suffer some type of disaster!
bp
I agree with Brian, take care of the critical items and have a plan for every situation. I recently met with a company who does telecom recovery (telecomrecovery.com). I have always focused on database backups, information storage, etc, but never what to do if the phones were down for an extended period of time...until I met these guys.
So, in short, find a way to keep the phones ringing, or route them to one that will ring, if that is a key component to your business.
One of the most consistent shortcomings of disaster recovery/business continuity efforts I've seen is testing. Too many such plans end up as untested shelfware, only to fail when a real disaster hits, because conditions have changed since the plan was created. Any good plan must include regular testing, and processes for documenting and addressing the results of those tests and how those results were translated into plan-improving actions.
Another issue is personnel -- specifically, how to "work around" key personnel becoming unavailable as a result of some disaster. The best disaster recovery/business continuity efforts I've seen go so far as to include space in or near the intended recovery site for people to eat and sleep, in case local roads and/or transportation options are compromised. Good luck with your efforts!
Having worked on such projects for a few enterprises in the Middle East region, I think I can help.
Technology specifics aside, you'll need to map out your IT services and inter-service dependencies first.
Once you have this ready, you'll then need to stick to desired Recovery Point and Time Objectives (also called RPOs and RTOs) for EACH service. Remember, RPO/RTO for one service needs to be aligned correctly with those it impacts - and those it is impacted by.
IT departments are perhaps the least qualified to assume RPO and RTO values for business critical IT services. It is therefore key that you get business units to sign off against each value, before you embark on your DR/BR planning.
Process + People - two key pillars of your DR plan. You'll need to account for Command Center type approach too, if you have services that are too complex for an automated, unmanaged 'fail over'
Give me a should if you wish to know more. I haven't covered the technology component of a typical DR plan in this note, but can help with this.
Regards,
Ravi
Having worked on such projects for a few enterprises in the Middle East region, I think I can help.
Technology specifics aside, you'll need to map out your IT services and inter-service dependencies first.
Once you have this ready, you'll then need to stick to desired Recovery Point and Time Objectives (also called RPOs and RTOs) for EACH service. Remember, RPO/RTO for one service needs to be aligned correctly with those it impacts - and those it is impacted by.
IT departments are perhaps the least qualified to assume RPO and RTO values for business critical IT services. It is therefore key that you get business units to sign off against each value, before you embark on your DR/BR planning.
Process + People - two key pillars of your DR plan. You'll need to account for Command Center type approach too, if you have services that are too complex for an automated, unmanaged 'fail over'
Give me a should if you wish to know more. I haven't covered the technology component of a typical DR plan in this note, but can help with this.
Regards,
Ravi
Having built DR sites and written articles on them I must say I agree with just about everything here. I think the most important aspect though that is always forgotten is location.
As David discussed there is so much more to DR than servers and hardware. It is important -- if in the position too -- influence proper impact on the entire organization.
One thing I proposed one time that got reviews for the company was to not put the DR site at one of their facilities. This was a difficult sale for them, but if you paint the black cloud I did in the pitch you'd have bought off on it too. This won't work for every company, and again, going back to what David talked about, its very very important to evaluate all the needs of your organization -- not just IT.
No matter what you have it either a) has to fail over with minimal intervention, or have a very detailed written fail over plan. You have to plan, as David said, for a leak on the floor above you, or the unthinkable.
Answer This Question