Centralised or de-centralised risk management?

Enterprise risk management (ERM) can mean a single centralised risk management process, with one central risk register. ERM can also work through de-centralised risk management processes, with many distributed risk registers. Those de-centralised risk processes might be standardised.

Centralisation has obvious benefits. It also has problems. You can solve those problems.

De-centralised risk management has obvious problems. It also has some less obvious benefits. You can solve the problems with de-centralised risk management, and the benefits are smart reasons to do that. Integration is a key step. Integration doesn’t always mean standardisation. Integration can mean recognising the implications of one risk assessment in another. In that way the enterprise risk assessment can recognise all the implications of many separate departmental and thematic risk assessments.

What is Enterprise Risk Management? What is a ‘risk management process’? Centralised and de-centralised approaches: ERM as an enterprise-level risk management process Centralised ERM Decentralised risk management processes throughout the enterprise Decentralised but standardised risk management processes through the enterprise. How you end up with one or the other The good and bad in each approach: The common problem is a long path from trigger event to enterprise outcome. ERM as a ‘top level’ risk management process is incomplete. Centralised ERM is ok, but has big problems. Decentralised risk management processes need an enterprise view created. Creating the enterprise view Decentralised but standardised risk management processes are not a solution. The bottom line: decentralised is smart, but there are conditions to meet.

Risk specialists

Version 2.0 Beta

What is Enterprise Risk Management (ERM)?

The goal of risk management for an enterprise is to:

Achieve understanding of all risks for which the enterprise has responsibility.
Gain reasonable assurance that all of those risks are within the applicable risk appetite.

Those goals come from ISO 31000. Enterprise risk management demands the complete coverage of enterprise risk to support all levels of decision making, especially at the top level.

For that complete coverage, risk management must include an enterprise-wide view of the uncertainty of achieving enterprise objectives. Those uncertain objectives must include all the objectives that will matter to the enterprise. The objectives that matter to the enterprise are wider than the core mission and profit concerns that get published in corporate mission statements. Those core objectives take up most time in the boardroom and attract performance bonuses. Many other objectives look important only when they are not met. For example, avoiding deaths by electrocution is always part of success, regardless of the corporate mission and priorities. Maintaining investor confidence is also critical to everyone, over and above the financial measures of success. Rarely are bonuses tied directly to electrocution or investor confidence.

That is one reason why specialists and lower level managers are important to enterprise risk.

On the other hand, ‘risk’ management is often thought to apply only to incidental possibilities like electrocution, ignoring the uncertainty around the organisation’s core objectives and reasons for existence. In ERM, that is a fundamental mistake. (For more authoritative opinions on this theme, check out Norman Marks. Tim Leech advocates Objective-Centric Risk Management. If I understand Carol Williams correctly, COSO is implicated in the fundamental mistake in a way that ISO 31000 is not.)

The Clear Lines equate an objective with a preferred outcome. That preferred outcome is a statement that will be clearly true or not true at a definable future time. Many others take an ‘objective’ to mean something much less precise, perhaps a single word like ‘financial’ or ‘safety’, loosely indicating a general dimension of success. In the Clear Lines, single words like that indicate categories of objective, and they are not objectives in themselves.

There are a few alternative approaches to ERM. This article breaks them up into four types:

ERM as an enterprise-level risk management process
Centralised ERM
De-centralised risk management processes throughout the enterprise
De-centralised but standardised risk management processes through the enterprise.

There are many other ways to break down approaches to ERM. Sometimes ERM is partitioned into ‘strategic, business, and operational’ risk management, which is vague but evocative. It also parallels the risk ‘perspectives’ identified in PRINCE2. It may indicate some form of decentralising. The three-way partition of strategic, business, and operational risk was the origin of this Clear Lines view on de-centralising risk management, though it isn’t quite the same thing.

What is a ‘risk management process’?

A risk management ‘process’ is defined in ISO 31000:2018, Clause 6. A risk management ‘process’ is separate from the risk management ‘framework’, which is described in Clause 5 of ISO 31000:2018. A risk management process is self-contained. It has a defined scope for the risks to be considered, risk criteria (such as scales for likelihood and consequence), and a risk register. The end of the process will be an understanding of risk within the scope, and decisions about risk treatments.

