What a risk actually is

Most risk registers fail at the first column. "Phishing" is not a risk; it is a topic. Nobody can own it, score it or decide anything about it.

Write a sentence

A risk has three parts: a cause, an event and a consequence.

An employee enters credentials on a phishing page (cause), an attacker signs in to the finance system and initiates payments (event), costing up to £250,000 before detection and requiring disclosure to our bank (consequence).

Written this way, several things fall out immediately: the controls that matter, who owns it, what evidence would tell you the likelihood, and what the organisation would actually lose.

Separate the layers

Teams routinely mix three different things in one register: threats (what might happen), vulnerabilities (why it could) and risks (the consequence to the organisation). Keep them apart. "Unpatched internet-facing VPN" is a vulnerability; the risk is what happens through it, and the same vulnerability may feed several risks.

Keep the register small

Fifty live risks is a programme leadership can engage with. Five hundred is a filing system that nobody reads. Aggregate the detail — individual vulnerabilities belong in a remediation backlog, not the risk register.

Start from assets, briefly

You cannot assess risk to things you have not listed. But a six-month asset discovery project before any risk work is a way of never doing risk work. List what matters most — the systems that hold the data, move the money or run the product — and start there.

The test of a good entry

Show it to the person who would have to fund the fix. If they can tell you whether they care, it is written well. If they ask "what does that mean for us?", rewrite it.