TUG Buzz! for Monday February 25, 2019


  1. ERM vs. ORM - article by Garth Tucker
  2. TUG Board of Directors - Nominations Open
  3. Stay Connected - Confirm your subscription to TUG Buzz

[article] Enterprise Risk Management (ERM)
vs Operational Risk Management (ORM)

Garth TuckerBy Garth Tucker

Over the last several years, I've run into roadblocks from ERM folks in organizations where there is no well entrenched Business Continuity (BC) program. Now before anyone starts calling for my head on a pike, I respect and understand (mostly) ERMs role in an organization. Unfortunately, many ERM folks don't like to differentiate between what they do and what a BC practitioner requires to begin building a program. Most see risk as they define risk and the only way it's assessed is via an actuarial process. A BC planner is obviously concerned about financial risk to the organization as well, but it's not our only focus. Whereas ERM folks look through a lens which is focused on the organizational bottom line.

This is where we begin throwing the spoiled produce at one another across boardroom tables.

Now, before we begin this dissertation, let's define both processes via Wikipedia (my favorite argument resolver along with Google smiley .)

Typical ERM functions         Operational Risk Management

The primary risk functions in large corporations that may participate in an ERM program typically include:

  • Strategic planning - identifies external threats and competitive opportunities, along with strategic initiatives to address them
  • Marketing - understands the target customer to ensure product/service alignment with customer requirements
  • Compliance & Ethics - monitors compliance with code of conduct and directs fraud investigations
  • Accounting / Financial compliance - directs the Sarbanes-Oxley Section 302 and 404 assessment, which identifies financial reporting risks
  • Law Department - manages litigation and analyzes emerging legal trends that may impact the organization
  • Insurance - ensures the proper insurance coverage for the organization
  • Treasury - ensures cash is sufficient to meet business needs, while managing risk related to commodity pricing or foreign exchange
  • Operational Quality Assurance - verifies operational output is within tolerances
  • Operations management - ensures the business runs day-to-day and that related barriers are surfaced for resolution
  • Credit - ensures any credit provided to customers is appropriate to their ability to pay
  • Customer service - ensures customer complaints are handled promptly and root causes are reported to operations for resolution
  • Internal audit - evaluates the effectiveness of each of the above risk functions and recommends improvements
  • Garth

The term operational risk management (ORM) is defined as a continual cyclic process which includes risk assessment, risk decision making, and implementation of risk controls, which results in acceptance, mitigation, or avoidance of risk. ORM is the oversight of operational risk, including the risk of loss resulting from inadequate or failed internal processes and systems; human factors; or external events. Unlike other type of risks (market risk, credit risk, etc.) operational risk had rarely been considered strategically significant by senior management


The International Organization for Standardization defines the risk management process in a four-step model:

  1. Establish context
  2. Risk assessment
    • Risk identification
    • Risk analysis
    • Risk evaluation
  3. Risk treatment
  4. Monitor and review

This process is cyclic as any changes to the situation (such as operating environment or needs of the unit) requires re-evaluation per step one.

The disciplines are the same, but different-ish smiley 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:

  • Can staff get to their workspace?
  • Is winter maintenance of parking lots, facilities, etc. being taken care of?
  • Will excessive snowfall or melt cause a building evacuation?
  • Will a large rain event flood the basement and what do we do if it does?
  • Will an ice storm compromise the electricity grid to the point it can't be used, and do we have the diesel or natural gas supply to sustain us until power is restored?
  • Etc., etc., etc.

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:

  • Business, legal, regulatory, statutory and contractual requirements and restrictions both from an internal and external perspective, providing recommendations on conformance and compliance for the organization.
  • Identification of conflicts between organizational policies and relevant external requirements.
  • Identification of business practices (such as complex supply chain strategies implemented on a regional or global scale) that may adversely impact the entity's ability to recover following a disaster event.

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 smiley.

Thanks to everyone who provided feedback/peer review for this article, muchly appreciated!

Garth Tucker, CBCP, CORP
Resilience Professional

Skype: garthatucker

GarthGarth 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.

The path to his current position began with software development, project and program management, and as an IT technology educator worldwide for IBM in the late 1990s and early 2000s. He transitioned to disaster recovery, business continuity, and crisis management beginning in 2002. Significant formal, and self-education throughout his career has ensured he remains relevant and effective.

Back To Top

TUG Board Election

Have you thought of becoming a Director of TUG? Nominations are open from now through Tuesday March 19th for candidates interested in running for a Board seat during this year's general election. To enter, simply send an email to 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:
     • Maintain active membership in TUG and keep their membership dues current
     • Attend at least 50% of TUG Board meetings and/or TUG events
     • Uphold and abide by the official bylaws of TUG
     • Act in a professional manner as a representative of TUG
     • Advocate on behalf of the IBM i platform

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:
     • Leo Lefebvre
     • Bob Lesiw
• (plus one open seat)

Back to Top

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.

Consent button

Should you change your mind, you can unsubscribe at any time, by clicking on "manage your subscription" at the bottom of our messages.

Back To Top

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.

Browse our
Articles & Downloads archives

Browse our
TUG Buzz! archives

Browse our
eZine archives

TUG GOLD Members


Do we have your current e-mail address and other contact information?
Email the TUG office to keep us up-to-date.   

TUG Juggler 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. (