DON’T WAIT FOR A RISK EVENT TO HAPPEN BEFORE YOU ADDRESS YOUR ENTERPRISE RISKS.

As I write this blog, I am experiencing a business disruption, and it is very frustrating. Should I blame my vendor, or is it my fault for not effectively managing my business risks?

I outsource my email and my provider has been down for several days with no end in sight. In fact, it took them several hours to even fess up to this event, and when they finally did, the communication was dismal at best. If you don’t use Rackspace for your email, you most likely haven’t heard about this massive outage. If you do, you are probably shaking your head while you read this.

Like most businesses, especially small entities like mine, we outsource many of our processes. We outsource IT services, payroll, testing, recruiting, development, websites, and many others. However, I can’t think of a single company like mine who doesn’t outsource their email. Small to medium sized enterprises depend on it. When I was working in large enterprises, I used to always joke about email. My theory was that email wasn’t considered a critical service until it went down. Well, it did for my business, and as it turns out…yes, it is a critical service. But I had a backup plan because I considered my risks, but did I do enough to predict this?

I don’t mean to beat down Rackspace while they’re down, but here’s my perspective from a customer/user perspective. Today is Monday, and this event started on Friday. I still have no clue what is going on. Rackspace is a $3B company who has recently chosen to ship its “Fanatical” customer service elsewhere as well as conducing several layoffs in recent memory. I’m not saying these are root causes, but I certainly should have seen these as potential risks. I’ve seen their service management practices decay in the last several months, but still considered any risk scenario with Rackspace as low likelihood because of their history with me.

If you do a quick search on Twitter, you’ll see some VERY irritated customers:

Let’s link this whole situation to risk. As a business owner, I think about those risks that could prevent my business from achieving its objectives. I continually think about the risk management process when it comes to my business. For your reference, the following is a quick view of the risk process I use:

 

Let’s dive into how I was somewhat prepared for this risk event. Using my risk management process from above, I want to break down my thinking for you.

Step 1, Identify my risk appetite.
Risk appetite is defined as the amount of risk I am willing to accept in pursuit of my goals, where tolerance is the acceptable level of deviation, or what I call the “wiggle room” under certain circumstances. What is my risk appetite and tolerance with respect to client communications?
“I will not accept a risk scenario that prevents me from communicating with my clients for more that three days. I will have a limited amount of tolerance during weekends, holidays and times of low project reporting times as long as it does not affect project deliverables.”
Now, let’s see how this drives the next several risk management steps.

Step 2, identify risk scenarios.
Think about the events that could happen that would impede your progress. As a small business owner, you can use several techniques to do this such as identifying previous events, scan current newsworthy events and industry articles, brainstorming, and identifying all scenarios that could possibly prevent you from meeting your goals.

For me, these include the following three high level scenarios:

An event that could prevent me from traveling, because travel is key to me delivering many of my engagements and courses.

An event that could prevent me from sharing knowledge online because I’m in the business of sharing knowledge with clients and peers.

An event that could prevent me from communicating with my clients, suppliers, and peers, because this is required for me to contract, execute and close projects with my clients.

An event that might affect my standing in the GRC community.

Therefore, examples of my key risk scenarios include:

Power, internet, or telco outage

Sickness or illness

Disruption in the travel industry

Failure to stay on top of the latest trends in GRC

A contractual or legal matter

Step 3, Analyze and assess risk scenarios.
This sounds easy, but it takes a little thought. For each of the scenarios that I discovered in step 2, I had to come up with a way to prioritize these. I went with the basic X and Y grid using X for likelihood and Y for impact.
Imagine a grid that visualizes this. You can use any form of measurement for this, like Low-Med-High, or a numerical system to meet your needs. Something like this:

Likelihood identifies the ‘chances’ the risk event could happen. It is based on frequency, probability, vulnerability and event timing. Impact is very different. It looks at things like goals achievement, financial, reputational, compliance, safety, privacy, and security impacts.

Once I identified these risks and analyzed their impact and likelihood, I prioritized these risks. It comes as no surprise that “power, internet, or telco outage” was high on my list. I’m also assuming that an email outage is part of this.

