Every organisation already manages risk. Finance teams model currency exposure, operations teams plan for equipment failure and HSE teams conduct hazard studies. Cyber risk belongs in the same conversation and should be expressed in the same terms. When it is treated solely as a technical matter for IT, the people accountable for the consequences rarely see it.
Express the consequence, not the vulnerability
A board cannot act on “unpatched remote code execution vulnerability on the historian server”. It can act on “an attacker could disrupt production reporting at the refinery for several days and use the historian as a pivot point into the control network”. The underlying finding is identical. The second statement describes business impact, which is what decision makers are there to evaluate.
A useful convention is to write each risk as a structured statement: because of a vulnerability, a threat could cause an event, resulting in a business consequence. If the consequence is difficult to articulate, the risk requires further analysis before it is entered in the register.
Likelihood and consequence
Most risk registers rate each risk on two scales, typically 1 to 5 for likelihood and 1 to 5 for consequence, and combine them to position the risk on a heat map. These ratings are not precise measurements and do not need to be. Their value lies in consistency: applying the same criteria across the organisation makes risks comparable and makes changes in rating visible.
Consequence criteria should be defined in business terms. A rating of 5 might represent loss of production exceeding one week, a safety incident, a regulatory penalty or significant reputational damage. When criteria are anchored to outcomes leadership already recognises, ratings become objective rather than a matter of technical opinion.
Every risk requires an owner and a decision
A risk without an owner is a concern, not a managed risk. The owner should be the person accountable for the consequence, usually a business or operations manager rather than a security analyst. That owner selects a treatment:
- Mitigate by implementing or strengthening controls
- Transfer part of the impact, for example through insurance or contractual terms
- Avoid by discontinuing the activity that creates the risk
- Accept the risk formally, within the approved risk appetite
Acceptance is a legitimate treatment. What matters is that it is a documented decision, recorded with a date and scheduled for review, rather than a default that no one approved.
Reading the register as a decision maker
A risk register should allow leadership to answer four questions within minutes: what are the principal risks, are they improving or deteriorating, who owns them, and are treatment actions on schedule? A register that cannot answer these questions is a technical log, not a management tool.
Link each risk to the assets it affects, the controls that reduce it and the remediation actions in progress. The discussion then moves from “how secure are we?”, which has no meaningful answer, to “these three risks exceed our appetite, these actions will reduce them by the end of the quarter, and this one requires a funding decision today”.
At that point, cyber risk is being governed as business risk.