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.
I’ve been known to tell a story about when my CEO rounded up the executive management team (I was the CIO at the time) and pounded us with the question: “Why are we going out of business as the most secured company in the world?” We couldn’t believe it. There must be some mistake – we were passing audits, we were compliant, and we were secure. It was impossible to us that our balanced scorecard results were dismal. We were experiencing decreasing satisfaction scores, losing customers, and failing to meet our enterprise objectives around growth.
We were focusing our efforts on compliance, and our performance was struggling. The balance between performance and conformance were heavily tilted toward one side of the pendulum. Technical requirements were driving the business, rather than the business determining how to respond to those requirements in a manner that best served our stakeholders. Of course, compliance is crucial for business survival, but it’s not always the only guidance system to use for value creation. Compliance does not dictate security and security is not a guarantee that vulnerabilities will not be exploited. It is a matter of managing risk to an acceptable level of tolerance commensurate with business objectives.
Organizations should leverage multiple perspectives when determining how to prioritize efforts towards creating value. As in travel, you need to have a good fix on your coordinates: location, altitude, heading and speed before you determine your future moves. Where most companies go wrong is in choosing only one of these variables which gives you one perspective. Just like using a GPS to help you navigate, here’s how you should use more than one guidance system to help you focus efforts.
First, how does GPS work?
GPS satellites help you find your position on the ground based on time and position of satellites. A GPS receiver monitors multiple satellites and determines a precise position. At a minimum, four satellites must be in view of the receiver. This is called trilateration. The first satellite locates you, the second narrows your location, the third reduces the choice to two possible points, and the forth calculates a timing and location correction and selects one of the remaining two points as your position. Knowing the satellites’ locations and the distances to them allows the receiver to pinpoint its position on the Earth’s surface. It is possible to find your position from 3 satellites. However, there is an advantage in using 4 satellites to determine your three dimensional position with no ambiguity.
Develop pinpoint accuracy
A fine balance between performance and conformance are important in any organization. However, most enterprises that I encounter have a tendency to lean towards the conformance side to the point where it actually affects business performance. This is similar to finding your precise location on the ground by using only one satellite. Having tools available that offer pinpoint accuracy to where you need to focus efforts in an organization is crucial, hence, the GPS analogy. Decision making around efforts such as funding, assurance, improvements and compliance are all areas within an enterprise that require resources, and should not be determined with only one signal. The more ‘GPS’ signals you have looking into your ecosystem, the more accurate you can be at focusing your efforts.
I suggest using the GPS strategy where you have multiple perspectives, or guidance systems to determine the current status of your business. This will drastically improve your chances of NOT being like us: going out of business as the most secured company in the world. These four GPS signals include 1) Goals Cascading, 2) Risk Scenarios, 3) Pain Points, and 4) Regulatory & Compliance (see Figure 1.)
Figure 1, Using Multiple Satellites to Prioritize Efforts
The four satellites
One. Cascading goals.
One of the best-kept secrets in our industry today is the goals cascade. The cascade, as depicted in Figure 2 below, illustrates how an enterprise can select and prioritize practices that are the most applicable to meeting enterprise goals, and ultimately stakeholder needs. The model begins with stakeholder drivers that influence stakeholder needs. Stakeholder needs can be literally mapped to enterprise goals, IT-related goals, and finally enabler goals. Sounds like a daunting task? Here’s a bit of advice: the model is already done for you in COBIT. You’ll find a generic set of tables that map each of these levels. Although they are generic, they are adaptable and surprisingly relevant.
Figure 2, The COBIT Goals Cascade. Information from COBIT5, ISACA
This is not just an academic reference, but a really helpful tool. Once you’ve seen how this works, you will most certainly be hooked. At the enabler level is a more holistic view of the ingredients required to govern and manage enterprise IT. For example, if you know that a particular enterprise goal is the most important goal for the next year, then you can literally map that goal through the cascade and determine exactly which processes are critical to its success. This will result in a list of areas that you can use to compare to the other satellites, but remember, this is only one of four guidance systems.
Two. Risk scenarios.
The use of scenarios is key to risk management and is applicable to any enterprise. An IT risk scenario describes IT-related events that could lead to a business impact if it occurs. Luckily, COBIT5 for Riskcontains a set of generic IT risk scenarios and can serve as inputs to risk analysis activities, and their effects on overall business objectives. Although the generic scenarios in COBIT do not replace the creative and reflective phase that every exercise should contain, it is not wise to assume that no other risk scenarios are possible or applicable.
After you define a set of scenarios, use this for analysis, where you can assess frequency and likelihood analysis while considering all of the risk factors involved. Risk factors are the conditions that influence the frequency and/or business impact of risk scenarios. Part of this analysis can be in the form of a risk map as illustrated in Figure 3. The numbers in the map represent the various risk scenarios.
Figure 3, Risk Map
This process results in the risk register, which records each scenario’s specific events, actors, threat types, asset or resource at risk, response, and mitigation. This process gives you valuable information for informed decision making, as well as a substrate to all of the other guidance systems. Use the results of this “GPS signal” to come up with the most critical risk scenarios that could hinder enterprise objectives, determine pain points, or guide compliance mitigation responses.
Three. Pain points
We all have them. Whether they are the “elephant in the room” that nobody wants to talk about or well known throughout the enterprise, pain points are those areas that need little effort to identify. Use pain points as additional drivers from which efforts towards the Governance of Enterprise IT initiatives are chartered. This can have a positive effect on the buy-in of your business case and creates a sense of urgency and support as well.
In the COBIT5 product family, the COBIT5 Implementation Guide does a superb job of identifying some of the most common pain points associated with enterprise IT. It also maps these pain points to specific processes in COBIT. For example, let’s assume that outsourcing service delivery problems such as agreed–on service levels consistently not being met is an identified pain point. Go to Figure 45 of the publication, and it identifies the following processes that could be selected for guidance corresponding to that pain point:
EDM04, Ensure Resourced Optimization
APO09, Manage Service Agreements
APO10, Manage Suppliers
To take this a step further, refer to the COBIT5 Enabling Processes publication for more information on definitions, goals, practices, activities, inputs/outputs, and roles/responsibilities for each of those processes.
There you have it, your third GPS signal to help identify your priorities. Now, we move on to the last of our four required guidance systems.
Four. Legal/Regulatory/Compliance requirements
If you’ve been in the assurance space for any amount of time, you are aware that no organization can be 100% compliant to everything that is out there. You have to synchronize this with your risk management process to determine the right response to each requirement. Some requirements; however, are legally required and must be adhered to, but as stated earlier: what level of adherence is the most appropriate?
The point of the above story is this: if you put steel plates over every opening, you may not have the funds to pay the mortgage, so you have to link this with the risk analysis and management processes in the enterprise (see our earlier guidance system regarding risk) to help determine the right investment of resources. In any case, with the volumes of legal and compliance requirements facing most organizations, it is best to determine the level of response based on what is best for the organization by balancing performance and conformance. The results from analyzing this GPS signal will help you determine what you may be legally required to do, and the level of response required in order to create value.
Aligning your satellites
Each of these guidance systems should result in a very clear list of high interest areas that would be the most appropriate from that perspective. Now, compare the lists. Are there any recurring areas? Certainly, there are, but if not, you can devise a prioritization scheme for each of these lists and normalize them into a single list. Now that the most important areas have been identified, compared and analyzed, more focused efforts can be identified.
Up to this point, I’ve been referring to focus areas, but now that we’ve walked through the concept of having multiple perspectives, what does this mean exactly? Let’s do a review of what focus areas might be:
Assurance activities. Audit scoping, prioritization, frequency and level of effort of audits that ensure the service providers are focused on providing value for the enterprise.
Resource allocation and prioritization. Portfolio, program, and project funding that support alignment with the real objectives of the enterprise.
Quality and improvement. Initiatives focused on the overall improvement of services, functions, performance indicators, goal attainment and compliance.
IT and business alignment. The BIG ONE! Ensuring that service providers are focused on what the higher level goals are, up to the stakeholder needs of creating value.
Conclusion
The enterprise exists to create value for its stakeholders: realizing benefits while optimizing risks and resources. This requires more than one perspective, or ‘guidance system’ to fully understand what is required to do this. This blog has only identified four potential perspectives that worked for one organization. Yours might have more, but should never have less.
To link this strategy back to the original problem, how did my company prevent going out of business? We implemented a cohesive and consistent approach, using the four satellites, to determine those processes, practices and activities that really focused on creating value.
Give it a try, you might find that the business case is hard to challenge. As always, this is my perspective, and I welcome your comments or suggestions.
Recent Comments