Step 4, Determine responses to those scenarios.
Now that I had a prioritized list of risks to my business, what should I do? I’ll boil this down to four primary responses:

I can choose to simply accept the risk.

This is not an option. Accepting a risk means that if the risk event becomes real, there’s no effect on my business. Accepting a risk basically means that if it happens, the effects are within my risk appetite and tolerance levels. Pass on this option since it exceeds my risk appetite.

I can choose to avoid the risk.

Avoidance in this case means that I choose to not use email at all, therefore avoiding the risk of this affecting my business. I choose to pass on this option as well because I, and many of my clients, depend on this communication medium.

Additionally, there are cost effective responses I can put in place to reduce either the likelihood or impact within my appetite level.

I can choose to transfer the risk.

Of course, the typical answer to this is insurance or outsourcing. Well, I outsourced this, but there is still the possibility of third party or vendor risk. What if my outsourcer fails? Yep, that happened. Let’s move to mitigation.

I can choose to mitigate the risk.

As luck would have it. I chose to mitigate this risk. Things that were going through my mind were things exactly like what is happening right now: what if my outsourcer fails to deliver on our agreement?

Here are my mitigations:

Create alternative email addresses to use in case my vendor fails

Use social media to communicate the change in my status

Have multiple sources of internet including phone hotspot and internet hotspot from a different provider

Step 5, Monitor these risk scenarios and continuously update my risks.

Here is the tough part, and frankly where I failed. For each risk, it is key to create some indicators that tells you whether the risk likelihood is low or high. Think of this as the weather report. If inclement weather affects your business, then you watch the weather forecast to determine how you might approach your day. As with any risk, what are the indicators you look to for indications that the risk event might become real? I’ll be honest, I failed at watching any key risk indicators for Rackspace. Had I done this, I would have had the information I needed to move away from this high-risk relationship before the risk event happened.

What I’ve leaned from this event? Digital Trust. You’ve no doubt seen some of my recent social media posts on digital trust. I’ve been a customer of organizations who have experienced situations like this in the past, but I stayed with them. Take for example a major hotel chain that has experienced several reportable breaches, yet I’m still a loyal customer of theirs. Why is it that Rackspace has one event, and I’m ready to leave them? That is digital trust. Stay tuned, I’ll be posting a blog on digital trust very soon.

As always, I look forward to your comments.

RISK APPETITE – MORE IMPORTANT NOW THAN EVER

The concept of risk appetite and tolerance is commonly referred to in today’s volatile and unpredictable business environment.  Based on my conversations with multiple businesses over the last several months I’ve found that it is a widely understood, but often misapplied concept.  I was working with a client recently to assess whether the residual risk in the current control environment was within the enterprise risk appetite levels.  Due to some recent market shifts, the board of this company had made some significant changes to their risk appetite guidance.  The guidance was expectedly very high level because of course, that’s what the board does, but how could we take that high level guidance down to a view where control owners can determine if they are within the appetite guidance?  This is a systemic problem for most of us.  Deciphering high level risk appetite statements is sometimes difficult to begin with but failure to have mechanisms in place to translate that guidance into decision making at the operational level can be one of your biggest vulnerabilities.

What is risk appetite?

Each organization has their own objectives intended to create value for its stakeholders and should broadly understand the risk it is willing to undertake in doing so. Therefore, the risk appetite statement is an expression of the amount and type of risk that an enterprise is willing to accept in the pursuit of its business goals.  Organizations should have a framework that provides an approach to the management, measurement, and control of risk.

Oftentimes, risk appetite is used interchangeably with risk tolerance and risk capacity.  Although they are related it is important to understand the key differences. Tolerance differs from appetite in that it defines the acceptable level of deviation, or what I call the “wiggle room” under certain circumstances.  Capacity, on the other hand, is the objective amount of loss that an enterprise can tolerate without risking its continued existence.  It differs from risk appetite which is more high level.

