Making Sense of the ISO 31000 Risk Management Process

ISO 31000 provides one of the most widely recognised frameworks for managing risk. Its risk management process is conceptually sound, deliberately generic and applicable to almost any organisation, industry or type of risk.

But there is a problem. For people encountering ISO 31000 for the first time — and sometimes even for people who have been using it for years — the process diagram can be harder to interpret than it needs to be.

I've written about it before, and you can find the original ISO 31000 process diagram in figure 1 in this article if you're not familiar with it.

The individual activities are straightforward enough. Establish the scope and criteria. Identify risks. Analyse them. Evaluate them. Treat them. Communicate, consult, monitor, review, record and report.

What is less obvious is what is happening to the risk as we move through that process.

That distinction matters.

A risk assessment is not simply a sequence of boxes to complete. We start with an operating environment containing uncertainty and exposure. We identify and understand the risks within it. We examine what controls already exist. We establish where those risks currently stand. We decide whether that position is acceptable. Where necessary, we modify it. We then determine what risk remains.

The diagram accompanying this article is my attempt to make that logic more explicit.

It is not intended to replace the ISO 31000 process. Nor is it intended to suggest that ISO 31000 is wrong. Rather, it is an interpretation and practical representation of the process designed to make it easier to understand, explain and apply.

In particular, it distinguishes between things we do and states of risk that we observe.

That seemingly small distinction makes the whole process considerably easier to understand.

Start with the context

Risk does not exist in a vacuum.

Before we can sensibly identify or assess a risk, we need to understand the environment in which that risk exists.

That includes such things as:

• the objectives we are trying to achieve;

• the internal and external environment;

• stakeholders and their expectations;

• legal, regulatory and contractual obligations;

• assets, activities, systems and processes;

• dependencies and interfaces;

• assumptions and constraints;

• threats, hazards and opportunities;

• existing capabilities and vulnerabilities; and

• the organisation’s appetite and criteria for risk.

Collectively, these form the context within which risk exists.

This is why I have drawn context as an open boundary around the process rather than another box in the sequence.

Context isn’t really something that happens between Tuesday morning and Wednesday afternoon before we move on to risk identification. It is the environment within which the entire risk management process operates.

And that leads to the first of the three risk states represented in the diagram: inherent risk.

Inherent risk: the risk embedded in the context

The term inherent risk attracts more debate than it probably deserves. This is probably the only contentious part of my interpretation of it, but for me the context is the inherent risk. It's critical to understand it because if the context changes, then your existing controls may or may not be effective.

Some practitioners argue that there is no meaningful such thing as inherent risk because risk cannot realistically be separated from the controls, systems and circumstances in which it exists. Others dislike attempts to calculate a hypothetical “risk without controls”, particularly where removing those controls would fundamentally change the activity being assessed.

Those are legitimate cautions.

Nevertheless, I think the concept remains extremely useful.

When I use inherent risk here, I mean the risk inherent in undertaking an activity, pursuing an objective or operating within a particular environment before considering the effect of the controls we rely upon to modify that risk.

Risk is a conceptual state, not necessarily an independently observable one.

Now, that doesn't mean that we don't document it. There is some activity in documenting it, but we're actually only documenting what we've identified. In the diagram above, current risk is only established as an understood metric once we've identified and then assessed it. That's just documenting the previous two steps. The next step, evaluating it, is where we get into more action.

Consider commercial aviation.

Flying a large aircraft containing hundreds of people at high speed and altitude contains substantial inherent risk. Modern aviation is extraordinarily safe not because the underlying hazards disappeared, but because layers of engineering, training, regulation, maintenance, air traffic management, procedures and other controls modify that risk.

Or consider cybersecurity.

Connecting critical systems to networks creates inherent exposure to malicious activity, error, disruption and compromise. Authentication, segmentation, encryption, monitoring, patching and incident response do not eliminate the underlying sources of risk. They modify the likelihood and consequences.

The concept therefore gives us a useful starting point:

What is it about this objective, activity or environment that creates risk in the first place?

We don’t necessarily need to calculate a precise inherent-risk score. In many cases, doing so creates spurious precision. But understanding the underlying exposure helps us understand why controls exist, what they are supposed to achieve and how important they may be.

That is why the diagram places context and inherent risk around the entire process.

Everything that follows happens inside that environment.

The process itself: five actions and two risk states

One of the most important changes in my representation is deceptively simple.

The central sequence contains seven elements, but only five of them are actions:

Scope and criteria → Identify → Assess → Current risk → Evaluate → Treat → Residual risk

Current risk and residual risk are deliberately shown differently because they aren’t activities.

• Nobody “does” current risk.

• Nobody “performs” residual risk.

They are states of risk that we establish and understand as a consequence of the activities around them.

Once you see the process that way, the sequence becomes much more intuitive.

1. Scope and criteria — decide what we are actually assessing

