Many use the terms Business Continuity, Disaster Recovery, and Incident Response interchangeably. However, each of these components of the Resilience Triad (see the previous post) serve different purposes, and understanding the role and interactions of each is essential to maintaining a robust information security program.
The next component of the Resilience Triad is Disaster Recovery, or DR, the process by which information technology systems are restored. It is often, and incorrectly, confused with Business Continuity (BC). DR supports BC by ensuring that systems and services are restored as directed by the BCP.
An unfortunate yet all-too-common situation is when an organization does not have a BCP. In that instance, Information Technology professionals are left to decide what systems are brought on line first. Some of this is necessary due to the dependencies of systems; for example, it makes little sense to restore a public web site hosted internally before bringing internet connectivity back online.
However, for any business to place the responsibility of risk management on the shoulders of Information Technology is irresponsible. Information Technology will likely make decisions based mostly on system dependency. Moreover, many in Information Technology are not Risk Management professionals. Yet, in conditions of outages, suddenly they are expected to take on that task, and associated liability. Unless such is in their job description and expectations are clearly communicated and managed, this can
present a significant gap for any organization, especially SMBs.
As noted before, DR actions should be informed by and follow the BCP. Other items of a well-constructed DR Plan (DRP) include:
· Up to date system administrator list
· Up to date contact list
· Up to date network documentation
· Up to date wiring documentation
· Up to date system documentation
There is an obvious commonality of these components. A DRP, possibly more so than any other Resilience Triad elements, is subject to changes over time by the dynamic nature of information technology. Therefore, the DRP should be reviewed regularly. Quarterly would not be too aggressive if the environment is rapidly changing.
DRPs should also be tested periodically. While this could be as a component of a BCP-TTX, since the latter is more about business processes and less technology, often DRPs are better served with independent testing. Additionally, as DRPs sometimes involve external entities (e.g., a bank coordinating with a core provider), scheduling can become challenging the more parties involved.
In our last post of this series we will look at Incident Response.
Photo by ThisisEngineering RAEng on Unsplash