I was recently talking with a colleague of mine, Ed McCabe (Linked-In Profile) about this subject.  My question to Ed was this:  “Why is the whole concept of risk appetite largely misunderstood at many companies?”  His response, not surprisingly was this:  “Normally it falls into one of three reasons.  First, organization’s don’t want to think about it – they focus on ‘what they’ll win’ rather what they’re betting with, what they could potentially lose if things don’t fall inline. Second, organizations aren’t investing the time to define and communicate a clear understanding of how they are defining these levels.  All too often I see Boards and Senior Management use a scaled system of High, Medium and Low, but they don’t actually define what those are for their staff.  What’s “High” to a system administrator sitting behind a console isn’t going to be “High” for the CIO or CFO. Finally, one of the last things that I’ve seen is that no one has taken the time to simply ask the question or effectively communicate what the risk appetite and tolerance criteria actually is.  We live in a very volatile and dynamic business world, one in which our risk appetite and tolerances are going to change – it falls on us to seek out the proper definitions for these.  If you struggle getting those answers, then I suggest start with the absurd and then let Senior Management respond accordingly so we can then adjust and gain that clarity and definition.”

Based on his input, we agreed on a simple analogy to help put these three definitions into perspective:

Looking at appetite from different views.

Appetite statements often start out broadly with a single high level statement followed by more detailed statements that cascade down to different levels of the organization. Some organizations find that broad statements such as “low,” “medium,” or “high” appetite are suitable for their needs but this largely depends on your culture and organizational structures.  The higher you are in an enterprise, the more vague the guidance appears.  Logically, the lower you go, the more specific the guidance should be.  There is no right appetite that applies to all organizations; however, there is an appetite suitable for each organization that can be interpreted and used at all decision levels.  How do we take a high level appetite statement from the board and apply it to the level in which we are working and trying to make decisions?  In the case of the client I was working with, they chose looking at appetite from three views, or what they called altitudes:  strategic, tactical and operational.  

Strategic Altitude

The risk appetite at this level should clarify the nature of acceptable risk and provide confidence that the organization remains aligned with its overall mission and vision.  This is generally considered the highest level of the organization such as the governing body and/or executive management. 

At the strategic altitude, risk appetite is driven by many factors such as mission, vision, values and of course the strategic direction of the enterprise.  For example, if an organization’s strategy assumes its industry will undergo significant disruption from digital transformation it may see the need for a higher appetite to be innovative and successful in the market.

Strategic categories may relate to growth, efficiency, customer or innovation (you may recognize the four dimensions of the balanced scorecard here).  More progressive organizations may also consider corporate responsibilities in the social, environmental and diversity areas as well. These are typically set out in a strategic plan or an annual report. Most often, there are very few categories at this level.  Below is an example of an enterprise’s stated strategy and possible appetite statements. 

Tactical Altitude

Below the strategic view comes the tactical view.  This is generally the business unit level.  I would also include areas such as finance, IT, HR, etc.  This is an important link between the highest level of appetite and what I call the “street view.”

This altitude takes the strategic risk appetite statement and transitions this into more specific guidance based on the objectives of that business unit.  Not only will the tactical altitude determine more specific appetite, but here is where I now insert risk tolerance and capacity clarity.  Tolerance is more specific and provides insight into decisions made within the business unit decision making structure. Unlike the broad risk appetite, tolerance is tactical and focused. Ideally, the tolerance guidance should apply to specific business unit objectives, should support the overall strategic appetite statement, easily understood and cascaded down to the operational level for risk-based decision making. 

When determining tolerance, the business unit considers the overall enterprise appetite and how it applies to the relevance of each objective where the highest ranked objectives may have lower risk tolerance levels.  As discussed earlier, tolerance is the acceptable level of deviation for any particular risk.  At this altitude, resources become a major consideration as well, where you may assign more resources to areas with lower tolerance levels.  Below is an example of a tactical level (business unit) tolerance statement based on the organization’s appetite. 

Operational Altitude:  

This view is focused on performance, or what I called the “street view” earlier in this blog because this is where the work gets done and decisions have to be made to deliver products and services.  At this view, questions such as “How much risk can I take to achieve an objective?” must be considered.  Performance achievement can identify whether the organization is, or is not assuming enough risk to achieve the desired objectives.  Therefore, this is the place where the balance between risk and performance is determined.  A question I often ask decision makers at this altitude is this:  “How do you know that the decision you are about to make is within 1) your level of authority and 2) within the appetite and tolerance levels of the enterprise?”    

