The disciplines are the same, but different-ish and as you can see, there is overlap between them. It's easy to see why many ERM folks insist BC practitioners play in their sandbox.
Where things break down for folks on the BC side of the DMZ however, is in the lack of fine detail that we require to build a response to a threat. What I mean is that while ERM folks may consider "Weather Events" as a risk category in their registers, they take a macro view of how it will affect the organizations insurance policies and financial position. A BC practitioner, typically along with business unit champions and subject matter experts, will break that threat down into little pieces and ask tougher questions, such as:
BC practitioners must address threats on a much more granular basis. To ensure that things continue with business as mostly usual and forward momentum of business unit processes, along with their up & downstream dependencies, we use the data from our operational risk assessment and from the Business Impact Analysis (BIA) to ensure accuracy. The BIA identifies all processes that could be affected by said weather events and we can then determine how the threats to those processes are best treated. i.e. By building resumption plans that shift resources to alternate internal or external locations, changing how a process is structured so that the threat is removed, transferring the risk of the threat to another entity, or in some cases, accepting the risk the threat presents. This is probably the best opportunity to most effectively collaborate with ERM teams as they can bring their perspective to the threats the BC practitioner is seeking to mitigate.
Now before you start, I've heard the arguments from ERM folks that their processes take all these things into account and I'm not saying they don't, in their own way. To paraphrase my very intelligent and experienced friend Bethany, "ERM gives you the satellite view of your organizational risks on a map. BC takes you down to street level and shows you how to navigate those risks."
There are several things that drive BC planning processes that don't necessarily line up with ERM processes. Let's consider the DRI Professional Practice #1, Program Initiation and Management, and some of the issues it identifies as drivers to build and maintain a BC program:
These are things that, from my experience, are not easily paired with the data driven from an ERM process and make program initiation much more difficult when trying to identify to senior leadership what needs to be done. As well, if we can't provide a detailed explanation or roadmap of the nuts and bolts of a proposed BC program, it's a much harder sell.
Using ERM risk data alone, without qualification of the likelihood of an occurrence and the deep dive into a threats impact that a BC risk assessment (RA) paired with a BIA delivers, would likely provide output from the BC planning process that is sub-standard in its effectiveness. To put it bluntly, your BC program will most likely be irreparably flawed and if you don't test it, you'll find out at the worst time possible.
At the end of the business day, let's agree that both disciplines have a significant impact on organizational resilience, should be given equal weight, and not subsumed by the other. Instead of dictating to a BC practitioner how they will perform their risk assessment or the data they will use, please stop and consider what they require to build comprehensive plans that keep the ship moving forward.
Stay tuned next time when I poke the Security & Protective Services folks in the eye with a pointy stick hahahaha .
Thanks to everyone who provided feedback/peer review for this article, muchly appreciated!
Garth is a DRI Certified Business Continuity Professional (CBCP), a member of the International Association of Emergency Managers (IAEM), an experienced Disaster Recovery, and Emergency Management planner. His career focus is on the development and management of resiliency programs as well as effective management of crisis events.
firstname.lastname@example.org expressing your willingness to serve.
The following list of principles should be considered by members seeking to become a TUG Director. TUG Directors are expected to:
Candidates will be announced at the March 20th MoM. If there is a sufficient number of candidates, the election will take place by electronic ballot during the month of April, and the results will be announced at the May Meeting.
The incumbents running this year are:
Stay Connected with TUG
The Toronto Users Group is committed to providing you with communications that are timely, relevant, and insightful. Canada's Anti-Spam Legislation (CAS) requires that we receive your permission to continue sending you emails.
You may have already given us your consent. If you haven't done so yet, or if you're not sure, please click on the following link to indicate that you would like to continue receiving electronic communications from TUG.
Should you change your mind, you can unsubscribe at any time, by clicking on "manage your subscription" at the bottom of our messages.
The Toronto Users Group for Power Systems (TUG) is a user group/forum for the exchange of ideas, and specializes in providing affordable education relating to the IBM iSeries, AS/400, System i, and Power Systems platforms. TUG is in its 34th year of operation.
Do we have your current e-mail address and other contact information?
Email the TUG office to keep us up-to-date.
Copyright 2019 - Toronto Users Group for Power Systems (Power Systems is a trademark of IBM Corporation.) IBM and the IBM logo are trademarks or registered trademarks of International Business Machines Corporation in the United States and are used under license by IBM Canada Ltd. Linux is a registered trademark of Linus Torvalds. Other logos appear in this message for reference purposes only, and are trademarks or registered trademarks of their respective owners.
(Please note that if you forward this email to any third party, they will be able to view your personal data once they click on the link to Manage Your Subscription, unless you remove that line from the message.)
eNewsletter design by Eclipse Technologies Inc. (www.e-clipse.ca)