Components of a disaster recovery plan (DRP)
1. Components of a disaster recovery plan (DRP)
Organizations often create disaster preparedness plans. By planning in advance, organizations can better navigate challenges and unexpected events. Security professionals also plan for unexpected events. In this video, we’ll explore Disaster Recovery Planning, also known as DRP. When all else fails, a well-constructed DRP ensures that business operations can continue. It’s the survival kit that keeps an organization going during unexpected disruptions. Let’s unpack the kit, and explore each of the four key components of a Disaster Recovery Plan. The first component of a DRP is roles and responsibilities. Having an established list of roles and responsibilities ensures your team knows how to communicate and collaborate with other employees, vendors, and customers. The second component of a Disaster Recovery Plan is critical systems, applications, data, and resources. The DRP should include documentation of which systems, applications, data, and other resources are most critical for business continuity, and how to bring them back online when they’re down. The third DRP component is to make plans for testing and optimization. It’s important that your team continues to test and update its strategy to address ever-evolving threats and business needs. The fourth DRP component is a risk assessment. A risk assessment considers strategies for potential hazards and the necessary resources to resume business operations. The assessment should include clearly defined recovery point objectives and recovery time objectives. Remember, a recovery point objective, or RPO, is the point in time to which data must be recovered after a disruption occurs. For example, imagine you’re working on a crucial project that depends on a constant stream of live data. Suddenly, without warning, your system crashes. The clock is ticking, and each passing second means more data is lost. How much data can be lost before it starts to impact the company? Thirty seconds worth of data, thirty minutes, or 3 hours? These are the questions RPOs are meant to answer. A recovery time objective, or RTO, is the maximum acceptable amount of time allowed for the recovery of a service in the event of a disaster. When setting an RTO, security professionals need to know the maximum amount of time a system can be offline. To figure out the answer, they’ll ask questions like, How long can business operations dependent on a specific system be down? And how quickly does the system need to be operational before the impact becomes severe? For example, imagine you work for a global financial technology company that provides financial services through a cloud-based app. Their services are accessible to millions of customers around the world at any time of day. One day, the company is targeted for a distributed denial of service attack. The attack overwhelms the company’s servers and systems, causing the app to go offline. The outage causes severe service disruptions, impacting customers all over the world in an instant. Unfortunately, your team’s efforts to mitigate and resolve the attack are not successful. Your defenses are overwhelmed, the system stays down, and the app remains unreachable. Your last line of defense is the disaster recovery plan. So the team activates the cloud-hosted DRP, which outlines the steps the team needs to follow to recover critical cloud resources. Your team’s designated personnel, including security engineers and stakeholders, access the DRP. Now, everyone on the team knows their roles and responsibilities, and collaborates effectively to get servers and systems back online. By leveraging the scalability and distribution of the cloud, your team is able to redirect and recreate network traffic, computing, and data from failovers and backups. All of the redirection and restoration efforts are then guided by predefined RTOs and RPOs, ensuring that downtime and data loss are within acceptable limits. Critical systems then come back online, and the bank’s customers are able to access the app once again. As you might imagine, this recovery process is not an every day action. It’s the safety net when everything else fails. Now that you’ve explored the components of a Disaster Recovery Plan and worked through a security scenario, you understand the process to support recovery when the unexpected happens.2. Let's practice!
Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.