What is “Risk”, Really?

Key Takeaways

• No Single Definition: There isn’t a universally accepted meaning of “risk” or “risk management.”
• Plain-English Framing: Replace “risk” with “what might happen” to improve clarity and engagement.
• ISO Clarified: Think of risk as the effect on the likelihood of achieving objectives, not just effects on objectives.
• Decision-Centric: Effective risk management equips decision-makers with timely, useful information—not risk registers or heat maps.
• Success Over Doom: Shift from preventing failure (“doom management”) to improving the chance of achieving objectives (“success management”).

Deep Dive

In this candid and thought-provoking piece, Norman Marks challenges conventional definitions of risk and risk management, arguing that most frameworks fail to resonate with how real-world decisions are made. Drawing from his decades of executive experience and referencing the ideas of Grant Purdy and Roger Estall, Marks reframes “risk” as simply “what might happen”, a practical, plain-English approach that bridges the gap between theory and management reality.

Why Understanding “What Might Happen” Matters More Than Managing Risk Registers

Bear with me for a moment or two, and set aside the standards and frameworks that provide definitions of “risk” and “risk management”.

Why?

As Grant Purdy (the grandfather and, IMHO, the grandmaster of risk management) together with the late Roger Estall proclaimed in the highly-rated Deciding: A guide to even better decision making (2020), there is no commonly-accepted definition of either term. I said the same thing when I wrote the earlier and equally highly-rated book, Risk Management in Plain English: A Guide for Executives: Enabling Success through Intelligent and Informed Risk-Taking (2018).

While I prefer the ISO 31000 definition of risk to anything else that is out there (and I quote it often), it is not clear by just reading it what it means. “Risk is the effect of uncertainty on objectives” may mean something to some (but not all) risk practitioners, but it is generally misunderstood and misused. For a start, what is meant by ‘uncertainty’? It’s not a lack of certainty—you can never be certain. Having more knowledge may not even increase certainty and it doesn’t change whether you will achieve objectives; only actions will do that.

While the ISO definition is intended to include both positive and negative effects, that is not clear when you just read or quote the definition. In addition, it is actually not ‘the effect on objectives’, i.e., a direct effect, as much as it’s the ‘effect on the likelihood of achieving objectives’.

In other words, the ISO definition is not plain English (or any other language commonly spoken in the boardroom). If you want everyone to understand, you should use plain English.

Both Grant and I prefer not to use the word ‘risk’ because, as I put it, it’s a four-letter word. Because standard English (or American) translates ‘risk’ as something bad, managing it is what I refer to as ‘doom management.’ You are managing the possibility of failure.

When you tell a manager that you want to talk about risks, i.e., bad stuff that might happen, he or she is turned off. They want to focus on running the business and making their targets/metrics/goals.

Both Grant and I focus on how organizations achieve success, or what I call ‘success management’. We both advocate using the language of the business instead of the technobabble of the practitioner. We both recognize that success is achieved through what I call informed and intelligent decision-making.

I prefer to talk about ‘what might happen’, which is plain and easily understood in any language.

‘What might happen’ is what could affect the likelihood of achieving objectives. So instead of talking about risk, talk about what might happen. Doing that leads to instant understanding—and credibility—with management.

Let’s Take a Practical Example

As a vice president in the IT function for a major financial services company, one of the functions I was responsible for was disaster recovery planning (DRP) for the loss of one or both of our data centers in the Los Angeles area. While some basic measures were in place, there was no recovery plan. I would not only have to get a plan in place but also hire the individual who would put it together and get it tested.

My objective for the first year was to develop and satisfactorily test a plan for the larger data center. We would develop one for the other data center later.

I could have identified several sources of risk right at the start. But I had many decisions to make, and it was only when I had to make those decisions that all the sources of risk were identified.

First, I had to hire a DRP Coordinator. I needed to decide who I was to hire. The budget I was given and the salary level assigned by HR were obvious constraints.

I had several good candidates on paper. My decision had to consider inter alia:

• Who had the necessary experience and knowledge? There was no certainty that the candidates would live up to their resume and their interview. What was the likelihood that they would excel vs. fail? I had to make an assessment with the help of others who interviewed each candidate. In technobabble, I had to make an assessment for each candidate of the level of related risk.
• Which one would be able to engage effectively with other managers in IT? We needed their engagement, constructive support, and time. In other words, the DRP Coordinator needed strong interpersonal skills as few of these IT managers were incentivized to help. Again, I had to gauge, with the help of others, the likelihood that they would excel or fail.
• Who would be able to work at a reasonable speed to complete the task on time? Again, I had to assess the risk that they would be too slow, as well as the possibility that they would do so well that we would gain continuing support and even start the next plan early.

This was just the first of many decisions along the way to developing the DRP.

Once I hired her, Ann Tritsch and I had to put a project plan in place. Many things could happen that would affect the achievement of (now) our objective, including:

• Senior management might impose unrealistic assumptions about the availability of resources in the event of a disaster. (They did, but I didn’t know that in advance.)
• Some IT managers might not only fail to provide support and information, but might actively resist – refusing to participate, saying they would develop their own (siloed) plan. (One did just that, and several didn’t even show up when it came to our test of the plan.)
• We might get sidetracked by the demand to develop a plan for a network outage. (This also happened when an EVP questioned why we didn’t have one following a serious network outage.)

In order to achieve our objective, ensuring that the likelihood of achieving it was acceptable, we needed to make decisions, and for each one understand what might happen, assess and evaluate each one, and then do something when the result was unacceptable.

None of those would be found in a risk register or on a heat map.

In fact, it would be very hard to put any of them on one of these medieval instruments of ineffective torture because there is a range of effects, from excel to fail. The ‘level of risk’ is a distribution and not a point.

Decisions are what lead to success or failure. If you don’t make good decisions, you will fail. Decisions have to consider what might happen. They need to be informed about what might happen. They need to be made intelligently with a good process (as discussed by Grant). They need to be made in the context of what is to be achieved—the objective or objectives.

So What Should We Mean by Risk?

We should mean those things that might happen that would affect the likelihood of achieving objectives. Which things that might happen do we need to be concerned with? Those that need to be considered in making the decisions necessary for success, achievement of enterprise objectives.

Then what is risk management all about? It should NOT be about managing a list of risks.

Instead, it should be about making sure decision-makers have the information they need about what might happen to make the informed and intelligent decisions necessary for success.

That information has to be tailored to the decision. It needs to be useful to the decision-maker. It may not be useful to other decision-makers.

Let Me Recap

• Risk = what might happen that could affect the likelihood of achieving objectives
• Risk management = making sure decision-makers have the information they need about what might happen to make the informed and intelligent decisions necessary for success

Do I care that they are longer than either ISO or COSO? No, because they are in plain English.

They make sense to leaders on the board, in the executive suite, and running the organization every day.

The GRC Report is your premier destination for the latest in governance, risk, and compliance news. As your reliable source for comprehensive coverage, we ensure you stay informed and ready to navigate the dynamic landscape of GRC. Beyond being a news source, the GRC Report represents a thriving community of professionals who, like you, are dedicated to GRC excellence. Explore our insightful articles and breaking news, and actively participate in the conversation to enhance your GRC journey.