Disaster Recovery Plan Policies
The disaster recovery plan (DRP) consists of the policies and documentation needed for an organization to completely recover from some incident. The business impact analysis drives the requirements for the business continuity plan. The BCP drives the requirements for the disaster recovery plan. These include software, data, and hardware. The DRP essentially is more detailed than the BCP. The DRP must not only get essential systems online, but in fact get all systems back online.
Disaster recovery planning considers people, processes, and technology. In many cases, laws and regulations outline the requirements for a DRP. For healthcare organizations, the Health Insurance Portability and Accountability Act of 1996 (HIPAA) requires a DRP. In developing a DRP, it’s important to work with your organization’s legal department to ensure requirements are being met. As another example, the Occupational Safety and Health Administration (OSHA) requires organizations with 10 employees or more to have a DRP. The law is meant, in part, to protect employees’ health and safety during a disaster.
Disaster Declaration Policy
The disaster declaration policy outlines the process by which a BCP and/or DRP is activated. It’s not unusual to have an IT disruption event that is localized in the technology infrastructure.
If an event causes major business outages, the BCP would be activated. Localized technology outages often impact the business. They may not rise to the level of a disaster. Still, in those cases, the DRP portion of the BCP plan would be activated. A server may go down, or a critical file may be deleted. This can disable a vital application in a smaller organization. In a large organization, however, many of these events occur each month. They are considered routine and would not trigger a DRP.
NOTE
It’s important to note that technology outages occur often, not just when there’s a security breach. Often the recovery plan is created independent of the cause, and then integrated into the IRT process as appropriate.
The disaster declaration policy defines the roles and responsibilities for assessing and declaring a disaster. Once a DRP is activated, a number of processes and capabilities are launched. You can handle many of these activities, such as notification to staff, through automated systems. The activation of a DRP for a large, complex organization costs thousands of dollars. In this case, the decision about who can declare a disaster is tightly controlled. Once the plans are activated, you want the process to be as automatic as possible. It should be second nature for those involved.
Once a disaster is declared, it’s very hard to stop its early ramp-up stages. These might include notifying key leaders and staging recovery capability. The process for declaring the disaster is contained in the disaster declaration policy. The following is a sampling of activations the plan might also include:
- Emergency notification of personnel, stakeholders, and strategic vendors
- Alternative site activation
- Activation of the emergency control center
- Transport and housing arrangements
- Release of prepositioned assets
Many of these activities will overlap with BCP activities. The difference is that they focus on the recovery of the IT infrastructure, as opposed to business operations.
Assessment of the Disaster’s Severity and of Potential Downtime
Not all disasters are alike. There’s a difference between losing your entire data center to a flood and having a DOS attack that disables a few dozen servers. But both would activate a DRP.
Assessment of the severity occurs throughout the life of a disaster. It starts with the disaster declaration and is continually updated. You forward the information to the emergency control center. Here it’s included in the decision-making process. Performing this continued assessment of the potential downtime is important. It ensures the right resources are being allocated to the problem. Many critical business decisions during a disaster rely on the assessment of the problem’s severity. A small sampling includes:
- Allocation of resources
- Notification to customers
- Assessment of financial losses and costs
Allocation of resources gets the right people to focus on the right problem. Consider a major outage of a vital vendor application. Your IT team estimates the outage at an hour or so. Then you reassess and estimate the potential downtime to be several days. The leadership in the emergency control center may be more patient in the first case. In the second case, the leadership may be on the phone with the vendor and begin flying in additional resources.
Having realistic estimates of downtime is important for customer relations. Overly optimistic recovery estimates often lead to loss of credibility. Suppose air travelers are told they face a flight delay of 20 minutes, but then their plane doesn’t leave until 3 hours later. This can cause a big public relations problem when it occurs repeatedly. The best professional judgment on potential downtime is expected in a DRP. Unrealistic estimates can overcomplicate and undermine the recovery process. It’s important to keep a complete history and basis for the estimates throughout the recovery process. You can use this information in postdisaster assessments to improve your process.
Assessments during a disaster are needed to determine financial losses and costs. An extended outage may require the infusion of capital to sustain an organization throughout the disaster. The amount of capital required will depend on the duration of the outage. Accurately estimating potential downtime is important to controlling those costs. It’s important to remember this is not just about a security breach or event. Equally, you need to look at a security event as a business disruption. Business relies on an end-to-end process working. From a technology perspective this means that the system, application, and data must all be in place and working. If any one of these components is not recovered or is out of alignment, the process fails. Disaster recovery policies define what to back up, and how often, and how to recover data in case of a disaster. The DRP must align well with the BCP and the BIA.
There are unique requirements for backup and recovery for systems, applications, and data. Systems and applications are easier to recover in some ways. They change less frequently and often rely on software from vendors. Having multiple sources to recover systems and applications makes recovery easier.
The customization of systems and applications is a different story. These customization settings are commonly referred to as configuration. They must also be captured and available during a recovery. The configuration for operating systems and databases includes security controls. The DRP needs to ensure these controls are not disabled during a disaster. A subset of the DRP is a security plan that outlines how security controls will be monitored and maintained during a disaster. The plan may restrict access to key staff to improve performance and stability. Approval for access may have to go through the emergency control center. It may require CISO approval.
The key point is that security planning and execution during a disaster are important considerations when building a DRP. Recovery of mission-critical data can be more challenging than recovery of systems and applications. The value of data is often time dependent. Data backups taken at the point of the disaster are typically more valuable than data backups from the prior month. The BIA process and data classification effort identify the data that must be recovered.