Disaster Recovery | Avoiding the Pitfalls | Part 2 of 4
Updated: Jul 4
Three (3) Common Pitfalls with Disaster Recovery Plans. Plus, How to Avoid Them. Over the years, the Thomas Cyber team have seen businesses continuously make the same mistakes when planning for outages to their IT systems. To help you avoid these common pitfalls, we thought we’d share our top three observations.
Observation #1 — A Business Continuity Plan is not a Disaster Recovery Plan
The first error we often see businesses make, is confusing (or combining) Disaster Recovery Plans (DRPs) with Business Continuity Plans (BCPs) — but as the heading suggests, they are not the same. A DRP is a defined and documented plan that details how ICT capabilities will be restored following a disruptive event.
DRPs should be developed to support BCPs, as part of risk management initiatives.
According to the whole of Government ICT Disaster Recovery for Business Continuity Policy, a BCP is the holistic management process that identifies potential threats to an business and the impacts to operations those threats might cause. It also provides a framework for building organisational resilience, wherein the business can respond effectively to safeguarding the interests of its key stakeholders.
Information and Communication Technologies (ICT) Disaster Recovery (DR) is the ability to restore the ICT elements (people, process information and technology) of an organisation to support the continuity of its critical business functions within a predetermined time frame.
Disaster recovery includes the prevention, preparedness, response, and recovery from disruption and is supported by policies and procedures.
Observation #2 — What are the appropriate security metrics for your industry
When it comes to Disaster Recovery, one size does not fit all industries.
To ensure the most appropriate plan of action, businesses need to determine the Recovery Time Objective (RTO) and Recovery Point Objective (RPO) most appropriate to their service offering/s and stakeholder expectations.
The RPO is a metric used to determine how often data backups should run, and to evaluate what services and solutions match your business needs. The RPO is determined by understanding how much data loss your business can tolerate.
Determining your RPO is important because data is dynamic and constantly changing over time, while backups only capture data at a specific point in time. The length of time between each scheduled backup is known as the backup interval. The wider the interval, the higher the likelihood that your data will change during that time, and the more risk you take.
In the event of a data disaster, a higher backup frequency enables more recovery points to restore from and shrinks the interval between backups, so that data has a better chance of being captured. Your RPO defines the maximum allowable amount of lost data measured in time from a failure occurrence to the last valid backup.
Recovery Time Objective (RTO) is the longest agreed period in which an ICT system can be unavailable without it resulting in significant damage to a business, and the time that it takes for the system to go from loss to recovery. This time is essentially what is available for ICT practitioners to restore an ICT system following a disruption. Because the process involves restoring all IT operations, RTOs are often complicated.
Determining what RPO and RTO best suit your business can help your IT team prioritise which systems are brought back online first, to help minimise the impact of a system outage.
Observation # 3 — Vendors vs Your Business — who is responsible for Disaster Recovery?
Another challenge we come across is confusion over the role of third-party vendors in helping organisations to plan for and mitigate the impact of system failures through disaster recovery. Some vendor contracts/products claim to include broad stroke disaster recovery support and so businesses assume when a disaster occurs, the vendor will step in and “handle everything”.
Unfortunately, when push comes to shove, the actual support outlined in the contract is somewhat vague or lacking and/or not to the level needed to support efficient, effective, timely disaster recovery. This leaves the business to fend for themselves, right when support is needed most, and they aren’t adequately prepared.
It’s also vital to investigate whether the recovery service provider is really able to recover the systems according to your business’s risk appetite if needed — not all service providers are made equal!
Lastly, the role of governance in Disaster Recovery is often overlooked or underplayed which can impede disaster recovery efforts. Governance processes, policies and procedures are critical to getting systems back online as soon as possible, as they determine which activities are done, and when and how to recover the systems. This governance is typically the responsibility of the business and not third-party vendors.
Where to next?
We’ll be the first to admit that these 3 common errors most likely stem from their complexity. There is a lot of information to understand so -
If your business is mixing up Business Continuity Plans with their Disaster Recovery Plans, we can provide advice and guidance to ensure robust processes and procedures are put in place to reduce the impact of IT system outages.
If you’re not sure how to determine your business RPO and RTO, we can conduct thorough assessments to find a security solution tailored to meet your specific needs.
Our stakeholder engagement tools and skills will help you and your third-party vendors to clearly articulate and allocate roles and responsibilities to ensure effective, efficient restoration of your services in a disaster.
The cyber landscape is constantly evolving, and threats are becoming more common and more complex. We want your business prepared for the latest risks.