Views regarding performance often vary within the organization. Management should not assume that operational leaders have the guidance they need to make decisions within the intended appetite. It has been my experience that in many cases they simply don’t know what that appetite is, so they are making decisions blindly.  Therefore, organizations need to review the application of appetite through other practices. This can be done through an effective monitoring and communication plan, which is up next.  Let’s say your organization has effectively identified and communicated risk appetite and tolerance levels throughout all of these altitudes.  If so, you may have statements that look something like the following:  

Communicating risk appetite.

Having a cascading appetite and tolerance mechanism sounds great, but it is useless if you don’t communicate this information throughout the enterprise which allows for all altitudes to make appropriate and informed risk based decisions that are within the defined appetite and tolerance levels.  

Of course, communication mechanisms vary based on the culture and structure of each organization.  To get some clarity on this, I reached out to Robin “Montana” Williams (https://www.linkedin.com/in/robin-montana-williams-88b8a024/) to get his suggestions on how to communicate appetite and tolerance throughout the organization, and he offered me some great advice:  “The communication of clear and defined appetite parameters that an organization will take in pursuit of its business objectives, and the tolerance acceptable variation in the performance measures linked to organizations business objectives must be understood across the organization—from the boardroom to the breakroom.”

Communication channels should be open and easily implemented so that all altitudes are up to date on organizational risk information.  Lower altitude employees tend to focus on specific limits defined in risk tolerance as opposed to the high-level strategic objectives and how they are aligned with risk-taking, so ensure that you are tailoring risk communications based on the point of view.  

It is also very important for your audit and assurance function to be aware of appetite and tolerance.  Audit scopes their efforts from a risk-based perspective and can use this information to gain insight on what the organization and stakeholders consider their highest risks.  Not wanting to leave audit out of this, I reached out to Mary Akers (Linked in link) for her audit input on this blog:  “An organization can have all of the right frameworks, policies and procedures documented and still not effectively communicate.  An organization’s culture as well as unclear directives of departments such as Compliance, Risk Management, and Assurance/Audit has a significant impact on the critical information that ends up in all forms of communications to include status reports and matrices, whatever methodology is utilized.” 

When the organization’s emphasis on meeting budgets, employee performance assessments, and deadlines become more important than meeting business requirements, communications will naturally be overly optimistic; even those projects that are reportedly in red status. Important attributes and critical controls will be overlooked.  Why? Because the organization’s tolerance and capacity are not aligned with risk appetite culturally and practically. Assess what is documented with what is actually occurring in practice. Don’t let the external auditor/examiner or hacktivist be the first to tell you that you have communication issues which end up with far more adverse consequences such as financial and reputational impacts.

Based on my research and experience, I can summarize that effective communication strategies should have the following attributes:   

  • Statements should be clear, understandable and stated in a way that assists decision making
  • Statements should be applied and cascaded through all altitudes of the organization 
  • Statements should be documented through policies and procedures
  • Statements should be adjusted and communicated as internal and external factors change the enterprise’s risk profile

Mark’s top tips.

I normally have a lot of my own tips and tricks in my blogs, but since I reached out to several colleagues for their input, I thought it was best to get their tips for this closing.  

Mark’s top tip:  Integrate risk appetite, tolerance and capacity statements with all decision making levels in the organization.  As discussed in this blog, start with a strategic, tactical and operational view and add/remove “altitudes” as your organization sees fit and adjust your appetite position as your environment changes.  

Ed’s top tip:  Take the time to ask and answer the hard risk appetite and tolerance questions, for the pessimists this means asking “How much am I willing to lose?” for the optimists “How much am I willing to bet that we’ll succeed?” Whether you’re a pessimist or optimist, ask the question until you get a sufficient answer.  Too often I see organizations that don’t effectively communicate the risk appetite and this results in a lot of time and effort spent on attempting to engineer for solutions that otherwise should be accepted and not focusing efforts where they really should be – those risks which exceed the defined risk appetite.

Montana’s top tip: Maintaining consistent understanding, implementation, and monitoring of appetite and tolerance is the key to achieving the desired outcomes that enable attaining organizational objectives.

Mary’s top tip: Do your homework and read the engagement risk appetite, tolerance, and capacity statements. Don’t simply ask management, “what keeps you up at night?”

As always, your thoughts and reactions are welcomed!

INTEGRATING ENTERPRISE AND IT RISK FUNCTIONS USING SCENARIOS

The challenges that organizations face today are increasingly more complex than in the past. The constant change of the global economy, dynamics of business risks and opportunities, and an increased threat of cyberattacks add complexities we’ve never faced. Organizations today must constantly scan their environments and take practical steps to make risk-informed decisions that provide value for stakeholders.

It is not uncommon to see several roles and perspectives in an enterprise all collaborating on risk. Although they all have very valuable and unique viewpoints, their duties are often split across several functions of the organization. Coordination between these efforts is paramount to ensure a holistic enterprise view of risks across all functional lines of business. Emerging practices have led to the “Three Lines of Defense” model which provides a balanced echelon of mechanisms to protect the organization and allow enhanced decision-making. These three lines generally consist of: 1) Operations, 2) Risk/Compliance, and 3) Audit. Although all three are important, my focus today is on the first two. Ensuring alignment of identified risks between IT and enterprise efforts is key. It not only increases the visibility of risks, but reduces duplications of effort, improperly understood impacts, and poor decision making.