A risk process is not an abstracted method, as might be defined in a procedure document. It is the actual execution of risk management, for a specific range of enterprise activities or risks. The first executed step will have been establishing scope and context. The process will produce artefacts such as a risk register and a list of risk treatments. There will have been no risk management process without them.

The Australian implementation guide to ISO 31000, HB 436, recognises the possibility of separate risk processes within one enterprise, for instance at 5.3.4.2:

It is less likely that risks will be overlooked and the process will prove more practicable if whatever is being examined is considered logically in smaller parts…if the risks associated with an organization as a whole are to be considered, this could be done by looking at either each organizational unit or each location separately.

There can be a risk management process for the enterprise as a whole. One of those is normally assumed for ERM. The Clear Lines recommend one.

Centralised and de-centralised approaches

ERM as an enterprise-level risk management process

Enterprise risk management requires that risks for the whole enterprise are understood, assessed, and treated. That can be done as one risk management process, executed by the C-suite or board of directors. That much is clearly legitimate.

It is often further understood that ‘enterprise risk management’ is in place if that C-suite or boardroom risk process is maintained.

But is that enough?

A huge amount of risk, and management, are both missing from that picture. A single top-level risk management process does not inform decisions taken at lower levels of the organisation. Every part and layer of the enterprise has its own risk drivers, and all of those drivers are ignored. The ‘enterprise’ risk process is also likely to exclude the managers who make those decisions. So while you could argue that the top-level risk process, by itself, is your version of ERM, it does not give effect to the principles in ISO 31000 (Clause 4).

Centralised ERM

ERM is most often understood to mean a single integrated and centralised risk management process for the enterprise. There is one enterprise risk register. There is one set of scales to represent risk criteria.

All managers involved in risk management contribute to this central risk management process. Typically, each manager’s contribution is made up of risk definitions added to the enterprise risk register, with ratings for those risks. That enterprise risk register includes all known risks identified by all managers, or at least all those accepted as relevant to enterprise objectives.

Centralised Enterprise Risk Management, shown as a typical organisation chart with a separate big box called Enterprise Risk Management. All boxes in the organisation chart have a direct input (arrow) to the Enterprise Risk Management box.
In the organisation structure chart, actual positions and organisation units are shown in blue on the left. Part-time and functional structures made up from the same individuals, like boards and project teams, are shown in green on the right. ERM requires input from every part of the enterprise structure.

There are no surprises so far. You have heard all that over and over.

De-centralised risk management processes throughout the enterprise

There is another world view that is also boringly familiar. Yet the other familiar world view contradicts the familiar idea of ERM, and leads to a competing idea, a hierarchical network of de-centralised risk management processes. That hierarchy of risk management processes looks a lot like the management hierarchy, with extra places for decision-making committees and boards, and for specialised ‘risk themes’.

In that competing world view, every manager is responsible for managing risks. Each one of them is responsible for managing those risks that are within their span of control. That means each one of those managers maintains a separate risk register. Very often, each one will maintain a complete stand-alone risk management process, each one with special-purpose scales and criteria.

In this world, there is a separate risk management process and a separate risk register for each work unit and level within the enterprise. There will be a separate risk register and process for each PRINCE2 project, project programme, and change portfolio (with an ‘e’ on ‘programme’).

There is also a separate risk process for the enterprise as a whole. That one, on its own, may pass for ‘enterprise’ risk management. That separate risk process for the whole enterprise may, or may not, not recognise all the risks identified by levels of management below the C-suite.

De-centralised risk management, shown as a typical organisation chart with a small risk management box within each position and function in the organisation chart.
Each separate risk management process is shown as a pink box, just as there was a large pink box for the centralised ERM process. Thematic risk assessment processes are typically the property of a board or specialty function, of the kind shown in green on the right side of the structure chart.

