What every de-centralised risk assessment must do
Every part of an enterprise has objectives
Every productive activity has objectives. Enterprises are full of productive activities. One activity is a component of another. Even the smallest activity has objectives.
In ISO 31000, and here in this article, risk is the effect of uncertainty on objectives. ISO 31000 clarifies the ‘effect’, as a deviation from the objective. The deviation may be positive or negative. It also spells out that objectives exist at different levels. [ISO 31000:2018, 3.1]
An objective is best understood as a descriptive statement about reality that will be true or untrue at a specified future time. You want it to become true. Objectives are often less precisely defined than that, but for this article, please take ‘objective’ to mean just that, including the time element. There are always objectives to minimise costs and harm, as well as to achieve the primary purpose and mission.
If you have a better idea for an ‘objective’, hit the reply box and let everyone know what it is.
What every risk assessment must do
Every risk assessment identifies ways in which there might be a deviation from objectives. (Blog post Risk is the uncertainty of outcomes)
Each of those ways is called a risk. A risk is usually represented by a record in a risk register. Registers are not essential to risk management, but for illustration I assume that there is a risk register in every risk management process, to contain information about risks. The information itself is essential, even if the register is not.
Every risk includes a ‘consequence’. That consequence is the deviation from an objective that would be caused if reality matched the risk description. If there is no resulting deviation from objectives, there is no risk.
So far, this idea of consequence is conventional.
Now accept that the consequential deviation is an absolute outcome difference in the future, when the objective has not been achieved as planned. The consequential deviation is the extent of non-achievement of the objective, at a point in time. Such clear measurement of consequence is less conventional, and often muddied by the ‘impact’ metaphor and a short-term focus for ‘consequence’. An ‘impact’ is instantaneous, but consequences can be forever. At the least, consequences mean that the world is different on at least one future date.
| If you think my interpretation of ‘consequence’ is not the best possible, please jump into the reply box and explain your better alternative. I questioned the interpretation of consequence in blog posts, but regrettably, no-one disputed my answers. You can be the first. You can also see a how-to guide for middle management, covering this stage of consequence definition in depth (in the drill-down pages). |
There are usually multiple risks that would lead to the same level of deviation from the same objective. If there are slight differences in the amount of deviation expected, you can define deviation ranges as classes, so that all risks with a similar consequence are said to belong to the same consequence class. Consequences are automatically classified according to the particular objective from which the deviation occurs.
Every risk also has a likelihood. The likelihood is properly understood as the likelihood of the identified future deviation from the objective (the consequence) having been caused by a real-world event matching the risk description. It is a common mistake to rate the likelihood of a risk event without considering that the risk event can have a range of different consequences, each with a lower likelihood of actually following.
Having classified consequences by deviation range, and having assessed a likelihood for each risk leading to its consequence, you can add up the likelihoods for all risks leading to the same consequence class. You then have the overall likelihood of that range of deviation from a particular objective, from any cause. If that overall likelihood seems wrong, you can use your doubts to explore what might be missing or excessive within your individual risks.
This likelihood-adding step is not standard within risk management. The reason why it is not usual is that most risk assessments do not define consequences in terms of deviations from defined objectives at a specific future date. In some common practices, consequences are understood as ‘impacts’ with only a vague link to any objectives. The objectives themselves may not even be known within the risk management process. These common practices are not aligned with ISO 31000.
The integration solution that follows requires that all the contributing risk assessments show a meaningful likelihood for each level of deviation from each defined objective. Not all risk assessments set out to do that, but if they fully implement the ISO 31000 principles, they will give you what you need.
| All of that may be a lot to ask. Please reply if you think it’s impossible. The rewards from meeting these conditions are considerable. They follow in the next section Watch the pencil, which shows you exactly how to integrate one risk assessment into another. |
Watch the pencil
Zoom in on one link
First, let’s look at just two levels within an enterprise, and only one link between levels. The Cyber Infrastructure Team reports to the Chief Information Security Officer (CISO) as the responsible line executive. The CISO is also the line executive for a number of other Teams.
The CISO is responsible for assessing all security risk for the enterprise, on behalf of the CEO and Executive Committee.
Risk management is also undertaken separately in each Team, including the Cyber Infrastructure Team. Suppose the Cyber Infrastructure Team has a usefully complete team-level risk assessment while the CISO is developing or updating the enterprise-level security risk assessment.
The Cyber Infrastructure Team has its own objectives. Its own assessment of team-level risk reveals a likelihood of reaching each of those objectives, and the likelihood of a deviation from each objective in a meaningful range of levels.
The Cyber Infrastructure Team is responsible for applying security patches to network firewalls. Firewalls usually have vulnerabilities that need to be patched before hackers exploit them. New vulnerabilities are discovered from time to time, resulting in new patches.
One of the Team’s objectives this year is that all security patches will have been tested and applied to firewalls within times required by the corporate ICT security policy. This is not an enterprise objective, nor even an enterprise security objective for the CISO. It’s a security strategy. But it is an objective for the Cyber Infrastructure Team.
There are at least two possible deviations from this objective. In a mild deviation, there will have been occasional delays to testing and application of firewall security patches, for understandable reasons. In a serious deviation, representing failure, firewalls will have been left out of date (and therefore possibly wide open to cyberattack) for extended periods.
There are many possible ways in which either the mild deviation or the serious deviation will occur over the year. Each one of the ways has a likelihood of resulting in its deviation. For illustration, let’s imagine that the overall likelihood of the mild deviation at the end of the year is 30%; and that the overall likelihood of the serious failure deviation is 2%.
The link is made while the enterprise risk assessment is being developed.
To make the link between the Cyber Infrastructure Team risk assessment and the enterprise risk assessment, the CISO first looks at the objectives for the Cyber Infrastructure Team. If the Team’s objectives are legitimate for enterprise security, achieving them will be important to enterprise security objectives, though perhaps not to an all-or-nothing extent. The enterprise could get lucky in ways that offset any deviations from Cyber Infrastructure Team objectives. It might also be unlucky in ways that wipe out any commendable successes in the Team.
In this way the objectives of the Cyber Infrastructure Team are aligned with enterprise objectives. If there had been no causal relationship between achievement of the Team’s objectives and enterprise security objectives, then the Cyber Infrastructure Team would have been working to the wrong objectives. The Team would also have assessed risk to the wrong objectives.
The CISO then looks at the Cyber Infrastructure Team’s risk assessment. The CISO looks particularly at the potential deviations from each of the Team’s objectives, ready with the right question, and ready with a pencil.
What the pencil does
For each potential Cyber Infrastructure Team deviation, the CISO asks What would that deviation mean for enterprise objectives? The answer can never be ‘nothing’, because the Team’s objectives are aligned with enterprise objectives.
So the CISO first pencils that Team deviation into the enterprise security risk register, as a risk description.
There were two deviations in the example. Both related to the Cyber Infrastructure Team’s current-year objective that all security patches will have been tested and applied to firewalls within times required by the corporate ICT security policy.
With a mild deviation from that objective, there will have been occasional delays to testing and application of security patches, for understandable reasons. The overall likelihood of that deviation was totalled to 30%.
One of the CISO’s objectives is to have no cyber security failures that would compromise investor or customer trust. That’s an objective for the strategic planning period, which is understood to run to 2025.
So the CISO pencils into the enterprise security risk register, as a risk description: There will have been occasional delays to testing and application of firewall security patches, for understandable reasons. The CISO’s pencilled note will also say exactly where this risk came from, the Cyber Infrastructure Team risk assessment.
Alongside the risk description, the CISO can also pencil some initial answers to the question What would that deviation mean for enterprise objectives? These answers are the beginnings of the consequence side of the enterprise security risk assessment.
In the firewall patching example, the CISO might note some thoughts like Yes, this vulnerability could lead to a damaging attack. But not necessarily, in either case. The answers do not come from the Cyber Infrastructure Team risk assessment, but useful answers can be obtained from other parts of the CISO’s well-funded empire.
Lastly, the CISO’s pencil notes the overall likelihood of the particular deviation in the Cyber Infrastructure Team. That likelihood might be a first guess at a likelihood for the newly registered risk for the enterprise. That guess cannot be the final likelihood for the enterprise security risk analysis, because the consequential effects on enterprise security objectives are themselves uncertain, even if the Cyber Infrastructure Team definitely deviates from success.
For firewall patching, the CISO notes the assessed likelihood of 30% for the mild deviation there will have been occasional delays to testing and application of security patches, for understandable reasons. The CISO also doubts the usefulness of that figure, given the list of unanswered questions pencilled into the consequence column of the enterprise security risk register. The CISO further notes that this likelihood applied to just the current year, which does not match the strategic life of the enterprise security risk assessment to 2025.
The CISO repeats this process for each potential deviation from the Cyber Infrastructure Team’s objectives. There is one new risk in the enterprise security risk register for each different deviation from objectives in the Team’s risk assessment. The CISO does not repeat each individual risk in the Team-level risk register, because for each potential Team deviation, there were multiple risks in the Team’s register. The enterprise security risk register grows, but only by one risk per Departmental deviation, not by one risk per Departmental risk.
So in the example, the CISO would proceed to the second Cyber Infrastructure Team deviation, firewalls will have been left out of date (and therefore possibly wide open to cyberattack) for extended periods (during the current year).
From pencil to position
Each of the pencilled risks then goes through a review and development process at CISO level, to become formal entries in the enterprise risk register. The Cyber Infrastructure Team may be involved as an expert adviser, but not all the answers can come from within that Team.
During review and development, the wording of the risk description might be translated from the language of the Team’s deviation into the language of enterprise security and strategy.
- The CISO might assess a higher or lower likelihood for the Cyber Infrastructure Team’s deviation, based on information not available within that Team.
- The potential effects of the Team deviation on enterprise objectives will be assessed critically, taking into account other cyber security controls and the assumed capabilities of attackers. These are factors outside the Cyber Infrastructure Team.
- There may not be a single definite enterprise security consequence from the Team deviation from its firewall-patching objective. There may be multiple possible effects, each with a different likelihood, conditional on the Team deviation happening at all.
- The CISO might even see that the Team deviation looks similar to deviations possible in other security Teams, and combine all of those possibilities into a single risk description in the enterprise security risk register.
The Cyber Infrastructure Team view of risk and the enterprise security view of risk will inform and challenge each other. With constructive discussion of differences, both will be better, even as they remain different. They are permanently different, because of the different objectives at each level.
Through all of that, the CISO will continue to validate the enterprise security risk analysis by reference to the conclusions of the Cyber Infrastructure Team’s risk assessment. The enterprise security risk documentation trail and source references will lead back to that Team risk assessment. In the other direction, the Team will be obliged to inform the CISO when its own risk assessment changes.
The Cyber Infrastructure Team’s risk assessment was recognised and integrated into enterprise security risk management. The Team’s risk assessment was not re-done, not over-ruled, nor made to use a different risk scale. Scales didn’t even come into the story.
Including all de-centralised risk management
Extending across the enterprise
The integration method can extend to the other Teams reporting to the CISO when each of their Team risk assessments have been done.
At that point, there will be a fully informed enterprise security risk assessment – setting aside any risks that no-one knows about.
The method can also extend vertically if there are more than two levels in the enterprise. Extending the cyber security example upward, the CISO’s enterprise security risk assessment can inform the top-level enterprise risk assessment.
A key point here is that the integration effort is itself de-centralised. It’s the CISO who integrates the Team-level risk assessments into the enterprise security risk assessment, not the CEO or a central risk unit. The CEO and Executive Committee never see Team-level risk assessments, and have no need to see them. This feature helps to spread the integration work. It also gets that integration work done by the one person who is in the best position to understand the links between Team risks and higher-level risks: the higher-level manager, in this case the CISO. The higher-level manager also has the best reason to care about what happens when the Teams deviate from their objectives.
Thematic risk assessments
A lot of productive risk management is done within thematic specialties such as cyber security risk or health and safety risk. Thematic risk assessments generally run enterprise-wide, cutting across departmental and work unit boundaries. The enterprise security risk assessment was an example. At the same time, thematic risk assessments can save line work unit managers the effort of dealing with risks within those thematic specialties that have their own risk management. This saving is usual, and sometimes essential, for themes like cyber security or health and safety.
Examples of de-centralised risk management processes
De-centralised risk management in the Australian Government
Within the enterprise hierarchy of risk assessments, thematic risk assessments (like enterprise security) generally sit one level below the enterprise risk assessment. The enterprise risk assessment recognises the enterprise implications of each of the thematic risk assessments, along with layer of line work unit risk assessments. The integration task will fall to the C‑level executive responsible for the theme (such as the Chief Information Security Officer), or to the top-level corporate committee that oversees the theme (such as an enterprise Health and Safety Committee), as representatives of the CEO or Executive Committee.
It is also possible to have thematic risk assessments at multiple levels. For instance, there might be separate health and safety risk assessments for each site, recognised by and integrated into one enterprise-level health and safety risk assessment. Both could be separate from any work unit or project risk assessments.
Projects, Programmes, Portfolio
Projects also have a hierarchical structure, conventionally called Portfolio, Programme, and Project. It is normal project governance practice to maintain risk assessments for the Portfolio, for each Programme, and for each Project. In the enterprise hierarchy of risk assessments, the Portfolio risk assessment will sit one level below the enterprise risk assessment. The Programme risk assessments will sit below that, and the Project risk assessments will sit below each Programme risk assessment.
It is also normal for each level of project governance to take into account risks identified at lower levels, one way or another. The integration method spelled out here for ERM can be used within the project hierarchy just as well.
Covering for missing risk assessments
Back in the two-level example, the Cyber Infrastructure Team did not wait for the CISO to ‘finish’ the enterprise security risk assessment before starting its own. Neither need the CISO wait for the Cyber Infrastructure Team. In the absence of a useable Cyber Infrastructure Team risk assessment, the CISO can populate the enterprise security risk register with independent best estimates about the possible variations in Cyber Infrastructure Team outcomes: by nature, likelihood, and consequence for enterprise security objectives. It is not even necessary that the Cyber Infrastructure Team’s objectives be first agreed or formally written down. The CISO can start from what is already known about the Team’s purposes, activities, and methods.
When the Cyber Infrastructure Team ‘completes’ its Team-level risk assessment, the results can be compared with the earlier enterprise risk register entries relating to that Team. They will not miraculously agree. There is no need to decide that one version is correct and the other is not. Instead, the reasons for disagreement should be explored. Working through those disagreements will be highly productive, far beyond tweaking some risk ratings.
The fact that missing risk assessments can be tolerated means that no layer of risk management need wait for the completion of any other. No risk assessment and no risk decision are ever stuck waiting for someone else.
What ‘risk management’ must be
The Clear Lines now zoom out to the understanding of ‘enterprise risk management’ that makes the integration method possible.
Some possible pain points
It is not enough to have a pencil. It is not even enough to believe in enterprise risk management.
For de-centralised risk management to work as enterprise risk management, the risk management effort must be driven by demand for the best enterprise outcomes with the optimal mixture of assurance and potential. There must be an understanding that risk management and assurance are all about enterprise success, and that enterprise success is not assured—and may never happen—without an understanding of the effects of uncertainty on enterprise objectives. Risk.
The original demand can come from the board or the CEO. That demand must flow down through each management level. Some driving demand can also come from regulators or other external stakeholders. In that case the ‘risk management’ may work well for those interests, but not for others.
The really important element is that the enterprise understands ‘risk management’ to be about improving and assuring outcomes, so that the worthwhile chances are taken and the unworthy avoided. ‘Risk management’ must not be just a code for something else, be that ‘best practice’, ‘compliance’, ‘sustainability’, or putting un-trusted managers and partners on a short leash. It is not just about avoiding surprises while ‘business as usual’ continues, unquestioned. Risk management must never be about maintaining the register, or worse, using a ‘risk matrix’ consistently. It must be about the uncertainty of success and failure.
For effective integration of de-centralised risk assessments, there must be willingness to discuss objectives and potential deviations, within and across enterprise levels. These are not always comfortable subjects for discussion, and there are many cultural influences that will vary across enterprises.
The stiff conditions for each separate risk assessment included these:
- Every risk management process must understand the objectives at risk.
- Objectives are statements about reality that you want to be true at a defined future date.
- Deviations from objectives are differences between reality and the objective statement, at that future date.
- Consequences are the deviations that follow from a risk event.
- Each registered risk will lead to one deviation or another, so it you can total the likelihoods for all risks leading to one defined deviation. The total of those risk likelihoods is the overall likelihood of that deviation.
You may still find these starting conditions unrealistic, or just wrong. If that’s where the trouble started for you, you may want to reply to them.
Why you integrate rather than centralise
All enterprise risk management suffers from the long and uncertain path between a local event and the effect on enterprise objectives. In de-centralised risk management with enterprise integration, the long-path problem is broken down into a series of short-path problems. There is one short-path problem for each layer of risk assessment. Each short-path problem is solved by the person with the most capability and motivation to do that.
De-centralised but integrated risk management also means that:
- Each manager can understand and act on risk without waiting for anyone else to ‘finish’ their risk assessment. No-one relies on any central risk team, so that central team cannot be a bottleneck. Each manager can choose to manage their own risks brilliantly, even while there is no risk management ‘program’ in operation.
- There is no need to impose standardised scales or registers. There is no need for a central risk database. A flexible corporate database might be convenient, but management of risk does not wait for the database.
- All risk registers are of manageable length, and meaningful to their owners.
The fundamental reason to de-centralise risk management is to recognise risk in every decision throughout the enterprise. ISO 31000:2018 Clause 4, Principle 2 (Integrated): Risk management is an integral part of all organizational activities. If you take that seriously, and decisions and activities are de-centralised, risk management must also be de-centralised.
Previous article for Specialists
Main article on De-centralised risk management
Comments are moderated from a sea of spam, so may not be published immediately. Email contact may get a quicker response.