GRC Tuesdays: Integrating Business Continuity Management (BCM) within Your Governance, Risk, and Compliance Process
Despite what many still believe, business continuity is not just about creating a recovery plan for IT resources in case there is an outage. Of course, this is a part of it, but business continuity is really about having a plan (including processes and resources) for the organization to face critical situations and still continue to function—even if in degraded mode—and limit as much as possible the disruptions.
In this sense, it’s very close to risk management where the intent is to document, analyse, and respond to uncertainties.
So Why Have the Two Processes Been Growing Apart for So Long?
Unfortunately, I don’t have a complete answer to that, but I will still share my feeling and what I have learned from various interactions with stakeholders from both worlds (yes, in many cases they are still worlds apart):
- Business continuity is owned by IT and only focuses on IT disruptions. Remember when cybersecurity was only perceived as an IT issue? Well, in many organizations this is still the case for BCM.
- Business continuity is owned by environmental, health and safety (EH&S). Many organizations manage their environment, health, and safety risks in silo. Since one of the most important resources for an organization are humans, some organizations have assigned the continuity topic to their EH&S team.
It’s Not a Fatality—Others Are Integrating BCM and GRC
Don’t get me wrong here—IT and humans are critical assets for the good functioning of an organization. In today’s world, no organization could produce and deliver its goods and services without these two resources, but they aren’t the only dependencies companies should consider when documenting their continuity plans.
A Simple Three-Step Plan
1.Reuse Your Process Documentation
- If the processes have been documented by internal control and audit management, aren’t they worth leveraging? There is still a perception that control and audit focus exclusively on financial reporting but this is simply not true. Both have one intent in mind: help the company perform better—for all processes.
- As a result, BCM could (and should) reuse the processes documented by these teams even if just to ensure that they cover the processes identified as the most important.
2.Leverage Your Risk Register
- Risks are everywhere… including in so many registers sometimes… But for companies that have an enterprise risk management framework, the central risk register is the single source of truth. Instead of creating its own subset, BCM should really leverage the risk register to ensure that the most critical risks identified are covered with an appropriate plan.
- Doing so will automatically help the risk owner reduce the impact of a risk should it manifest. Collaboration between business continuity teams and operational teams therefore becomes a no brainer!
3.Use the Incidents—and Near Misses—for Feedback
- Continuous improvement for risk mitigation is of utmost importance. Nothing could be worse for an organization than to have a set of risk responses (actions plans, controls, policies… continuity plans!) associated to a risk that are being ineffective because they’re obsolete.
- It’s invaluable for the risk owners to be able to review the incidents that have triggered a continuity plan and learn from what was done in reaction. Indeed, the documentation of the real-life incident should include all the triggers—not just the first ones, but also as the incident developed. Hence, this goes further than a simple root case analysis that is more of a theoretical exercise.
- As a result, the risk owner could add more potential drivers to his risk and design an all-encompassing mitigation strategy that should prevent the risk from turning into a crisis or at least mitigate it more rapidly in the future.
What about you? Has your company already integrated the two processes of BCM and GRC together? If so, feel free to share your feedback either on this blog or via Twitter @TFrenehard
I challenge you on your assertion that IT owns Business Continuity. IT owns Disaster Recovery. The business as a whole owns BC. DR is specific to assets and services whereas BC is on processes/procedures and operations.
First of all, thank you for your reply.
In theory, I would agree with you: the business should own business continuity management.
Unfortunately, in many organizations that I have come across, business continuity management is actually still limited to its IT disaster recovery planning portion.
As a result, and only due to this bias, IT often owns the topic within the organization and no overall BCM strategy is therefore deployed.
For organizations that take a more holistic approach, then yes, the business itself (hopefully) owns the topic. This also means that the business continuity plan integrates all aspects of the topic, and not just the IT part and is therefore much more effective when a crisis occurs that is not limited to an IT outage.
As you will be able to read in the blog, I am definitely not proposing that IT should own the topic. I am simply sharing my experience and trying to offer suggestions as to how companies can leverage their governance, risk and compliance efforts and build a more sustainable business continuity practice.
I hope this clarifies.
we are currently implementing the Risk Control for our Risk Management (OpRisk)in SAP GRC and planning to go forward with other content (compliance, audit) aswell.
For BCM currently another Platform is used.
I agree that there is an overlap between Risk Management and BCM, but as Risk.M. is focussing very much on the evaluation and controls, BCM is covering the documentation of the actions to be taken and includes a URP (Unit Recovery Plan) - which is a lot of data. Is there any smart way to migrate and merge? Some practical experience?
Thanks for sharing,