ERM vs. ITRM

From a functional perspective, risk has been managed from two primary directions. The first is from the enterprise perspective, top-down approaches focused on protecting assets reported on the balance sheet and assisting business executives in making informed decisions to protect those assets. We’ll call this Enterprise Risk Management, or ERM. The second is from the ground up, for example IT Risk Management, or ITRM, focused on the protection of the confidentiality, integrity, and availability of information and data. If you’ve been in IT for a while, you’ve witnessed the IT risk function grow from a few network security people in the basement to a function that looks at all risks that can be encountered in relation to IT investments. Now we are seeing two formal functions in an organization that often fail to synchronize their efforts. These perspectives are the ERM and ITRM functions. Therefore, one of the most common questions I get during risk based discussions is, “How do we get ERM and ITRM to collaborate in determining the holistic and/or aggregate risk from an enterprise perspective?”

Enterprises have come a long way in making decisions based on risk appetite and tolerance. This is largely in part due to the technologies that have allowed this to happen, as well as a better understanding of the types of risk they encounter. These types typically include the following:

It is important to note that the IT-related risks are a substrate to business risks. While the enterprise risk function focuses on the strategic business-related risks, the IT risk function focuses on IT-related risks that can have an effect on meeting business goals and objectives. Considering the emphasis of value placed on an enterprise strategy, ownership of the process should begin at the top, cascading downward to operational or functional managers, and in the case of IT-related risk, ITRM. However, not all risks can be identified using the top-down approach. A bottom-up approach provides some very specific scenarios based on technical vulnerabilities. If ERM processes support the top-down enterprise direction while the ITRM focuses on the IT-related risks from the bottom up, how do we optimize the two approaches to support a holistic strategic direction? The goal is to replace the old compartmentalized approach to managing risks with a more effective enterprise approach.

The Risk Process

The schematic below is a very high level depiction of a typical risk process. The separation of governance and management is key here. Risk governance sets direction and strategy as well as defines risk culture and acceptable levels of risk for the enterprise. It also ensures that risk management is effectively identifying, assessing, managing, monitoring, and reporting on all risks facing the enterprise. Risk management, on the other hand, is responsible for implementing IT related risk practices and activities per the policies and direction set by the risk governance function. To have effective risk management, the enterprise must maintain a focus on the business mission, goals, and objectives while integrating ITRM into the ERM function. This is where the gaps begin to emerge.

 

If you are looking for a more detailed description of this process and its practices and activities, some of the most applicable frameworks include: COSO, NIST, ISO38500, ISO31000, ISO27000 and COBIT5.

Using Risk Scenarios.

