Organisations do not struggle to imagine bad things. They struggle to decide which bad things deserve leadership attention.
Every workshop can generate a hundred possible problems, but only a handful belong in the risk register. The rest might still matter, but they do not all deserve the same visibility, ownership, or reporting.
If you skip that discipline, the register turns into a wish list, a vulnerability dump, or an audit scrapbook.
Start after the basics are clear
Before you identify risks, get your language straight. I like to anchor this work on business objectives, assets, threats, vulnerabilities, controls, and impacts. If that framing is fuzzy, start with Threats, Risks, and Controls.
This matters because people often confuse risk identification with issue collection. A missing patch is not automatically a top risk. A weak onboarding process is not automatically a top risk. A single audit finding is not automatically a top risk.
The question is always the same: what could happen here that would genuinely hurt the business?
The categories are just prompts
I usually start a workshop with broad categories to get the conversation moving:
- reputational
- operational
- financial
- legal and regulatory
- strategic
- information security and privacy
- cyber security
- environmental
- supply chain
Those buckets are useful because they stop the room fixating on one topic, usually cyber.
But they are only prompts. The outcome I want is not a list of categories. I want a shortlist of real business risks written in plain language.
For example:
- A contamination event stops the business from trading for weeks.
- A payment-system compromise drains cash and stalls operations.
- A privacy breach triggers complaints, regulator attention, and customer churn.
Those are risks.
"Cyber" is not a risk.
"Compliance" is not a risk.
Those are domains.
Use the right people
This part fails when the room is wrong.
If you ask only the IT team to identify enterprise risk, you will get an IT-flavoured register. Useful, but incomplete. Operations will see things security misses. Finance will see different dependencies. Product and customer teams will surface impacts that never appear in technical workshops.
I like a whiteboard session here because it forces people to argue in the open. Good. That friction is useful.
The goal is not total agreement on day one. The goal is a shared view of what deserves closer analysis.
A simple example: the ice cream truck
Say Jessie runs a small ice cream business.
The truck matters. Food safety matters. Cash flow matters. The payment system matters. The customer mailing list matters a bit. The social media account matters more than Jessie expected.
Now run the categories quickly:
- Operational: a contamination event shuts the business down for days or weeks
- Financial: a banking or payment incident drains working capital
- Regulatory: a failed inspection suspends the licence
- Reputational: customers stop showing up after a visible hygiene failure
- Cyber security: compromise of the payment flow or business email disrupts trading
- Privacy: customer contact data is exposed or misused
That does not mean Jessie needs six board-level risks. It means Jessie now has enough material to decide what belongs in the register.
In a small business, I would probably track a short list and keep the rest under observation. That's the point. Identification is about narrowing, not collecting.
What I actually want at the end
By the end of a good identification session, I want:
- a shortlist of high-level risks
- a rough sense of their impact
- enough context to assign owners
- clear candidates for deeper assessment
Then the harder work begins: validating likelihood, understanding existing controls, and deciding treatment. That sits in Risk Management.
If the discussion starts drifting into confidentiality, integrity, and availability, that can be useful too, but keep it anchored to the business. Confidentiality, Integrity, and Availability is a useful lens, not a substitute for a risk workshop.
If your team keeps blending privacy, cyber security, and information security into one vague blob, Information Security vs. Cyber Security vs. Privacy is the right reset.
What usually goes wrong
The common failure modes are boringly consistent.
Teams identify twenty risks and own none of them.
They write category labels instead of scenarios.
They keep risks because somebody worked hard on the slide deck.
They mix privacy, cyber security, and information security into one vague blob and wonder why nothing gets prioritised.
Cut harder.
The register is supposed to help leadership focus. If it reads like everything matters equally, it is not doing its job.
Start broad. Narrow fast. Then go deeper where the impact is real. That is the work.