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:
- There is only one DBA in the organization and we are highly dependent on the information in our databases;
- Our primary developer is the only person who knows how to maintain our core business application; or
- 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):
- Create an enterprise view of the process that encompasses all business units and IT
- Adopt a common taxonomy for risk definitions and terms
- Cascade risks from top down and bottom up
- Link all risk scenarios to enterprise/business goals
- Identify and document appropriate roles (including ownership) and functions that are critical to risk governance and management
- Embed risk into the culture through training and awareness
- Use scenarios to make informed response decisions based on enterprise risk appetites and tolerances
- Leverage industry best practices to assist in designing and documenting your processes
- Apply both qualitative and quantitative analysis in the process to provide a solid foundation to your efforts
- 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.
