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