I've seen risk programmes fail in two opposite ways. The first is chaos: no structure, no owner, no follow-through. The second is worse: beautiful templates, polished matrices, regular committee packs, and almost no change in the real world.
Most organisations do not need a bigger risk process. They need a usable one.
That is the difference that matters.
Start with context, not spreadsheets
Before you score anything, be clear on the scope. What are we looking at: the whole organisation, a business unit, a customer-facing service, a supplier relationship? What matters here: revenue, safety, privacy, uptime, regulatory exposure, strategic delivery? And who needs to be in the room?
If that context is vague, the rest will wobble. I usually anchor this on the same simple model described in Threats, Risks, and Controls.
The sequence I actually use
I keep the flow simple.
1. Identify the inherent risks
First, identify what could go wrong before giving too much credit to the existing controls.
This is where Risk Identification does the heavy lifting. You are trying to understand the real exposure, not prove that your current programme is excellent.
2. Assess impact and likelihood
Now estimate how bad each scenario would be and how plausible it is.
This does not have to be mathematically elegant. It has to be consistent enough that the organisation can compare risks and make decisions.
Risk scoring is more art than science. That is fine.
3. Review what already exists
Only now do I want to hear about controls.
What is in place to deter, prevent, detect, contain, or recover? Is it actually working? Is there evidence? Has it been tested, or is it just written down somewhere nobody opens?
This is the step where a lot of optimistic scoring falls apart.
4. Re-rate the current position
Once you understand the controls, reassess the risk.
Some risks will stay high because the control environment is weak.
Some will drop because the mitigations are genuinely effective.
Some will look fine on paper until you realise the detective control only alerts after the damage is done.
That is why I like to distinguish between inherent risk and current risk. It stops the room pretending the first score never existed.
5. Decide the treatment
Then make a decision.
- accept
- reduce
- transfer
- avoid
Not every risk gets the same answer. And that is okay.
What matters is that the decision is explicit, owned, and tied to business context.
6. Track the actions and review them
This is where most programmes lose momentum.
A treatment plan needs owners, dates, and evidence. Otherwise it turns into a polite fiction.
I want to know:
- who is accountable
- what will change
- by when
- how we will know it worked
- when we will review it again
The documents matter less than the behaviour
Yes, you will probably end up with a risk register.
Yes, you may also have a treatment plan, control assessment notes, or committee papers.
Fine. But the paperwork is not the goal.
The goal is that the right people understand the exposure, make a decision, fund the treatment where needed, and come back to check whether the position improved.
That is risk management. Everything else is support material.
The failure modes are predictable
The same things go wrong over and over.
- Risks stay open for months with no real owner.
- Treatments are written as aspirations, not actions.
- Control effectiveness is assumed, not tested.
- Reviews become status theatre.
- The register grows, but prioritisation gets worse.
If any of that sounds familiar, trim the process. Get closer to the business. Make the scenarios clearer. Force ownership.
Useful frameworks and guidance
If you want external reference points, start with ISO 31000:2018 - Risk management — Guidelines. It is still the cleanest general-purpose foundation for principles, framework, and process.
If AI systems are in scope, add the NIST AI Risk Management Framework and ISO/IEC 42001:2023. They are more specialised, but useful when the risk conversation needs to cover governance, trustworthiness, and management-system discipline for AI.
For Australian context, I would also point people to the Governance Institute of Australia's Effective Cyber Risk Management: A best practice governance guide and ASIC's Cyber resilience good practices. Both are practical, board-relevant, and closer to how many local organisations actually need to run the conversation.
Keep it moving
Risk management is not a once-a-year exercise.
The business changes. Systems change. Suppliers change. Regulations change. The controls that looked good last year may be brittle now.
So review the position regularly. Before acquisitions. Before major changes. Before new services go live. After incidents. After people with too much access leave.
Also keep looking out for external factors impacting you: regulatory changes, new threats, worsening economy, etc.
But keep it practical: A good risk process should help leadership act faster, not slower.
If your programme creates more paperwork than decisions, it is overdue for surgery.