Before identifying risks, we need to know what the assessment is about.

That sounds obvious, but poor scoping is one of the most common causes of poor risk assessments.

• What objective are we considering?

• What decision is the assessment intended to support?

• What organisational, geographic, technical or temporal boundaries apply?

• Who owns the activity and its risks?

• Which stakeholders need to be involved?

• What assumptions are we making?

And crucially, against what criteria will we eventually decide whether a risk is acceptable?

This last point matters because risk evaluation only makes sense if we know what we are evaluating the risk against.

If we wait until after assessing a risk to decide what constitutes “high”, “unacceptable” or “tolerable”, we create an obvious opportunity for hindsight and bias.

Scope and criteria therefore establish the rules of the game before we start playing it.

2. Identify — work out what could happen

Risk identification asks us to find and describe the uncertainties that matter.

Depending on the nature of the assessment, this might involve identifying:

• sources of risk;

• threats and hazards;

• events and scenarios;

• vulnerabilities;

• opportunities;

• causes;

• consequences;

• affected objectives;

• dependencies; and

• emerging or changing conditions.

Good risk identification goes beyond producing a list of unfortunate things that might happen.

A useful risk description tells us something about the source, event and consequence, and links them to the objectives that matter.

The purpose is not to create the world’s longest risk register.

It is to develop a sufficiently complete picture of uncertainty to support good decisions.

3. Assess — understand the risk and the controls

Once risks have been identified, we need to understand them.

This is where likelihood, consequence, uncertainty and existing controls enter the picture.

• What could cause the event?

• How likely is it?

• What would happen if it occurred?

• How severe might those consequences be?

• What controls already exist?

• How effective are they?

• How confident are we in our assumptions and evidence?

The assessment process takes us from understanding the underlying exposure to understanding the risk as it actually stands today.

And that produces our next risk state.

4. Current risk — where are we now?

I deliberately use the term current risk here.

Current risk is the level and nature of risk given the controls and circumstances that actually exist now.

It is a state, not an activity.

This distinction is important because it separates two questions that are frequently muddled together:

What is the risk?

and

What should we do about it?

Those are not the same question.

1. Assessment establishes our current position. (Think of it as being like a balance sheet in a financial statement - a snapshot in time).

2. Evaluation determines what that position means. (Loosely, this is equivalent to the profit and loss, which means: how is our trajectory changing or likely to change over time?)
   

Keeping those ideas separate helps prevent one of the most common risk-management errors: deciding in advance that something “needs treatment” and then reverse-engineering the assessment to justify the desired answer.

Current risk is therefore the output of assessment and the input to evaluation.

5. Evaluate — decide whether the current risk is acceptable

Risk evaluation compares our understanding of current risk against the criteria established at the beginning of the process.

This is the decision point.

• Is the risk acceptable?

• Is it tolerable subject to monitoring?

• Does it require further analysis?

• Does it need treatment?

• Is it sufficiently significant to change the activity or objective altogether?

• How does it compare with other risks competing for attention and resources?

This is also why defining risk criteria at the beginning matters so much. Evaluation should not simply mean looking at a red box on a matrix and declaring that something must be fixed.

It is a decision process informed by objectives, criteria, uncertainty, stakeholder perspectives, costs, benefits, obligations and available options. And sometimes the correct decision is to do nothing further. Risk management is not risk elimination.

6. Treat — modify the risk where worthwhile

Where evaluation determines that further action is appropriate, we move to risk treatment.

Treatment might involve avoiding a source of risk, changing likelihood, changing consequences, introducing or strengthening controls, sharing risk, changing an activity or accepting the risk through an informed decision.

But selecting a treatment is only half the job.

A treatment that exists in a risk register but has never been implemented is not a control. Effective treatment requires ownership, resources, responsibilities, timing and some way of determining whether the treatment actually achieved what was intended.

We should be able to answer:

What change in risk do we expect this treatment to produce, and how will we know whether it worked?

Once the treatment has been implemented and is operating, we arrive at the third risk state.

7. Residual risk — what remains?

Residual risk is what remains after treatment.

Again, this is a state rather than an action.

Treatment does not make risk disappear. It changes it.

Some uncertainty remains. Some controls may fail. Some consequences cannot be completely prevented. New exposures may emerge. Assumptions may prove incorrect.

The important question becomes whether the remaining risk is acceptable in the context of the organisation’s objectives and criteria. And there is another important feature of residual risk that the circular nature of the diagram is intended to show.

Today’s residual risk becomes part of tomorrow’s context.

The process begins again.

A treatment becomes an existing control. The environment changes. Technology changes. Threats change. People change. Objectives change. Controls degrade or improve.

What was once residual risk becomes part of the environment against which the next assessment is conducted.

Risk management is therefore not a journey from left to right with a finish line at the end.

It is a cycle.

The three circles at the centre

