It seems like everything within Information Technology (IT) requires some sort of Minimum Control Standards (MCS) to operate. Some organizations call them Minimum Control Requirements or maybe even Minimum Internal Control Standards. The point is to ask whether MCS should apply to Disaster Recovery, and if so, at what level?
For decades, organizations have tasked the DR Manager with putting together a plan and processes around restoring the data center in the event of a disaster. Most DR Managers have developed these plans and processes through the employment of common sense and previous experience performing recoveries or tests. To this day, little information exists on the internet around best practices for DR, valuable documentation on DR Plans, Technical Recovery Plans (TRPs) and the like. So, the question exists, is it beneficial to have a Minimum Control Standard document created within your organization so that you, as the DR Manager, meet some minimum standards?
So, where do MCS documents come from? There are a couple of places that I am aware of: from Corporate Risk Management, and from past practice within the DR Team. There are probably others, but these are the two that I will discuss today.
- MCS requirements from Risk Management
- Many organization’s Risk Management departments believe they understand what should be done in the event of a disaster. Maybe your data center has failover, hot-hot, hot-warm, or some other type of replication and recovery process in place. When Risk Management makes determinations about MCS, oftentimes you end up with controls that may or may not be easily achievable.
- The idea behind MCS is to have some standards in place that are minimums that must be achieved in either your plan, processes, testing, or other area of DR, to ensure that you are prepared in the event of a disaster. However, having a department within the organization (which may not understand Disaster Recovery) create these standards for you does not necessarily benefit the organization or the overall DR plan. Only if Risk Management is willing to work directly with the DR Manager does a valuable set of standards get created.
- MCS Requirements from DR Team
- The most valuable set of standards around Disaster Recovery will come directly from the DR Team. This is because they have the best understanding of the what, when, where, why, and how for restoring the data center, creating the plan and processes, performing testing, engaging the business and test plans, as well as many other topics. Therefore, I would always recommend that the initial framework for an MCS document come from the DR Manager and his/her team.
- This document should encompass easily attained standards. These are minimums, not the best-case scenario if they had unlimited resources available and could build their plan and processes around the best end-state. Any organization’s DR Team can have certain criterium that they would like to meet over the next month, year, 3 years, or 5 years. However, those are not Minimum Control Standards, and upper-level management needs to understand not only the difference, but what should go in to developing those controls.
Now, having two different places where MCS documents can come from does not necessitate every organization going out and creating MCS documents just to have them. As I mentioned earlier, nobody probably knows more about Disaster Recovery in the organization than the DR Manager and the DR Team. Therefore, a discussion should occur to determine if an MCS document needs to actually be created for your organization. An argument can be made for and against them. It may be too early in the life of DR within your organization to automatically jump to including MCS in your process.
So, think long and hard about MCS for DR. Discuss it with upper-level management, or take a stab at writing your own controls. From there, making sure that everyone is onboard with what you are trying to accomplish becomes vitally important. Nobody wants a rogue DR Manager. However, showing the initiative and coming up with some of these ideas and presenting them to management will not only look good for you, but will also help in bridging any gaps that exist between the DR Team and the rest of the organization.
