A risk register people actually use

Most risk registers are created during initiation because a template demanded one, filed in a shared drive, and opened again only when something has already gone wrong. At that point it is not a risk register. It is a document proving you predicted the problem and did nothing.

A register earns its place only if it changes a decision.

A risk is not an issue

The distinction matters more than it sounds. An issue is happening now and needs solving. A risk has not happened and may never. Registers rot when the two are mixed, because issues are urgent and crowd out the thinking that risks require.

If the entry has already occurred, it belongs on the issue log and in this week's status. Take it out of the register.

The fields that earn their place

Strip a register down to what actually drives action:

• The risk, written as a causal sentence. Not "integration risk" but "if the payment provider's sandbox is still unavailable past the 14th, integration testing cannot start and the launch date moves". A one-word category tells you nothing. A causal sentence tells you what to watch and what it costs.
• The trigger. What observable event tells you this is materialising? A date passing, an environment still down, a key person's notice period ending. Without a trigger you are relying on somebody remembering to worry.
• The owner. One name, not a team. The person who watches the trigger.
• The response. Avoid, reduce, transfer or accept, plus the specific action attached to it. "Monitor" is not a response.
• Exposure. What it costs if it lands, in the currency the project actually cares about: days, money, or scope.

Probability times impact is mostly theatre

The five-by-five matrix feels rigorous. In practice nobody can reliably distinguish a 3 from a 4 on either axis, and the resulting score lends false confidence to a guess.

A more useful framing: if this lands, what does it cost, and what would it cost to reduce that now? Expressing exposure in days or money makes the mitigation conversation concrete. "This risk is a 12" starts no useful conversation. "This risk costs us three weeks, and two days of work now removes it" ends one.

Keep a rough high, medium or low if governance requires a score. Just do not let it substitute for the sentence.

Keeping it alive

• Review on a cadence, briefly. Fifteen minutes a week beats two hours a quarter. Walk the top five, check the triggers, move on.
• Retire risks explicitly. When the window passes, close the entry and say so. A register that only ever grows becomes noise, and nobody reads noise.
• Add risks from retrospectives. The things that hurt on the last project are the best-evidenced risks on this one.
• Escalate the ones you cannot own. A risk whose mitigation sits outside your authority is not a risk you are managing. It is a decision somebody else needs to make, and it belongs in the status report with a name and a date attached.

The test

Look at your register and ask: in the last month, did anything in here cause us to do something differently?

If the answer is no, either the project is unusually calm, or the register is decoration.