The hierarchy of risk processes is one way to partition risk into ‘strategic, business, and operational’ layers. The enterprise risk management process is equated with ‘strategic’ risk management. Each line executive has a ‘business’ risk management process for their area of control. The work units at lower levels have ‘operational’ risks. I don’t call those equations theoretically pure, but they are too not far wrong.

Beyond those manager-based risk processes, there are further separate risk processes for specific themes with special risk management drivers. Themes with special drivers often include safety, security, investment, business continuity, or fraud risk. It is also possible to have a separate risk management process for a product or ‘system’, or for a defined business process, or even for the intersection of a business process with a theme. A product safety assessment is such an intersection.

Examples of de-centralised risk management processes

De-centralised risk management in the Australian Government

De-centralised but standardised risk management processes through the enterprise

Another idea is to de-centralise the risk management effort into separate strands of activity, while standardising all of that activity across the enterprise. The enterprise standards cover risk register formats and risk rating scales, called risk criteria in ISO 31000. The standards mean that all the risk records can be held in a common database, even if that database contains hundreds of risk registers, and each register is maintained by a different manager somewhere across the enterprise.

All of that is nicely convenient to administrators and to systems people. For the risk team, it demonstrates tangible progress in ‘enterprise risk management’. It looks like standardisation and integration. It breaks down barriers and silos. It can look like centralisation, or like de-centralisation, depending on which part of the picture is drawn biggest.

The work of the central risk team may be limited to maintaining the system and the standards, which looks simple and affordable, compared to the costly nightmare of ‘managing all risk’.

There is also an implied promise of comparability between risk ratings across assessments done by different managers. The system might even have an automatic way to add up risk across the enterprise. That would be fantastic, right?

I actually conclude that standardisation is not a legitimate solution at all. There is nothing wrong with the central database as such. The central database will be almost essential if risk management is centralised while everyone is expected to participate. The central database is not necessary for successful de-centralised risk management.

How you end up with one or the other

You might end up with only an enterprise-level risk process if your enterprise sees ‘risk’ as part of governance and board activity, and not as part of the management culture or of the bureaucratic regime. Some entrepreneurial leaders might think ‘risk’ is critically important, but only for those special people who lead, not for worker bees.

A centralised risk management process is natural in smaller organisations with a single purpose. It is also attractive to system vendors, and to risk specialists looking for work. For a large organisation with centralised risk management, a corporate system is essential, and a lot of centralised specialty work is involved.

De-centralised risk management processes arise from a belief that risk is part of management. That belief can be based on a genuine understanding of management responsibility, and of risk as the effects of uncertainty on objectives. It can also be based on bureaucratic requirements for certain documents to exist, whether or not they have any effect on what happens in the real world. Bureaucratic requirements may demand an annual business plan, or a project plan, in each case supported by a risk assessment.

It is normal to have separate risk processes for safety, security, investments, and so on. The law gets involved in those risks. The law rarely cares about enterprise risk as a whole.

The risk processes for those themes may pre-date all other ‘risk management’. They did not wait for the enterprise boardroom to decide any corporate risk policy. Very likely, a regulator spoke first and still has the last word. For those themes, the separate risk register is maintained by a specialist team, on behalf of the whole enterprise.

In large organisations, separate de-centralised risk assessments won’t go away any time soon. There are hundreds of them within agencies of the Australian Government. Some of those are positively required by central Government policy.

Even ERM purists typically start from multiple stand-alone risk management processes distributed across the enterprise. Those de-centralised processes are an asset rather than a liability. Those de-centralised processes may be inconsistent and disconnected. To the ERM enthusiast, the inconsistency and the disconnection are the problems to be solved. The ERM enthusiast’s challenge is to standardise and integrate, or so it seems.

Standardising the de-centralised risk management processes is a natural extension of the bureaucratic instinct, and it promises real ‘enterprise risk management’, once everything is standardised and integrated—and regulated—by the central risk team, who will need a corporate system to make that possible. It is a huge and lucrative target for system vendors, and for risk bureaucrats.

The good and bad in each approach

The common problem: a long path from trigger event to enterprise outcome.

