If colleagues see risk management as a form to complete, start with a decision they need to make. Show how clearer assumptions, control evidence and consequences can change the action, then use the register to record that reasoning.
Risk management looks like paperwork when all anyone sees is the form. It stops looking like paperwork the moment someone watches the reasoning happen: a genuine disagreement about how a control might fail, resolved by actually working through the mechanism rather than by rating boxes on a matrix. The fix isn't a better register template. It's showing the thinking, not just the output.
Start with what a clear risk statement actually forces you to do
Most registers are full of risk statements like "IT security risk" or "risk of non-compliance." These aren't risks — they're topics. A topic doesn't tell you what could happen, why, or what it would cost, so nobody can meaningfully disagree with it, and nothing that vague can be prioritised against anything else.
A clear risk statement has three parts: a cause, an event, and a consequence. Something like: because remote access is not restricted by device (cause), an attacker could gain access to the finance system using stolen credentials (event), resulting in fraudulent payment instructions being issued (consequence). Written this way, a colleague who thought risk management was paperwork can immediately see something worth arguing about — is device restriction actually the main gap here, or is it multi-factor authentication? That argument is risk management. The rating that follows is just recording the conclusion.
This is usually the fastest way to change a sceptical colleague's mind: don't defend the register, rewrite one entry from a vague topic into a proper cause-event-consequence statement in front of them, and let them see how much more it actually says.
Use bow-tie thinking to show the mechanism, not just the rating
A bow-tie diagram puts the risk event in the centre, with causes and their preventive controls on the left, and consequences and their mitigating controls on the right. You don't need to draw a formal diagram to use the thinking. The useful move is asking two questions out loud about any risk: what has to go wrong, in sequence, for this event to actually happen — and if it does happen, what stands between the event and the worst-case consequence.
This reframes risk management from a scoring exercise into a mechanical one. Instead of arguing whether a risk is a 3 or a 4 on a five-point scale, you're asking whether the preventive control on the left of the bow-tie would actually stop the sequence, or whether it just looks like it would on paper. That's a question with a real answer, and it's usually the question that reveals whether a control is real or decorative.
Test controls with a question, not an inspection
A control that's documented is not the same as a control that works, and the gap between the two is usually where risk management earns its credibility with sceptics. Rather than confirming a control exists, ask what would happen if you tried to defeat it right now. Could someone tailgate through that access-controlled door carrying a box. Would the backup actually restore, or has anyone only ever confirmed the job completed. Does the approval workflow actually stop a payment, or does it just log who clicked approve.
These aren't audit questions in the compliance sense — they're mechanism questions, and they tend to be the moment a sceptical colleague stops seeing risk management as a form-filling exercise and starts seeing it as a way of finding out something they didn't already know.
Worked example: reframing a register entry
Here's the difference in practice, using a fictional entry from a mid-size logistics firm's IT risk register.
| Element | Before | After |
|---|---|---|
| Risk statement | "Cybersecurity risk to operations" | "Because the freight scheduling system accepts remote logins without multi-factor authentication, an attacker using a phished password could access and alter delivery schedules, causing missed deliveries and contractual penalties." |
| Control | "Access controls in place" | "Password-only login; no MFA. Last tested: never. Preventive control does not currently stop the sequence." |
| Discussion generated | None — the entry is unfalsifiable | Whether MFA rollout should be prioritised ahead of two other IT projects this quarter |
The "before" version is technically compliant with having a risk register. The "after" version is the actual work, and it's the version that produces a decision rather than just a rating.
Risk management is not paperwork — but the perception is partly earned
It's worth being honest with yourself before you try to change anyone else's mind: the paperwork perception usually exists for a reason. Registers get built once under audit pressure, filled with vague statements because nobody had time to work through the mechanism properly, and then never revisited except to update a rating that was never tested to begin with. A colleague who has only ever seen that version of risk management isn't being unreasonable. They're describing what they've actually experienced.
That means the fix has to be a demonstration, not an argument. Telling a sceptical colleague that risk management is a valuable discipline changes nothing — they've heard that claim before, usually right before being handed a form. Showing them, on one real entry that affects something they care about, the difference between a topic and a proper cause-event-consequence statement, and then asking whether the listed control would actually survive someone trying to defeat it, does more in ten minutes than a slide deck on the value of enterprise risk management ever will. People who think risk management is paperwork have usually only ever been shown the paperwork. Show them the thinking instead, once, on something concrete, and the objection tends to answer itself.
Common mistakes when trying to make the case
Leading with the framework instead of the reasoning. Naming ISO 31000 or a maturity model to a sceptical colleague before showing them one worked example just confirms their view that this is theory, not practice.
Defending the existing register instead of rewriting an entry. Arguing that the process is sound is far less persuasive than demonstrating it on a real example in five minutes.
Treating every risk with the same depth of analysis. Not every risk needs bow-tie thinking or a lengthy control test — reserve the depth for risks that matter, or you'll reinforce the paperwork perception by making everything feel equally laborious.
Rating without testing. A control rated as "effective" because it exists, not because anyone checked it functions, is the single biggest reason experienced staff distrust risk registers.
Not connecting the risk back to something the colleague already cares about. An abstract risk statement lands poorly. One tied to a deadline, a customer commitment, or a system the colleague personally relies on lands immediately.
Take this further
A Guide to the Risk Management Body of Knowledge covers the foundational principles behind this way of thinking and how the components interconnect, including clear risk statements, bow-tie analysis, and the control-testing questions above, with lessons drawn from major incidents. If you're building the case with AI-assisted drafting, Thirty ChatGPT Prompts for Security Risk Practitioners has prompts specifically for turning vague risk topics into proper statements, and Anonymising a Prompt Without Destroying the Answer is worth reading before you paste anything sensitive into a public tool while doing it. For a concrete application of this thinking to a specific risk type, Ten Questions That Reveal Whether You Have an Insider Threat Problem works through the same cause-event-consequence approach.