Disaster Recovery Planning
1
Disaster Recovery Planning
2
Overview
• What is a Disaster Recovery Plan (DRP)
• 7 steps for a DRP
• Top 10 best practices for creating and implementing a DRP in 2021
3
Disaster Recovery Planning - Definition
Disaster recovery planning is defined as the process of creating a comprehensive plan
that helps your organization resume work after the loss of data or IT equipment due to
natural or human-made disasters. A good disaster recovery plan will make sure that
this is done with minimal business disruption. (Ramya Mohanakrishnan, 2021)
4
Importance of having a stable DRP
a) Disaster management
No business can run successfully without substantial tech-based infrastructure. To put
things in perspective, a 2018 BCI Survey Report says that the top supply chain disruptors
are IT outages, cyberattacks, and transport network disruption, which are caused by
natural or human-made disasters such as hurricanes, floods, wildfires, cyberattacks,
power outages, and even acts of terrorism.
5
Importance of having a stable DRP contd…
b) Cost of disruption
According to Dell’s 2021 GDPI snapshot, cyberattacks and disruptive events are rising
meteorically. 82% of the organizations reported an unplanned disruption in the last one
year, a number which was only 76% in 2018. In fact, these disruptions cost an estimated
total of $810,018 — up from $526,845 the previous year. Hefty figures aside, business
continuity is also a matter of reputation and trust for customers and stakeholders.
6
Statistics – Consequences for lack of a DRP
• 80 % of businesses without a recovery plan either closed or never reopened within 18
months
• 70% of companies go out of business after a major data loss
• 80% of companies without a BCP fail within 2 years
• 60% of companies that lose their data shut down within 6 months of a disaster
• Source : Continuity Central,
[Link]
7
Should you hire a DRP consultant?
You may want to hire an outside consultant who is an expert at disaster recovery
planning and performing a Business Impact Analysis.
Hiring an outside consultant for this type of work has its pros and cons.
The pros include that the consultant is
• An expert at DR planning
• An expert at creating Business Impact
• Analyses
• Objective
Consultants do have their downside:
• They’re not familiar with your business
• They have few, if any, relationships with staff
• Their services are costly
You need to weigh these factors and decide how much you want a consultant to do for
you. You can have him / her give you a little up-front advice, or you can let him or her
manage the entire process. 8
7 key steps for developing a DRP
According to Sneadaker (2007) the steps required to build a robust DRP are:
1. Project initiation
2. Risk assessment
3. Business Impact Analysis (BIA)
4. Mitigation strategy development
5. DR plan development
6. Training, testing, auditing
7. DRP maintenance
Each of these steps is discussed in below.
9
7 key steps for developing a DRP
According to Sneadaker (2007) the steps required to build a robust DRP are:
10
1. Project initiation
• Project initiation is one of the most important elements in BC/DR planning, because
without full organizational support, the plan will be incomplete.
• As an IT professional, there may be limits to what you can do to create an organization
wide functional DR plan.
• For example, you may know how to set permissions for a particular business
application, but you may not really know how users interact with it and what would be
required to get the business back up and running with regard to that particular business
function?
• If the application server is destroyed and you have data backups, do you also have a
backup server?
• You will not likely be able to answer these questions. It requires the input and
assessment
• from subject matter experts in other departments and divisions.
• Therefore, getting executive and companywide support for the BC/DR planning process
is absolutely key to its success.
11
2. Risk assessment
Risk assessment is the process of identifying the potential risks your company faces.
These risks run from ordinary to extraordinary—from a fire or minor flood in a server
room to a catastrophic loss such as an earthquake or major hurricane and everything in
between.
Again, as an IT professional, you can certainly lend your expertise to this process by
helping define the likely impact to technology components in various types of disasters or
events, but you can’t do it alone.
For example:
Your marketing manager might best understand the potential business risk of a
contaminated product or a Web site breach.
Hence a risk assessment is performed by representatives from all the functional areas /
departments of an organization.
12
3. Business Impact Analysis (BIA)
• Once you’ve delineated your risks, you need to turn your attention to the potential
impact of these various risks.
• BIA outlines the impact on business of each of the identified risks.
Example - If the web server of an online merchant is down, what is the impact on
business?
• This is one area that, as an IT professional, you clearly need input from your
company’s experts.
• As mentioned (under risk assessment) earlier, you might understand the technical
aspects of an application server going down, but what is the actual business impact,
and can that be tolerated?
For example, you might determine that your ERP application cannot be down. Period.
E-mail and your Web server, however, can go down, even though both events would be
disruptive. However, you may not know the impact on business of the ERP being down.
13
4. Mitigation strategy development
• It refers to identifying strategies to recover from disaster.
• For each identified risk that has a significant business impact, you need to
look at your options.
• How can the risk and impact be tolerated, reduced, avoided, or transferred?
14
5. Plan development
• Next is plan development.
• As with other types of IT project plans, you’ll outline the methodology
used so that you improve your chance of success and reduce your
chances for errors and gaps.
• This includes standard processes like developing business and technical
requirements, defining scope, budget, timeline, and quality metrics,
and so forth.
• Standard IT Project Management methodologies can be used to create
a solid plan, regardless of the size of your company.
15
6. Training, Testing and Auditing
• Once the plan has been developed, people need to be trained on how to
implement it.
• Running through appropriate drills, exercises and simulations can be of great
help, especially for disasters or events that rank high on the list of “likely to
occur.”
16
7. Plan maintenance
• Without a plan to maintain your plan, your DRP will become just another
project document on a file server or sitting in a binder on a shelf.
• If it is not maintained, updated, and revalidated from time to time, the DR plan
may be rendered useless if a disaster does occurs.
• Maintenance doesn’t have to be an enormous task, but it is one that must be
done.
• Most importantly, there must be an organizational commitment to do so and
someone within the company to own it.
17
10 best practices to create and implement a DRP
1. Focus on assets and vulnerabilities rather than the disaster
2. Keep iterating the process
3. Maintain a readily accessible disaster recovery playbook
4. Do not forget the process
5. Have a testing schedule and stick to it.
6. Create comprehensive post-test reports
7. Keep up employee awareness, training and drills
8. Supplement your DRP with security and data protection solutions
9. Protect the everyday software
10. Ensure good reporting
18
1. Focus on assets and vulnerabilities rather than the disaster
• Picking particular disasters and focusing only on risks associated with
them can draw attention away from other threats.
• A better approach would be to identify core assets and services and
then working up to the associated vulnerabilities.
19
2. Keep iterating the process
• Disaster recovery planning is not a one-time process.
• Business requirements keep changing, new infrastructure is added every day
and industry regulations are updated all the time.
• This means that the DRP also needs to keep changing. It is best to have
scheduled sessions, ideally three to four times a year. It can also be based on
certain milestones or triggers — like adding a new service or making major
changes in an existing one.
• A good DRP grows with the business.
20
3. Maintain a readily accessible disaster recovery playbook
• A Disaster recovery playbook is meant for multiple stakeholders at different business
levels and professions.
• It must be written in a clear and concise language understood by all.
• Once a playbook has been approved and tested, a hard copy must be placed in a
readily accessible area, while a soft copy is loaded onto the cloud or a portable
medium.
• A DRP must also be easily modifiable since it is subject to change with every
iteration.
• Any changes made in the plan must be reflected in all storage and communicated to
all stakeholders and team members.
21
4. Do not forget the process
• DRP is not just about the hardware and the software.
• There are people and processes involved in each step too.
• It is important to make sure that the recovery team has a backup work location to
operate from.
• If employees are logging in from home, do they have secure access points to reach
your systems?
• Remember to include these work-process solutions in the playbook.
22
5. Have a testing schedule and stick to it
• A disaster recovery plan is only as good as its testing schedule.
• A 2014 Global Benchmark Study showed that poor planning, testing, and
technological deficiencies led to more than a $5 million loss by critical application
failure, data center outages, and data loss.
• An untested plan leads to a false sense of security.
• Usually, DRP tests are scheduled three to four times a year, though some bigger
enterprises with complex systems carry them out monthly.
23
6. Create comprehensive post-test reports
A testing activity must always result in a comprehensive report detailing the following
points:
• The type of tests carried out
• Frequency of testing
• Success Factors — predetermined details that help evaluate the testing. A successful
test isn’t just one that comes up error-free. A successful test is also one that catches
an error that might have made it to the final cut.
• Test procedures followed
• Post-test analytics
24
7. Keep up employee awareness, training and drills
• All concerned people must always be kept in the loop and DRP drills
need to become part of the company culture, just like fire drills.
• Training must be frequent and contact information updated.
25
8. Supplement your DRP with security and data protection solutions
• Replicating a whole new secondary setup means replicating security concerns
as well.
• Any cyberattacks or ransomware demands must be curtailed within the
primary system and cannot permeate the WAN while duplicating data for
backup.
26
9. Protect the everyday software
• Any SaaS applications used, like MS Office or Salesforce, need to be considered
in the inventory logging stage.
• While they might not directly be involved with the company’s services, losing
contact information with potential clients might have a long term effect.
• Even email suites come into play here because the loss of important
communication can be a major business impediment.
27
10. Ensure good reporting
• On-ground reporting is just as, if not more, important than test reports.
• When a disaster actually strikes, and the DRP is set in motion, provisions must be
made for documenting each step.
• It is the best way to figure out what works best and what needs tweaking.
• With the number of natural and human-made threats increasing daily, creating,
adopting, and maintaining a well-thought-out disaster recovery plan makes good
business sense.
• A good DRP goes a long way in creating a confident and resilient business.
28
Disaster recovery software
Disaster Recovery Software: An application program developed to assist an
organization in writing a comprehensive disaster recovery plan.
Examples open source:
PhotoRec (Windows, Mac & Linux)
FreeRecover (Windows)
Kickass Undelete (Windows)
Recuva (Windows)
29
Summary
Disaster recovery plans are implemented in the immediate aftermath of a business
disruption.
Business continuity activities usually begin after the immediate impact of the
disruption, event, or disaster has been addressed.
Note
1. It should be clear, then, that business continuity and disaster recovery (BC/DR) are
two distinct plans that intersect.
2. Each can be planned as a separate project using standard project management (PM)
methodologies, or they can be planned as one larger, integrated plan.
30
Summary
• Companies need to plan for potential disasters that will impact their ability to continue
operations and earn income.
• Without a plan to recover from any disaster or event, no matter how large or small,
many companies fail.
• Using standard project management methodologies will help you throughout the
DR plan development process. It will help reduce errors and avoid potential gaps in your
planning activities.
• The basic steps of BC/DR planning are project initiation, risk assessment, business
impact analysis; mitigation strategy development; plan development; testing, training
and auditing; and plan maintenance.
31