There is one key problem that affects every approach to enterprise risk management. That problem is the long and uncertain path from an unplanned event to a difference in enterprise outcomes. Consider these unplanned events, which are already generalised across a range of triggers and causes to bring them closer to ‘consequences’:

A key person leaves an important functional team (OR a key piece of equipment becomes unusable).
A cyberattack [via attack path X] results in exfiltration of the main customer files, but no-one realises what’s happened until 6-24 months after the attack. (Exfiltration: Reading internal organisation data and copying it outside of the organisation, without permission.)
A construction site accident resulting in one worker’s permanent disability.

When coupled to a further consequence, each of these events is part of a real risk that would be identified at some level of an enterprise. But equally, the consequential effect on total enterprise objectives is unpredictable, and may be unknowable for the management level identifying the risk. Viewed from a high enough level, any of these events could end up as a net positive for the enterprise, even though none of them are desirable in themselves.

The long-path problem is not solved by any approach or methods. The burden of dealing with long paths lands mostly on contributing (lower-level) managers, and on risk specialists. It will be up to them to work out the enterprise consequences of upstream events like people and equipment not working, cyberattacks, or worker injuries.

The different approaches to enterprise risk management contain different responses to this long-path problem. The implied response to the long-path problem is unlikely to be the reason why one approach is chosen over another, and yet it matters.

ERM as a ‘top level’ risk management process: incomplete.

If your idea of enterprise risk management is a single risk management process conducted in a boardroom, you respond to the long-path problem by ignoring identifiable risks that don’t have an obvious effect on boardroom outcomes and decisions. The ‘enterprise’ risk register contains only risks with clearly explained links to ‘enterprise’ objectives. On that basis a risk event like a key person leaves an important functional team is not likely to be registered at all. Someone might worry a lot about that possibility, but boardroom ‘risk management’ is not necessarily reconciled with actual and realistic worries.

The detailed knowledge developed in lower-level work units is not used for ‘risk management’. At the same time, ‘enterprise risk management’ is not offered to the lower-level managers for decision-making. On that basis alone, you might reasonably conclude that the ISO 31000 principles are violated.

Usually there will be some recognition that lesser events and disruptions can affect the enterprise. Those lower-level risks are not completely discounted. Instead, they might be summarised into very broad risk descriptions that could cover many types of trigger events. Each described risk might be subject to many different controls. For example, the risk event a key person leaves an important functional team might be recognised as one possibility within an ‘enterprise’ level risk event, perhaps along the lines of one of our key functional areas does not meet a critical target. The enterprise version leaves out specific triggers or causes within the functional area.

When risk descriptions are so broad, the full range of triggers and controls are not known to any one manager, even at the highest organisational level. Likelihood and consequence ratings for such risks are dubious at best, and may show emotional signals more than clear thinking or facts.

Centralised ERM: ok, but…

The challenges of the centralised approach to risk management are about including and motivating all managers at all levels. They all have to be included if the central risk register is to be ‘complete’.

Including all managers and all risks could take some time, particularly if a central risk team has to be involved in assessing every risk. To that extent, the fully centralised approach builds delays into understanding and acting on risk across the enterprise.

The centralised assessment of risks does not by itself solve the problem of long, uncertain causal paths between identified risks and enterprise objectives. The long-path problem is encountered within the analysis and assessment of each and every identified risk. Lower-level and specialised managers will struggle with understanding those long causal paths. The risk team and higher-level managers can help with understanding causal paths. Success may depend on how well they can help.

One method that helps is the ‘reasonable worst case’. The reasonable worst case is the worst plausible enterprise consequence(s) arising from a given risk description. Less severe consequences may be more likely. However, it is a reasonable strategy to analyse only the worst case, adjusting the likelihood rating to match the likelihood of that worst case following. While the resulting analysis won’t tell the whole story, it will give a reasonable guide to decision-making, pending more experience of events and clearer insight into the consequence chain.

Decentralised risk management processes need an enterprise view created.

De-centralised risk management arises naturally from the idea that risk management is part of management, and plays a role in all decisions. As management decisions are de-centralised, so are the risk management processes that inform those decisions.

The obvious benefit is that all managers are directly involved in managing risk. The risks they manage are necessarily important to their decisions and to their success.