The other important feature of the graphic is the three concentric circles:

1. Communicate and consult

2. Record and report

3. Monitor and review

These are embedded throughout it.

I have deliberately nested them because I think their relationship becomes clearer when represented this way.

Communicate and consult

The outer circle represents the continuous two-way exchange of information with stakeholders. Risk management cannot sensibly be performed by an analyst sitting alone with a spreadsheet.

Stakeholders provide information about objectives, operations, threats, controls, assumptions, consequences and priorities. The risk process, in turn, gives information back to those stakeholders. Communication and consultation therefore flow both ways.

We ask questions, receive information, analyse it, develop conclusions, test those conclusions and communicate decisions. That is why the arrows in the diagram are double-headed.

Record and report

Inside communication and consultation sits record and report. I regard this as, in practical terms, a subset of communication. Risk registers, assessment reports, treatment plans, control descriptions, decision records and dashboards create the information base around which meaningful consultation can occur.

You cannot effectively consult on information that was never captured. Nor can an organisation reliably learn from risk decisions if the assumptions, evidence and reasoning behind them disappear when somebody leaves the room.

Recording and reporting provide continuity, accountability and organisational memory.

They also make monitoring possible.

Monitor and review

At the centre sits monitor and review. This is arguably the heartbeat of the entire process. Controls need to be monitored. Assumptions need to be tested. Changes in the internal and external environment need to be detected. Treatments need to be reviewed. Indicators need to be watched. Incidents and near misses need to feed new information back into our understanding of risk.

Monitoring and review therefore feed the record, which feeds communication and consultation, which in turn informs every action in the process. The three aren’t isolated boxes.

They are an information system surrounding and supporting risk-based decision-making.

Why do the arrows only connect to five elements?

There is another small but deliberate detail in the graphic. The double-headed arrows connect the central circles to the five action steps:

1. Scope and criteria.

2. Identify.

3. Assess.

4. Evaluate.

5. Treat.

They don’t connect to current risk or residual risk.

Why?

• Because those are states.

• We communicate and consult while assessing risk.

• We record the results of the assessment.

• We monitor the controls on which that assessment depends.

• But “current risk” itself isn’t an activity with which we communicate.

• It is a condition we understand as a result of those activities.

The same applies to residual risk.

Nor does the diagram need an arrow connecting the circles to context, because everything already exists inside the context. Context is the environment within which communication, assessment, treatment and every other part of the process occurs. This might seem like graphical pedantry. I don’t think it is. Diagrams shape mental models.

If a diagram makes fundamentally different concepts look identical, people tend to treat them as identical. Distinguishing actions, states and context makes the underlying logic much easier to see.

What this representation is trying to achieve

My objective with this diagram is not to invent another risk management methodology.

The world has quite enough of those already. It is to make the ISO 31000 process easier to see.

When someone looks at the diagram, I want them to understand four things almost immediately.

1. First, risk exists within a context.

2. Second, we perform a series of actions to understand and modify it.

3. Third, those actions reveal different states of risk — inherent, current and residual.

4. And fourth, communication, documentation and monitoring occur continuously throughout the process rather than being administrative tasks bolted onto the end.

Put another way, the whole model can be reduced to a fairly simple story:

• Understand the environment and the risk inherent within it.

• Define what you are assessing.

• Identify what could affect your objectives.

• Assess the risk and the controls already in place.

• Understand your current risk.

• Evaluate whether that risk is acceptable.

• Treat it where worthwhile.

• Understand the residual risk.

• Monitor, communicate, record and review throughout.

• Then repeat the process as the context changes.

That, to me, is the practical logic sitting underneath the ISO 31000 risk management process.

A model should help people think, not merely comply

One of the recurring problems in risk management is that processes become compliance exercises.

People complete templates because the procedure tells them to. They populate risk registers because somebody needs a report. They assign likelihood and consequence ratings because there are empty cells waiting to be filled. The process becomes the objective.

It isn’t.

The purpose of risk management is to help people make better decisions in the face of uncertainty.

"Risk management is optimising resources by making better decisions."

A useful process should therefore help people understand what they are doing, why they are doing it and how one activity informs the next. That is what I have tried to achieve with this representation.

It preserves the essential logic of ISO 31000 while making explicit some relationships that I think are easier to understand when shown visually — particularly the distinction between actions and risk states, the role of context, and the transition from inherent through current to residual risk.

You don’t have to agree with every element of my interpretation. Indeed, disagreement about concepts such as inherent risk is healthy if it forces us to be precise about what we mean.

But any useful model should pass a simple test: Does it help someone understand the risk well enough to make a better decision?

If this diagram helps a board member, project manager, security professional, engineer, risk practitioner or student look at the ISO 31000 process and suddenly say, “Ah — now I see how those pieces fit together,” then it has done its job.

And that is ultimately what risk management should be about.