Alot of organizations are becoming data-led and this means a data governance policy is a hygiene factor. However, a strong DG policy should also include disaster recovery. A data governance policy with clear contingency plans and escalation matrices defined for crises, will provide early responders with all the information they need to move ahead. This blog explains the considerations that an organization needs to make to include disaster recovery as a part of the data governance policy.
Ask any organization these days what their long-term plans are, and the answer will inevitably be built around leveraging data, its collection, analysis and utilization. Is it any wonder then that most of the big names in the past few years have been mostly tech-centric, data-fed businesses?
But even as more and more organizations revamp their intelligence-gathering apparatus to become adept at collecting their customers’ information, there is also a growing awareness that this data needs to be protected. This protection is, in a manner of speaking, provided by creating robust, comprehensive data governance policies that not only aim to prevent failure but also have clear-cut recovery plans even in worst-case scenarios.
When does a system bug, or a glitch, become a disaster? Typically, the word ‘disaster’ conjures up images of smoking data centers and molten server slices, especially if you are part of the infrastructure team responsible for preventing such problems in the first place. But a disaster can just as easily be a simple – but catastrophic – matter of an intern dropping an entire column of values from a database table, or a data-format incompatibility that switches months and days in a timestamp field.
In addition to man-made causes (that might be deliberate or otherwise), disasters can also strike in the form of floods, earthquakes, utility failure, cables getting cut, electrical problems and fire. The bigger the organization, the bigger the budget to plan for all these eventualities – but sometimes, even that is not enough. Even with the most advanced of warnings, our species continues to underestimate nature from time to time and ends up paying the price. The answer, therefore, is simple – assume a maximum-possible factor of safety, and then assume that even that factor can be topped by nature.
In other words, irrespective of the safeguards you have built in to prevent a disaster from bringing down your infrastructure, your data governance policy must still have a disaster recovery (DR) component as well. After all, with data systems being so intimately connected to each other, a failure at one node might very quickly translate into a system-wide catastrophe.
For one, it means that you must have your contingency plans in place. As the old saying goes, “failing to plan is planning to fail.” It helps to integrate your contingency plans with your data governance policy so that there is only a single source of information for people to look into when things go wrong. The worst thing that can happen to any company when it’s fire-fighting is confusion.
Secondly, your disaster recovery (DR) plans must factor in the human element. Even the most automated systems for recovery, repair and restoration need human eyes overseeing the process, if only to ensure that everything is working as it should. If you’ve drafted your policy with clear escalation matrices defined for crises, it will provide early responders to each situation all the information they need to move ahead.
Third, your data governance policy – and specifically your disaster recovery plan – must provide for communication guidelines that are necessary at such times. You can set up mailing lists and templates depending on the source and the severity of the issue. Be proactive in informing your stakeholders, especially when they are paying customers, about outages and estimates on time needed to resolve them (ETR). A template where only fields such as cause, status and ETR need to be plugged in can head off a secondary disaster such as an employee revealing too much or too little to outraged clients.
Along with all these, you must have clear benchmarks for what constitutes a successful recovery state. Your definitions for these must be tied into the broader objectives of your data governance policy, including its use and dissemination. For instance, even if you’ve just recovered from a drastic denial of service (DDoS) attack, your next step must be to ensure that your normal runtime safeguards are back in place to prevent unauthorized access to your data as defined in your data governance policy.
Finally, you will need to spell out how to call an operational closure on your data recovery process. Right from defining the wait-and-watch period to the organizational sign-off that the disaster has passed, it helps to have a checklist that the incident manager can use. After all, while you may need to bring in additional resources and give them access to specific areas of your data infrastructure during the disaster recovery process, you will need to roll back such privileges the moment they are no longer necessary.
With data becoming a key differentiator in the marketplace, data governance is rapidly becoming part of the identity and foundation of companies all over the world. But a proper data governance policy is much more than just a set of rules and regulations.