The obvious problem is that when all the risks are in different registers, and all the risks are rated on different scales, you have no integrated view of all enterprise risk. Very often, the different risk scales will represent very different priorities and objectives, even if the words and colour-codes look similar. They may even represent conflicting priorities and objectives. Such tendencies might be called ‘stove-piping’: a part of the organisation pursuing its own goals, without sharing an enterprise goal.

If you interact with your enterprise IT division or legal team, but aren’t inside it, you know exactly what I’m talking about. If you tend to talk about ‘the business’ as though your own team isn’t ‘the business’, you may be part of the problem.

The risks in the de-centralised registers may all be rated, but those ratings will not represent effects on enterprise objectives. At best, the ratings will represent effects on the particular objectives of the department or thematic specialty that created the register. Very probably, many of those registers will use consequence (impact) scales wholly disconnected from any defined objectives. Free-floating scales of abstract ‘badness’ marked out by vague adjectives are still common, and widely promoted.

Here’s an example of a disconnected consequence scale from Sobel & Reding (2012), Figure 5.5. This is certainly not the worst example you will see. Other scales are much more vague than this one. My main concern with it is that the consequences are not linked with any defined organisation objectives.

Impact category	Impact level
	Insignificant	Minor	Moderate	Major	Catastrophic
Financial	< $1m	$1m-$10m	$10m-$50m	> $50m	> $1b
Reputation	No noticeable impact.	Modest damage that requires some expenditure of resources to remediate.	Damage that makes it challenging to achieve at least one objective in the short term.	Significant damage that makes it difficult to achieve one or more business objectives.	Irreparable damage that threatens the organisation’s viability.
Safety	Minor injuries that result in no lost time.	Physical harm that may cause short-term absence from the workplace.	Physical harm that may cause extended absence from the workplace.	Life threatening injuries to employees, visitors, or innocent people in the community.	Fatality(ies) of employees, visitors, or innocent people in the community.
…	…	…	…	…	…

The words in the cells are taken verbatim from Sobel & Reding. Please be kind to Sobel & Reding by understanding that this table is an example, which does not claim to be fit for real-world application.

Even if each of the separate risk assessments are fit for their local or specialised purpose, you still have the problem of how to recognise the implications of each assessment at the enterprise level, or at intermediate management levels. There is also a question about whose job it is to do that.

Creating the enterprise view

There are reasonable solutions to these problems. My preferred solution is that each manager in the hierarchy recognises the implications of all lower-level risk assessments, while assessing their own risks in their own way. The risk management process at each level works in its own terms.

Decentralised risk management with enterprise integration through the structure hierarchy. Shown as a typical organisation chart with a small risk management box within each unit and function. There are arrows from each risk management box to a risk management box at a higher level in the structure, reaching an apex at the CEO and Executive Committee.
As before, each pink box is a separate and self-contained risk management process. The arrows show where the implications of one risk assessment are recognised in another risk assessment. Risk processes can be built in any order, and cross-recognition may not be immediate.

Exactly how that works isn’t often spelled out, so I have spelled it out in the next article, Integrating de-centralised risk management for enterprise risk management. For this article, the key point is that upper management levels become responsible for linking each lower-level risk with higher-level objectives. The long path problem remains, but it is assigned to the appropriate senior manager to solve, and there is a defined and plausible way for each senior manager to solve it.

My preferred solution does not involve standardising risk criteria between levels, nor standardising across the organisation. There is no stage in which risks are compared across different registers, counted, or added up across the enterprise. There is no need to pretend that risks are numerical quantities.

For ERM, all risks need to be understood in terms of effects on enterprise objectives. The enterprise view is essential to enterprise risk management, if not for deciding individual risk treatments. The enterprise view is needed for ERM whether all risks are in a central register, or if there are many de-centralised risk registers with some form of integration or roll-up.

A conventional approach to the enterprise view is that every risk is rated according to the likelihood and magnitude of defined effects on enterprise objectives, regardless of where that risk is identified and described. That approach leads to a centralised risk register, or to standard rating scales for de-centralised risk registers.

