When someone tells me "the threat is hackers", I know the workshop is about to go sideways.
"Hackers" is not a useful threat statement on its own. It is a vague label. It tells me almost nothing about what could happen, what would be affected, or how we should prepare.
To make threat discussions useful, I separate two things.
That distinction sounds small. It cleans up a lot of confusion.
Source first, then event
A threat source can be a person, a group, a supplier, a system failure, or an environmental event.
In practice, I tend to group them like this:
- Adversarial: criminals, malicious insiders, competitors, opportunists
- Accidental: staff mistakes, bad changes, incorrect handling, mis-sent data
- Structural: hardware failure, software defects, design weaknesses, dependency failures
- Environmental: fire, flood, storm, power loss, building access problems
That is already much more useful than saying "cyber threat" and moving on, but it still is not enough.
You also need the event.
- A malicious insider exports customer data.
- An administrator deletes the wrong database.
- A supplier outage takes down authentication.
- A storm knocks out power to the office.
- A ransomware operator encrypts key systems.
Now we are getting somewhere.
Build scenarios, not labels
The point of threat work is not to create a clever taxonomy. The point is to build scenarios that the business can understand.
Take a customer portal.
If I say the threat is "insiders", nobody knows what to do with that.
If I say a privileged employee could misuse access to export a client list, bypass weak monitoring, and trigger contractual, privacy, and reputational fallout, the conversation changes immediately.
That is specific enough to test controls.
That is specific enough to discuss ownership.
That is specific enough to put in front of leadership.
This is why I prefer threat discussions that stay close to business context. Start with what matters, then describe what could realistically happen there. Threats, Risks, and Controls is the broader framing I use for that.
Why teams get this wrong
Most teams do not struggle because they lack frameworks. They struggle because they jump to abstraction too early.
They say:
- cyber attack
- insider threat
- compliance issue
- third-party risk
Fine. But none of those tell you what the event is. A third party could leak data, fail to deliver a service, lose availability, introduce malicious code, mishandle credentials, or disappear mid-project. Those are very different problems.
Same source. Different events. Different controls. Different owners.
The event is where the work starts
Once you have a plausible event, you can ask useful questions.
- What asset would be hit?
- What vulnerability makes this possible?
- What controls should already be stopping this?
- How would we detect it?
- What would the business impact actually look like?
That is the point where risk identification becomes real rather than theoretical. If you have not done that step yet, go to Risk Identification.
And if you are already there, you can use the threat scenarios to support Risk Management by making the register more precise and the treatment plans less fluffy.
A quick test I use
If your threat description could apply equally to every company on earth, it is too vague to help.
If it cannot be tied to a business process, service, team, or dependency, it is too vague to help.
If it does not lead to a conversation about controls, monitoring, ownership, or impact, it is too vague to help.
Threat work should make decisions easier. If all it produces is a longer spreadsheet, something has gone wrong.