I've sat in too many risk workshops where smart people spend an hour arguing about the words instead of the problem. One person says "threat", another says "risk", and someone else jumps straight to controls. By the time the whiteboard is full, nobody can tell what actually matters to the business.
This is the simple model I keep coming back to.
That sounds obvious. It rarely stays obvious once the meeting starts.
Start with what the business is trying to protect
Before I look at attackers, controls, or matrices, I want three things on the table:
- the business objective
- the part of the business in scope
- the people, processes, and technology involved
If that sounds basic, good. Most bad risk conversations skip it.
If you're assessing a payment flow, say that. If you're assessing a customer portal, say that. "We are reviewing cyber risk for the company" is usually too vague to be useful.
If you need a quick refresher on the building blocks, People, Process and Technology is still the simplest way to frame the environment.
The chain I actually map
From there, I walk through the chain in this order:
- Valuable assets: what would hurt if it were lost, changed, exposed, or unavailable?
- Adverse impact: what would the damage look like in practice? Lost revenue? Service outage? Regulatory breach? Safety issue?
- Threat source: who or what could cause the problem?
- Threat event: what actually happens?
- Vulnerability: what weakness makes that event possible?
- Control: what already exists to deter, prevent, detect, contain, or recover?
- Action: what needs to change?
That order matters. If you start with controls, you tend to defend what already exists. If you start with assets and impact, the conversation gets sharper very quickly.
A small example helps.
Say you run an online service that depends on a single cloud-hosted database.
- Asset: customer data and the service itself
- Impact: customers cannot use the service, support volume spikes, revenue drops, trust takes a hit
- Threat source: malicious actor, administrator error, cloud outage
- Threat event: ransomware, destructive change, accidental deletion, regional outage
- Vulnerability: weak access control, poor backups, single-region design, over-privileged admin account
- Control: MFA, database backups, change approval, logging, restore testing
- Action: reduce admin access, test restores, add resilience, tighten change paths
Now you have something you can work with. Not a cloud of words. A scenario.
Don't confuse categories with understanding
Frameworks help. I use them. But they are prompts, not answers.
You can use high-level risk categories. You can use threat libraries. You can use attacker behaviour frameworks when you need more detail. Fine. Just don't mistake the taxonomy for the assessment.
I've seen organisations with gorgeous risk registers and no shared understanding of what any entry means.
That's why I like to separate the posts in this series:
- Threats for thinking clearly about threat sources and events
- Risk Identification for deciding what deserves a place in the register
- Risk Management for turning that register into ownership, treatment, and follow-through
And if the line between information security, cyber security, and privacy keeps getting muddled in your organisation, read Information Security vs. Cyber Security vs. Privacy. That confusion shows up in risk workshops constantly.
What usually goes wrong
The mistakes are repetitive.
Teams write risks as control failures, not business impacts.
They list "lack of MFA" or "unsupported software" as the risk. Those are weaknesses. The risk is what happens because of them.
Or they mix several risks into one sentence so broad that nobody owns it.
Or they build a register around audit findings rather than around the business.
That last one is common. And lazy.
A risk register is not a dumping ground for security observations. It is a decision tool for leadership.
What good looks like
A good risk statement is specific enough that a reasonable person can answer four questions:
- What are we trying to protect?
- What could happen?
- Why could it happen here?
- Why should leadership care?
If you can answer those clearly, you're in good shape.
If not, stop polishing the spreadsheet and go back to the scenario.
Start small
You do not need a perfect model to begin.
Pick one service, one business process, or one important objective. Walk the chain. Write down the scenario. Test whether people outside security can understand it. Then expand.
That is much better than inventing fifty abstract risks nobody will revisit.
Risk work gets overcomplicated because people want precision too early. I get it. But at the start, clarity beats sophistication.
Get the words right, then get the priorities right. The rest follows.
If your register starts with controls and ends with no owner, you're not managing risk. You're cataloguing anxiety.