In my alternative approach, each possible deviation from a lower-level objective is recognised as a risk within a higher-level risk management process. The two risk processes at different organisation levels use different rating criteria, and that doesn’t matter. Each one tells the truth from its own point of view.

You may feel uncomfortable with relying on management effort, at levels all the way up and down the hierarchy. Relying on the management hierarchy is both a weakness and a strength.

Lack of senior management support is often the breakdown of risk management. They have limited time to spend on it, and they tend to be non-committal about corporate programs, such as ‘enterprise risk management’. Corporate programs often resemble fads that can fail and fade with no regrets. Rightly or wrongly, ‘risk management’ can be just such a fad.

Relying on senior managers is also a strength, relative to pushing out ERM without them. Not a lot will ever be achieved without senior management support, regardless of the ‘approach’. If the CEO actually cares about the effects of uncertainty on objectives (that is, risk), the management hierarchy will follow, and can make it all happen. They will need minimal help from the corporate risk team, and they will succeed best with minimal obstruction from that corporate risk team.

If the CEO doesn’t really care that much, you might question why anyone else should care. Including you. Risk management will continue in areas where there is a respected reason for it, and it will achieve nothing elsewhere—regardless of methods and frameworks.

De-centralised but standardised risk management processes: not a solution.

Standardisation usually involves a standard scale for rating risks. Most often it means three scales, one for likelihood, one for consequence (impact) and one for ‘level of risk’. ‘Level of risk’ us usually a scalar value looked up from likelihood and consequence levels, in a so-called risk matrix, which looks something like this:

	Consequence
	1. In- significant	2. Minor	3. Moderate	4. Major	5. Cata- strophic
A (almost certain)	High	High	Extreme	Extreme	Extreme
B (likely)	Medium	High	High	Extreme	Extreme
C (moderate)	Low	Medium	High	Extreme	Extreme
D (unlikely)	Low	Low	Medium	High	Extreme
E (rare)	Low	Low	Medium	High	High

Of these, the important scale is the scale for consequences.

The consequence scale may represent:

effects on enterprise objectives, or
effects on local or specialist objectives, which vary widely.

Alternatively, and very commonly:

The consequence scale may not represent effects on any defined objectives. Consequences are just assumed to be good or bad in varying degrees, within a few loose categories.

Creating a consequence scale disconnected from any objectives is easy to do, and there are many models around. They often have consequence ‘types’ such as ‘financial’, ‘reputation’, and ‘safety’, without any regard to enterprise-specific goals for the future financial position, reputation, or safety record.

‘Finances’ may seem ‘important’ to everyone, one way or another. And so they are. But ‘finance’ means very different things to different managers with different functions. A good financial result for one is not comparable with a good financial result for another, and not everyone knows what distinguishes a good financial result from a financial disappointment or a financial failure. Just saying ‘finances’ does not create a common consequence measure. That is especially true for within smaller work units, which may not see success in financial terms. Nor does everyone understand how unit financial outcomes weigh against other dimensions of unit success. Simply defining or rating consequences as ‘financial’ avoids the essential link between risk and the real objectives of the activity. But risk is the effect of uncertainty on objectives.

You can read much, much more about the meaning of ‘consequences’ and the construction of consequence scales, in a series of four long blog posts, some with drill-down pages.

The problems resulting from standardised risk management are different for each of the three interpretations of ‘consequence’. In no interpretation is standardisation a solution to the problems of either centralised or de-centralised risk management. The universal problem of a long causal path from individual risk to enterprise objectives is barely touched by ‘standardisation’, and might even be made worse.

If the standard consequence scale represents the effects on enterprise objectives…

Lower-level and specialist managers will have difficulty rating the effects of their identified risks on enterprise objectives, using the standard scale. They may not even understand the scale. If they do understand it, they will not be in a good position to predict the enterprise effect of each of ‘their’ risks. To those managers, the causal links will be long and unpredictable.

This ‘long path’ problem is common to any approach to ERM, and standardisation only makes it worse.

