A Risk Register With Owners, Dates and a Trigger

A risk register derived from artifacts I already had: eight candidates pulled out of a published case, three thrown out for having no trigger, five rows kept.

Numbers in this note carry source tags ([POLICY], [THREADS n=10], [MINE]). What the tags mean.

This piece stands on the returns case published on this site: damaged-delivery refunds at a mid-size online retailer, built from a published returns policy [POLICY], help centre articles [HELP], ten public complaint threads I selected myself [THREADS n=10], consumer law [LAW] and a walk through the published customer journey [WALKTHROUGH]. No client, no engagement, nobody inside the company asked anything at any point. That matters more here than in most pieces, because a risk register is the artifact most easily filled with confident guesses.

A risk register is a list of events that have not happened yet, where every row names an owner who can act before it does, a date by which acting is still cheap, and a trigger: an observable event that says now rather than later. A row without those three is a worry with formatting.

The register below was not written at a workshop. It was derived from artifacts that already existed, and the derivation is the part worth copying.

In short

• Do not brainstorm risks. Derive them. A pack you have already written names most of them: the anti-goal, the section on what your change makes worse, the column saying what each stakeholder loses, and your own criteria worded as prohibitions.
• A candidate stays only if it survives the trigger test: name the observable event that says act now, and the person other than you who would see it first. Three of my eight candidates did not survive.
• If answering your open questions would delete the row, it was never a risk. It was an open question, and it belongs in the register that already has owners, dates and fallbacks.
• There is no probability times impact column in my register, and the reason is that I have no baseline. A number I chose, multiplied by another number I chose, produces a third one that looks measured.

Where do the rows actually come from?

Seven passes over sections of the case that already existed, each with a rule for what to read out of it.

The second row carries most of the weight. The case has a section naming what the to-be makes worse, written because a proposal that improves everything has not been costed. It is the only risk input in the pack guaranteed to be about your work rather than about projects in general.

The fifth row is the one people skip. A criterion phrased as a prohibition exists because the obvious implementation would break the requirement while appearing to satisfy it. REQ-015 says that assignment to a shared mailbox, a group or a queue does not satisfy it: a risk statement with the word risk missing.

What does the trigger test throw out?

Eight candidates came out of that pass, and each had to answer two questions: what observable event says act now, and who other than me sees it first. Three failed, in two different ways.

Two were open questions wearing a risk costume. A 48 hour window measured in clock hours escalates into a weekend rota that may not exist, and uploaded photographs need a retention period I could not confirm from outside the company. Both disappear the moment a named role answers a question, and both already sit in the case as OQ-04 and OQ-01 with an owner, a due point and a stated fallback. Copying them across creates a second place to track one thing, and the second place is the one that goes stale.

So the boundary is a test you can run in one sentence: if answering every open question on time would delete this row, it is not a risk. What survives is the set of things that can still go wrong when everybody answers you on time.

One had already been converted into a decision. The self-service form is built around photographic evidence, and a customer whose parcel never arrived has nothing to photograph. That arrived through review rather than my own diligence, and the fix was to name non-delivery and lost parcels out of scope, with a reason and an owner. Putting a deliberate exclusion back into a risk register reopens something closed in writing.

Five rows survived, and each can still happen after the last open question is answered.

The register, filled in

Copy the columns, not the content. Owners are roles, because public sources carry no staff list and a plausible name filled in to make a cell look complete is worse than a visible gap. Anything I chose carries [MINE].

Two honest notes on that table. Every owner is a role and says so, because the case has no access to the company, and every review point I chose rather than found is tagged. And RSK-05 is the row that looks least like a risk: it fires when the project succeeds on the number it is being judged by.

Why is there no probability and impact score?

Because I cannot produce either honestly, and a five by five grid would hide that rather than show it.

The case counts how often a case stalls today as unknown: four of the ten complaint threads I selected ended in that state [THREADS n=10], which is a count of ten threads and not a rate, and no rate is obtainable from outside the company. Measuring it is the first thing I would do with access [OPEN, OQ-06]. With no baseline, a probability of 3 out of 5 is a number I chose, an impact of 4 out of 5 is a second number I chose, and multiplying them produces a 12 that looks like it came from somewhere.

The register replaces that pair with two columns somebody else can check: the trigger, and the response when it fires. A trigger is a claim about what is observable in your system, so a reviewer can argue with it. Nobody can argue with a 12.

This is not an argument against scoring where a baseline exists. With your own incident history behind the numbers, score it. From outside a business, on public sources, scoring is decoration with arithmetic on it.

What do the standards actually ask for?

Less than the templates do, and the part they do ask for is the part templates leave out.

HM Treasury's Orange Book, the free risk management guidance for UK government organisations, last updated in July 2026, asks for "clear processes for bringing significant issues to its attention more rapidly when required, with agreed triggers for doing so", and for reporting that shows trends and supports "early warning indicators". Agreed triggers, in other words, and a route that they open. It also puts ownership with management rather than with a document: "management have primary ownership, responsibility and accountability for identifying, assessing and managing risks".

The Software Engineering Institute published its Continuous Risk Management Guidebook in 1996, and the word doing the work in that title is continuous. A register produced once, at the point where a business case needs an appendix, is not what either document describes.

What both ask for, then, is ownership held by people and a route that opens when something changes. Neither of those arrives with a file.

The blank card

One row per risk. If you cannot fill the trigger column, you have not found a risk yet.

Three rules for using it. Write the trigger before the response, because a response you cannot attach to an event is a good intention with a paragraph around it. Retire rows out loud, with a date and a reason: a register nobody ever subtracts from is read once. And when a trigger reads "somebody notices", the risk has no owner yet, whatever the owner column says.

What this register does not tell you

It does not tell you whether the change is worth making, and it prices nothing. The one-page summary in the case carries no cost figures and says why: internal effort cannot be priced from outside the company, and an invented figure is the first thing to break in the room. The risks of changing nothing sit on that page too, under what happens if nothing is decided.

It is also silent on volumes, staffing and cost, the three subjects where public sources gave me nothing. A register that looked complete would be lying about exactly that.

Where to start

Open the last pack you wrote and find the section where you said what your proposal makes worse. If there is no such section, that is the finding, and a larger one than a missing register. Then read your requirements for criteria worded as prohibitions: each is a risk you already identified and filed where no risk owner will look.

Three pieces on this site pick up where this one stops. As-is before to-be puts the two models side by side with a column for what each change breaks, which is where RSK-01 and RSK-04 came from. Definition of ready for a requirement runs a seven-condition gate over the same register and finds the failures a checklist can catch a week late. The questions a reviewer asks about your work sample is the same material seen by somebody with twenty minutes and no reason to be kind.

The twenty-five checks behind the artifacts named here are on the scorecard: yes or no, free, no email address asked for. The worked case this register was derived from, with its version history and its review log, is at the case, and the six blank templates are on templates.

One last thing, since the phrase "risk register template" belongs to tool vendors and it would be strange to pretend otherwise. They will outrank this page for a long time, and their download looks better than the card above. What they cannot hand you is a register with the derivation written beside every row, on a case whose review log is published with it.

All field notes · The portfolio guide · More in The Case File