Unfortunately in today’s modern threat landscape, it’s only a matter of time before your business faces a disaster. How would your organization cope if an employee deleted a production database? Could you continue to serve customers if a tornado took out your primary data center? How soon could you recover data encrypted in a ransomware attack or return to normal operations during a denial-of-service attack? Disaster recovery planning ensures your business has answers to these questions and more.
We covered disaster recovery planning basics in What is a Disaster Recovery Plan (DRP)? In this article, we’ll explore the disaster recovery planning process and the steps you need to take to build a robust DRP that protects your business’s infrastructure from real-world threats.
Why Do You Need a Disaster Recovery Plan?
Disaster recovery planning lays the groundwork to help your business bounce back when things go wrong. It’s only a matter of time before an adverse event threatens to disrupt business operations. A DRP may make the difference between a quick recovery with minimal losses and a catastrophe costing your business thousands or even millions of dollars. It’s not unusual for companies to go out of business after a large data loss or severe service disruption—a realistic and practical disaster recovery plan might have saved them.
Other benefits of disaster recovery planning include the following:
- Preventing the loss of customers to competitors. Consumers have little patience for extended downtimes, especially for online services. It doesn’t take long for previously loyal customers to seek alternative vendors, and once they’ve found a suitable replacement, they are unlikely to return.
- Limiting reputation damage. People remember large-scale data losses and service disruption. They introduce a degree of doubt that can dissuade potential customers from adopting your services for many years.
- Enhancing compliance. Disaster recovery planning is part of many security standards and regulations, including HIPAA, SOC 2, and ISO 27001.
- Improving infrastructure transparency. Disaster recovery planning forces businesses to catalog their infrastructure and the services it hosts. This is a useful exercise: many security vulnerabilities result from improperly monitored and secured infrastructure.
Identify Critical Infrastructure and Services
An organization must comprehensively understand its infrastructure and the services it supports before designing disaster recovery processes. An infrastructure inventory is often one of the most time-consuming aspects of disaster recovery planning, but it is necessary. You can’t build redundancies, failovers, and risk mitigation systems unless you have a clear and comprehensive accounting of what you’re protecting.
It’s not unusual for businesses to build a disaster recovery plan that ignores essential pieces of the puzzle: for example, an old server running scripts that no one has looked at for years but which turn out to play a critical role in keeping services up and running . A complete infrastructure inventory mapping essential services will help you to build robust disaster recovery processes.
Conduct a Risk Assessment
A risk assessment documents and prioritizes risks to a business’s operations. Simply put, risk is the likelihood of something bad happening. Risk has two components: adverse events and their probability. A risk assessment identifies adverse events that could disrupt operations and considers how likely they are. For example, businesses have a high likelihood of disruption due to ransomware attacks, so mitigation and disaster efforts should be prioritized.
Conducting a systematic risk assessment is often challenging for businesses, especially when they lack the expertise to identify risks and the probability of an adverse impact. A risk assessment’s utility may be affected by ‘unknown unknowns,’ factors you cannot account for without expertise and experience in the relevant field. It may be beneficial to hire a third party that specializes in systematic risk assessments.
Determine Disaster Recovery Objectives
The next step is to prioritize systems and determine your disaster recovery objectives. Objectives are usually expressed as Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO). RTO is how quickly you would like systems to be back online in the event of a failure. To put it another way, how much downtime is acceptable? RPO expresses how up-to-date you expect recovered data to be. For example, are you comfortable losing a couple of hours of data, or do you need guarantees that there will be as little data loss as possible?
Your RPO and RTO decisions impact disaster recovery systems’ design, implementation, and cost. Typically, critical systems will be given low RTO and RPO times. They should be recovered as quickly as possible with the least data loss. You might choose to deploy redundant infrastructure with automatic failovers and continuous backups for these systems. Higher RTO and RPO values are acceptable for less critical systems—you may be content to leave low-priority systems offline for several hours with daily or even weekly data backups.
Create Written Policies and Documentation
At this point, you understand your IT infrastructure’s risks, how to prioritize disaster recovery planning, and your disaster recovery objectives. The next step is to create disaster recovery policies to achieve those objectives. From those policies flow specific processes and procedures. These should be comprehensively documented as documentation is critical to effective disaster recovery. Managers and employees must understand what is expected of them and the available resources.
At a minimum, your disaster recovery plan documentation should include the following:
- Procedures for recovering and restoring systems
- Inventories of disaster recovery infrastructure and services
- Schedules that order procedures according to the importance of each system
- Lists of responsible employees: who takes charge of disaster recovery, is accountable for implementing DR procedures, is tasked with customer and partner liaison, and so on. Documentation should include contact details for all responsible individuals.
Test, Revise, and Adapt
Once your disaster recovery plan is in place, it should be tested to make sure it survives within the real world. A plan is a great starting point, but it’s far better to discover a shortcoming during testing than a serious incident. Run simulations, test DR infrastructure, and enact disaster recovery drills with employees. During testing, you will discover opportunities for improvement, which should feed back into your policies, procedures, and documentation.
Regularly Update Your Disaster Recovery Plan
Your company’s IT infrastructure and processes evolve, and your disaster recovery plan should evolve with them. DR planning is not a “once and you’re done” event. Businesses must iterate on their plan continuously, ensuring that policies and documentation reflect current systems and priorities. It would be unfortunate if, when disaster strikes, employees turn to their DR plan only to find that it’s years out of date and inapplicable to the current scenario.
Does Your Disaster Recovery Plan Comply With Information Security Regulations?
We mentioned earlier that information security regulations and standards often require disaster recovery planning. But there is another aspect of compliance to consider. Your business’s DR infrastructure and processes must also be compliant. They must have the same security, confidentiality, privacy, and data protection controls as your primary infrastructure.
KirkpatrickPrice offers a wide variety of information security testing and auditing services that help businesses to maintain compliant disaster recovery plans, including audits for:
To learn more, contact a KirkpatrickPrice information security specialist today.