Assessing risk includes identifying, analyzing, and evaluating risks. I believe a core practice for this is to use the concept of risk scenarios as the starting point and basis of any assessment. A risk scenario describes an event that, if it occurs, could have an adverse impact on the business. The process of creating these scenarios includes four basic steps: 1) create generic scenarios, 2) validate scenarios against business strategy, 3) reduce scenarios to a manageable set, and 4) develop the risk register with the appropriate analysis and response. Risk scenarios can be created at any level of the business, but since this blog is focusing on connecting ERM with ITRM, we’ll keep our focus on those two altitudes.

As mentioned in other blogs I’ve posted, the COBIT5 for Risk document produced by ISACA has some great generic scenarios from which to start. There are 111 risk scenario examples in 20 categories. Although these scenarios are quite extensive, they are not intended to replace your organization’s creative process of determining which scenarios are applicable to you.

Creation of the IT Risk Scenarios.

Step One

Identify and validate a set of enterprise goals for the customer organization(s) you support.

Step Two

Determine the long list of potential IT risk scenarios. No need to do a full analysis at this point. Hint: COBIT5 for Risk.

Step Three

Shorten the scenario list by determining which scenarios impact the enterprise goals identified in step one. See below for an example of how to visualize this. You can also use a grid, or risk map, to visualize the Severity and Likelihood as well. See here for an example.

 

Step Four

Analyze each scenario and create a ranking, then create the IT Risk Register.

 

You might notice that each of our scenarios seems very high level. That is good. In the risk register, more details are added that provide structure to the scenario. For example, let’s take our first scenario from the above list: “There is an overreliance on key IT Staff.” This scenario can have from one to several specific events that led us to this scenario. For example:

  1. There is only one DBA in the organization and we are highly dependent on the information in our databases;
  2. Our primary developer is the only person who knows how to maintain our core business application; or
  3. Our Service Desk Manager knows the IT environment so well (s)he is used as both a level one and level two resource.

It’s at this level you can focus your risk responses (accept, transfer, avoid, or mitigate) and propagate your selected responses up to the generic scenario.

So we’ve created our IT Risk scenarios and register. How do we link these to enterprise risk? Within the ERM function, a set of risk scenarios can also be maintained that focus on even higher level risk scenarios – those that are focused on the business (strategic, environmental, market, credit, operational, compliance). As noted earlier in this blog, IT-related risk is a substrate to all other areas. So think of it like this. If the enterprise creates the high-level scenarios and supports them with specific events, the specific events can also be the high level scenarios identified by ITRM. It looks like this:

 

Business colleagues working together on a computer in an office.

Of course, all of this is largely dependent on the organizational structures, policies and procedures of each enterprise, but the concept is valid. We look at risk from multiple altitudes, and should strive to ensure they link. The process of keeping these altitudes aligned is a never-ending effort. Risk scenarios don’t wait until your next semi-annual planning process; they are dynamic and fluid. Therefore, constant vigilance towards keeping the scenarios aligned between ERM and ITRM is vital to proper decision making.

Here are some suggestions to keep in mind when it comes to managing the alignment of your risk scenarios (in no particular order):

  1. Create an enterprise view of the process that encompasses all business units and IT
  2. Adopt a common taxonomy for risk definitions and terms
  3. Cascade risks from top down and bottom up
  4. Link all risk scenarios to enterprise/business goals
  5. Identify and document appropriate roles (including ownership) and functions that are critical to risk governance and management
  6. Embed risk into the culture through training and awareness
  7. Use scenarios to make informed response decisions based on enterprise risk appetites and tolerances
  8. Leverage industry best practices to assist in designing and documenting your processes
  9. Apply both qualitative and quantitative analysis in the process to provide a solid foundation to your efforts
  10. Understand that this does not guarantee success, it provides the information needed to make better informed decisions

This blog focused on the alignment of scenarios and, as you may know, there’s much more to governing and managing risk than having scenarios. Just having lists of risks scattered throughout an enterprise with no real scenarios to link them to is akin to an un-prioritized to-do list that neither creates value nor supports informed decision-making.

I hope this short example has helped and, as always, your feedback is welcomed.

Skip to content