Published:
April 30 2009, 04:30 AM
|
no comments
by
Sumner Blount
Rick, in Part 1 of our blog Q&A
, you talked about the need for granularity in risk hierarchies. Let's explore that some more. Why is granularity so important?
Appropriate granularity may be the single most important key element of a good hierarchy. For example, we have found that the risk types defined in Basel II are too general "" they don't foster consistency, nor do they offer enough precision to support useful conclusions about a firm's risk profile, especially at the business-line level. Local business managers tend to deal with risk at a reasonably low level of detail, and unless the hierarchy supports that level of granularity, it won't be very useful for these managers.
Appropriate levels of granularity are important because they support and enable these key functions:
- Communication
- Reporting
- Convergence (across risk and management functions in the organization)
- Benchmarking and assessment (both internally and externally)
But doesn't granularity lock us in to a single viewpoint, making it difficult to grow and change?
To the contrary, granularity is the best ""perhaps the only "" way to allow such growth.
Let me compare ORM data collection to the task of collecting basketball statistics. A commentator may wish to make remarks on the performance of any specific team on any specific date (i.e., before and after particular trades), or on the performance of specific individuals playing for a variety of different teams over time. Target criteria may be number of shots, number of points scored, number of assists, number of fouls, etc. But let's say all this information is collected at the team level. This is fine as long as the team stays intact and includes all the same players. Any change in team composition would require extensive recoding and reinterpretation, or in some cases might not be possible at all. By comparison, if we begin with more granular data collection, e.g., at the level of the individual player, we could assemble any kind of resulting statistics we like, from a variety of different viewpoints, all without changing the "baseline statistics," no matter how many trades or team realignments may occur.
The same is true for ORM data. We like to think of individual categories in a risk hierarchy as Lego blocks, which managers can map and combine in any number of different ways""either modifying the firm's approach over time or supporting a number of different viewpoints simultaneously""all with little or no disturbance to the underlying dataset. This is far more economical.
Why would a firm want to support different, simultaneous mappings of its data? Easy"¦ Audit or Finance may want a COSO framework, IT a COBIT framework, regulators a Basel II framework, external data consortia a custom proprietary framework, and business managers a detailed, customized view of their own. A well-designed, granular framework can support all of these at the same time, avoiding the need for an elusive "global agreement" among all parties. All this is lost if initial granularity is insufficient.
With several hierarchies, doesn't it all become very complicated?
Not really. Or at least not if done sensibly. First, a company must decide which hierarchies need to be the most granular (often risk type and control types). Others can be kept relatively high-level since that level of detail is not required. The challenge is that different groups within the organization typically want to view risk in different ways. You have the IT group, the finance group, the compliance group, etc., and each of them wants to "slice and dice" risk in slightly different ways. A granular dataset lets each of them view risk according to their own needs. And much of the granular content may apply to only a few groups in the organization (such as IT monitoring and security content), allowing others to take it off their plates.
Once you have created a well-designed hierarchy of elements in your GRC environment, what next? How do you take advantage of this design?
Make sure that you design your risk initiatives so that you use a consistent hierarchy (for example, for self-assessment, loss types, risk scenarios, etc). Using different hierarchies in different initiatives can make it difficult to associate losses with risks. And, having a common framework can help ensure consistency across risks, losses, controls, etc., and help you map losses to risks and controls.
The bottom line is that a common framework gives you actionable information that lets you more quickly and efficiently decide where to put your strategic investments.
If the future, I think we will see more focus on causal risk events and their interconnections, rather than on the loss events alone. Confusing? Let me explain with an example. In your risk analysis, you might focus on the risk of a lightning strike and put in place activities to minimize the impact of such an event. But, ideally, you'd like to be looking at causal factors that would cause this event to actually occur "" temperature, change in barometric pressure, cloud formation, as well as other complex factors, all of which interact in subtle and complex ways. So, basically, you need a hierarchy of causal conditions and an understanding of how each one impacts the others, or reacts with the others, to create lightning (the risk event). But, frankly, this is a complex area that could be a complete topic for another day.
==================
To learn more about RiskBusiness and the company's consulting and software solutions for Risk Management, visit
http://www.riskbusiness.com/
.
By: Sumner Blount
Sumner Blount has spent his 25-year career focused on the development and marketing of software products for a range of top-tier enterprise IT firms. Currently, he’s a Director in the Security business unit at CA. Previously he managed the large computer operating system development group at Digital...
Read More..