The net result will be that the ratings by lower-level and specialist managers will not be reliable for higher-level decision making, well-intentioned as everyone might have been. Someone will have to do further analysis and moderation if the distributed risk assessments are to be used by anyone other than the managers directly responsible for each one. All of that might work, with a lot of effort from central experts. The effort involved is also probably at odds with the reasons for ‘de-centralising’ and ‘standardising’ in the first place. By ‘de-centralising’ the organisation very likely wants to minimise the central support effort.

If the standard consequence scale represents the effects on local or specialised objectives…

All the risk assessments will have a similar look and feel. They will not be truly standardised. Risks with the same rating in different assessments will not be comparable, because they refer to different objectives with differing enterprise significance. The situation is practically the same as for distributed and non-standardised risk management processes.

If the standard consequence scale does not represent effects on objectives…

My first question is whether there is any risk management happening at all. Risk is the effect of uncertainty on objectives (ISO 31000). After a moment, I suggest that the answer is yes, there is potentially risk management, because some good risk decisions can be made even if concepts from ISO 31000 are completely ignored.

At the same time, the lack of grounded, tangible meaning in the consequence scale will mean that there is very little consistency or comparability across the ‘standardised’ risk management processes. The situation is effectively the same as for distributed and non-standardised risk management processes. At best, someone will have to do further analysis and moderation. And contributing managers will not have had the benefit of relating ‘risks’ to their own objectives.

The bottom line: de-centralised is smart, but first…

Having only an enterprise-level risk management process, without involving the supporting management hierarchy, is not ERM. It is much better than not having an enterprise-level risk management process.

A single centralised risk management process can deliver enterprise risk management if there is effective central support and genuine participation from (all) senior management levels. If central supports create a bottleneck, all management of risk across the enterprise can be delayed.

De-centralised risk management processes without connecting links can include effective risk management, but it will not lead to enterprise risk management.

De-centralised risk management with standardisation is at best equivalent to a single centralised risk management process, but that is unlikely. The ‘de-centralised’ approach probably means that the central support is limited, and that will limit the effectiveness of the whole program.

De-centralised risk management with effective links, instead of standardisation, can have a lot of advantages. If the links are created through the management structure itself:

Risk management is part of management: every manager is also a hands-on risk manager.
Each risk management process is owned by, and meaningful to, the manager responsible for it. That manager has a definite reason to manage risk in that process: assuring their own objectives, for which they are accountable.
Management of real-world risk need not wait for a risk management ‘program’, anywhere. Any manager can make a risk-based decision even if there are no risk assessments at higher or lower organisation levels.
You don’t need a centralised database of risks.
Thematic or other risk management processes established separately, for their own purposes or for regulatory purposes, can live on within an enterprise hierarchy of risk processes. They can continue to meet their special stakeholder needs while adding to the enterprise view of risk.
Links between decentralised risk management processes are created by managers at intermediate levels, between the ground-level managers of risk and the C-suite. They don’t need to be experts on ‘risk management’. They only need to know their own business, and to have a reason to care.

But first, there must be a top-down demand for assurance about the achievement of objectives. The CEO must really want assurance that enterprise objectives will be achieved, with an explainable level of confidence. The CEO must demand evidence that all sources of uncertainty have been considered. That demand is what energises and steers the whole process.

That demand drives upper level management to demand risk management at all lower levels, and to make the connections between low-level risks and enterprise outcomes.

Without that demand, effective enterprise risk management cannot follow from the de-centralised approach. It is also doubtful that enterprise risk management would be effective through any other approach.

Reference

Sobel, Paul and Reding, Kurt (2012) Enterprise risk management: achieving and sustaining success. Altamonte Springs, Florida: Institute of Internal Auditors Research Foundation (IIARF). This book is a major source for the CRMA Study Guide, available from the same IIARF bookstore.

➜

Next article for Specialists

Integrating de-centralised risk management for enterprise risk management

Every part of an enterprise has objectives What every risk assessment must do Zoom in on one link What the pencil does From pencil to position Extending across the enterprise Thematic risk assessments Projects, Programmes, Portfolio Covering for missing risk assessments Some possible pain points Why you integrate rather than centralise