If your risk register records concerns but does not change decisions, connect each risk to an objective, credible causes, consequences and controls. The Risk Management Body of Knowledge (RMBOK) provides practical ways to organise that reasoning.
What is RMBOK? A method, not a standard
RMBOK — the Risk Management Body of Knowledge — is a practitioner's method for doing the work that ISO 31000 describes at a principle level. ISO 31000:2018 sets out what a risk management framework should contain and the attributes of a good process; it is deliberately generic, because it has to work for a bank, a mine site and a school. RMBOK sits underneath that. It is the set of techniques — writing risk statements, building bow-ties, testing controls, running assessments — that turn "identify, analyse, evaluate, treat" into something a room full of operational people can actually do in a workshop.
If you already run a risk process built around ISO 31000 or a sector framework, RMBOK is not a competing system. It is closer to a toolbox for the parts ISO 31000 leaves to your judgement: exactly how you word a risk, how you decide a control is real, and how you connect a single point of failure to the consequence a board cares about.
The risk statement is the unit of work
Everything else in RMBOK depends on getting one sentence right: the risk statement. A usable risk statement has three parts — a cause, a risk event, and a consequence — and it should be specific enough that different readers understand the scenario and can examine suitable controls.
Compare these two:
- Weak: "Risk of cyber attack on operational systems."
- Better: "Failure to segregate the corporate network from the SCADA network could allow malware introduced via a phishing email to reach process control systems, resulting in unplanned disruption to the treatment process."
The first is a category, not a risk. Nobody can test a control against it because it does not say what fails, how, or into what. The second tells you where to look for the control (network segregation), what would defeat it (a phishing-delivered payload crossing an unsegregated boundary) and what the organisation actually cares about (the treatment process, not the network itself). Rewriting broad categories into specific cause–event–consequence statements is a useful starting point for a register review.
Bow-tie analysis: connecting cause to consequence
Once you have a risk statement with a real cause and a real consequence, bow-tie analysis is the tool for showing everything that sits between them. On the left side of the "knot" you list the causes that could trigger the event; on the right, the consequences that could follow; and on both sides, the controls — preventive controls stopping a cause reaching the event, and mitigating controls limiting the consequence once it has.
Worked example. Take a fictional mid-size water utility, Coastal Water Authority, with the risk statement above. A simplified bow-tie for that risk might look like this:
| Side | Element |
|---|---|
| Cause | Contractor remote access credentials not disabled after contract end |
| Preventive control | Quarterly access review against active contracts |
| Top event | Unsegregated network path exploited to reach SCADA |
| Mitigating control | Network intrusion detection on the SCADA boundary |
| Consequence | Unplanned disruption to the treatment process |
The value of laying it out this way is that it forces a separate answer for each control: what stops the cause, and separately, what limits the damage if it happens anyway. A register that only lists "firewall" as the control for a segregation risk usually collapses the moment you ask which side of the bow-tie it is actually on.
Testing whether a control is real
A documented control is not the same as a working one. For example: a policy says access is reviewed quarterly, the control register says "in place," and nobody has actually run the review in three cycles. RMBOK's approach to this is to test each control against three questions before you rely on it in an assessment:
- Is it designed to address this specific cause or consequence — not risk in general, but this one?
- Is there evidence it operated as intended in the last assessment period — a log, a sign-off, a ticket, not a policy statement?
- What single change would defeat it — a leaver not offboarded, a rule disabled "temporarily," a default password left on a test account?
If you cannot answer question two with evidence, treat the control as absent for the purpose of your assessment, even though it is documented. That is an uncomfortable thing to put in front of a control owner, but it is the difference between an assessment that predicts an incident and one that only reflects the policy manual.
What incident reviews teach you about this method
Post-incident reviews of major security and safety failures tend to show the same shape: a documented control that had quietly stopped operating, a single point of failure that sat outside anyone's stated risk statement, and a consequence more severe than anyone had modelled because the bow-tie stopped at the first-order effect. Reading incident reports with a bow-tie in mind — where was the barrier that should have stopped this, and why didn't testing catch that it wasn't working — is a more useful habit than reading them for the headline cause. The headline cause is almost never the only barrier that failed; it is usually the last one standing after several quieter failures upstream.
Common mistakes
- Writing risk statements as categories. "Cyber risk," "reputational risk" and "supply chain risk" are headings for a workshop agenda, not risk statements you can treat.
- Listing a control without saying which side of the bow-tie it is on. A control that prevents a cause and a control that limits a consequence need different owners and different test questions.
- Treating "documented" as "tested." A policy is evidence of intent. A log, a sample check or an audit finding is evidence of operation. Registers routinely conflate the two.
- Stopping the bow-tie at the first consequence. Real incidents cascade. If your assessment stops at "system outage" and never asks what that outage causes downstream, you have under-scoped the risk.
- Running the whole process as a compliance exercise. ISO 31000 asks for a process; it does not hand you a method that produces defensible statements and testable controls. That part is on you, which is exactly what RMBOK is trying to standardise.
Where to go from here
A Guide to the Risk Management Body of Knowledge walks through these foundational principles in more depth, including how the components interconnect, clear risk statements, bow-tie analysis and control-testing questions you can take into a workshop, and lessons drawn from major incidents. It is free to download. If you are building or rebuilding a risk process rather than just tidying a register, it is worth reading alongside A Fully Worked Information Classification Example (Free) and Risk Treatment Schedule Template (Free), and if part of your risk surface now includes staff pasting information into AI tools, Is It Safe to Paste This Into ChatGPT? A Thirty-Second Test applies the same cause-and-consequence thinking to that specific problem.