How to link an event to a risk on Mac
You can do this with RiskOS, a risk register for macOS. One link turns an incident into evidence about a rating.
A register predicts. An event log records. Keeping both is only worth the effort if the two are joined up, because a prediction nobody ever checks against the real world quietly turns into an opinion that has been left to age. The join is a link between an event and the risk it came from, and it takes a few seconds to make.
Everything here happens on your Mac. There is no account, nothing is uploaded, and your register never leaves the machine.
Where events live
Choose Events under Signals in the sidebar. The table is the list of things that actually happened: a reference, the event's title with the risks it is linked to, the date it occurred, the severity you experienced, its status, the detection delay and the cost. Click a row and the panel on the right opens on that event. Every field is edited there, and the link to a risk is made there.
The other half of the picture sits on the risk. Open Risks, select a risk and open Intelligence in its panel. That section carries the indicators watching the risk with their live status, and beneath them the events that have been linked to it. If you look at only one of the two places, make it this one: it is where a rating meets its evidence.
Link an event to a risk, step by step
-
Open the Events list
Choose Events under Signals in the sidebar. Everything you have recorded appears in one table, with the risks each event is attached to shown beside its title, so you can see at a glance which entries are still floating unattached.
-
Open the event, or create it
If the incident is already recorded, click its row. If it is not, press ⌘N while you are in Events and a new one is created for you to fill in. Give it a title that names what happened in one line — Weekend restore rehearsal failed on the finance share rather than Backup problem — and use the description for the sequence of what took place, in the order it took place.
-
Record when it happened and when you noticed
Set the occurred date and the detected date separately. They are rarely the same, and the distance between them is what the Detection delay column in the list reads. Be honest about the second date even when it is uncomfortable: a three-day delay recorded accurately is worth more to next quarter's decisions than a tidy one that nobody believes.
-
Rate the severity you actually experienced
Record the severity as experienced, not the severity the risk's rating predicted. This is the whole point of an event: it is evidence, and evidence rounded towards the forecast tells you nothing you did not already believe. Add the cost if you have a figure, even a rough one, and set the event's status to reflect where it currently stands.
-
Link the risk it came from
In the event's detail, link it to the risk this came from and choose the row from your register. Ask which risk would have had to fail for this to happen, rather than which risk sounds closest. A failed restore rehearsal belongs to RSK-0007 Backup restoration has never been tested end to end, not to a general continuity risk that happens to be nearby in the list.
-
Link any other risks it touched
An incident rarely stays inside one row of a register. A supplier outage can be evidence for the vendor risk that predicted it and for the continuity risk that describes the consequence. Link both, and the Event column shows every risk attached to that entry, so the reach of one incident is legible from the list without opening anything.
-
Check the link from the risk's side
Open Risks, select the risk you linked, and open Intelligence. The event is listed there with the indicators watching the same exposure. Seeing both together is the reason to bother: one is a measurement taken on a cadence, the other is the thing the measurement was meant to warn you about.
-
Write the lesson, and decide whether to re-score
Fill in the lessons on the event while the detail is still fresh, including who recorded it. Then make a deliberate decision about the rating. If the event changed your mind, open Assessment on the risk and move the steppers; if it confirmed what you already thought, leave the rating alone and say so at the next review. Either way the change is kept in History with the reason behind it.
What the link changes
Linking is a small act with a long tail. It alters no number by itself, and that is deliberate: an event is testimony, not arithmetic. What RiskOS does with it is put that testimony in front of you everywhere the rating is used.
| Where | What appears once the event is linked |
|---|---|
| Events list | The linked risks show beside the event's title, so an entry that touches three risks reads as such from the table. |
| Risk panel ▸ Intelligence | The event is listed with the risk's indicators, giving the rating its measured warnings and its realised outcomes in one place. |
| The underrated-likelihood warning | Once a pattern exists, the risk carries a warning with a suggested rating that the observed frequency would justify. |
| Risk panel ▸ History | Nothing from the link itself. Re-score after it and that assessment is kept with the reason you typed and the score it produced. |
| Reports | The risk events section carries them into the PDF, the HTML file, the workbook and the printed copy, all built from one snapshot. |
The fields that make an event worth linking
A linked event with an empty middle is a tick in a box. These are the fields that decide whether it teaches anyone anything a year from now, when everybody who was in the room has moved on.
| Field | What to put in it |
|---|---|
| Title | One line naming what happened, specific enough to recognise in a list of forty. |
| Description | The sequence of events, in order, in plain language. What failed, what followed, what stopped it. |
| Occurred | The date the thing actually happened, not the date it reached your desk. |
| Detected | The date you knew. The gap between the two becomes the detection delay. |
| Severity | How bad it turned out to be, as experienced. Not the rating, the outcome. |
| Status | Where the incident itself stands, so an open matter is not read as a closed one. |
| Cost | What it cost, as well as you can establish. A rough figure beats an empty field. |
| Who recorded it | The person to ask when a detail is queried later. |
| Lessons | What you would do differently. This is the field people read; write it for them. |
| Linked risks | The risk or risks this is evidence about. |
Why both dates matter
Two dates give you a number nobody usually has: how long you were exposed without knowing. The detection delay is the honest test of the detectability rating you set on the risk. If a risk is rated as something you would notice quickly and the linked events show a pattern of week-long delays, one of the two is wrong, and it is not usually the events.
What to count as cost
Record what you can defend rather than what sounds impressive: direct spend, the contractor's invoice, the credit given to a customer, the hours lost to recovery. Where the risk carries an exposure amount in its assessment, a run of costed events is the clearest check you will get on whether that figure was ever realistic.
When the register argues with your rating
Ratings drift towards comfort. A risk is scored once in a meeting, the number is carried forward through review after review, and nobody stops to ask whether the world has behaved as the number claims. Linked events let RiskOS do the asking for you.
When a risk materialises more often than its rating implies, RiskOS says so on the risk itself, in Intelligence, and it carries a suggested rating: what the frequency you have actually observed would justify. The suggestion is a prompt, not an instruction. Nothing is re-scored behind your back, and the warning stays until the rating and the evidence agree.
What counts as enough evidence
The warning needs at least two events over a full year before it appears. One incident is an anecdote and could be bad luck; two inside twelve months is the beginning of a rate. Waiting for the second event also means the register never panics at a single dramatic morning, which is exactly when ratings are most likely to be moved for the wrong reason.
Accepting a suggested rating
If you agree, open Assessment and raise the inherent likelihood yourself. The score, the band and the matrix markers move as you do it, the residual is recalculated from the controls you have linked, and the change lands in History with your reason attached. Write it as a sentence a stranger could follow: two failed restore rehearsals in ten months is a reason; updated is not.
Declining a suggested rating
Sometimes the frequency is misleading. Two events can share one root cause that has since been removed, or belong to a supplier you no longer use. Leave the rating where it is and record why in the risk's description, so the next person to meet the warning finds an argument waiting instead of deciding from scratch.
Events and indicators together
Indicators and events answer different questions about the same risk. An indicator measures something on a cadence and crosses a threshold before anything goes wrong. An event records the morning it went wrong anyway.
Reading them side by side in Intelligence tells you which of your warnings work. If the Backup restore test success rate indicator had been in breach for two cycles before the failure you linked, the indicator did its job and the response did not. If it was comfortably in tolerance the week the event occurred, you are measuring the wrong thing, and the fix is a better indicator rather than a higher score.
Troubleshooting
I linked an event and the risk's score did not move
That is intended. An event is evidence about a rating, not an input to it, and no incident re-scores a risk on its own. You change a rating deliberately in Assessment, or during a review pass, and the reason is recorded with it. What the link changes is what you are shown, and it counts towards the frequency RiskOS checks your likelihood against.
No warning has appeared even though we have had incidents
Check two things. The warning needs at least two events over a full year, so a single incident, however severe, will not produce one. And only linked events count: an incident sitting unattached in the Events list is invisible to the rating it concerns. Open the entries with no risks beside their title and attach them.
I linked it to the wrong risk
Press ⌘Z to undo the change, then link the right one. ⇧⌘Z brings it back if you undo one step too far. If the incident genuinely bears on both risks, leave both links in place rather than choosing; an event is allowed to be evidence about more than one thing.
I cannot find the event in the list
Search the Events list for a word from the title or the description rather than scrolling. Incidents tend to be recorded in the words used on the day, which are rarely the words you would reach for later, so try the supplier's name or the system's name.
The events are missing from my report
Open Reports and switch on the risk events section before you export. The section toggles decide what a report contains, and all four outputs are built from the same snapshot, so once it is ticked the PDF, the HTML file, the workbook and the printed copy agree with each other.
A routine that keeps events honest
Event logs decay faster than any other part of a register, because nobody has time to write one up in the week it would be most useful. A few habits keep them alive.
- Log it in the week it happens. Detail evaporates, and the detected date is the first thing anyone misremembers. A thin entry made on the day beats a full one reconstructed in March.
- Link it before you close the tab. An unlinked event is a story with no home. Attaching it while the incident is in front of you is the difference between a log and a register that learns.
- Record near misses too. Something that cost nothing still happened, and frequency is what the register reads. Low severity with a real occurred date is a complete, useful entry.
- Read Intelligence before you re-score. Open the risk's linked events and indicators first, then touch the steppers. A rating made after looking at the evidence holds up in the room; one made from memory does not.
- Let two events move a rating, not one. Match the threshold the register uses. A single bad morning is rarely a new likelihood, and rating from the last incident makes a register oscillate.
- Sweep for unattached entries each quarter. Scan the Events list for titles with no risks beside them and attach each one, or accept that it belongs to nothing on your register, which is itself worth knowing.
- Carry events into the board pack. Switch on the risk events section in your report. Nothing holds a risk committee's attention like a rating printed beside the thing that already happened.
Frequently asked questions
How do I link an incident to the risk it came from?
Open Events under Signals in the sidebar, select the incident, and link it to the risk from the event's detail panel. The link then shows on both sides: the risks appear beside the event's title in the list, and the event appears in that risk's Intelligence section, alongside the indicators watching the same exposure.
What counts as a risk event?
Anything on your register that actually happened, at any size — an outage, a supplier missing a deadline, a restore that failed in rehearsal, a near miss that cost nothing. RiskOS records what it was, when it occurred, when you noticed, how severe it turned out, what it cost and what you learned, so small events accumulate into a pattern instead of disappearing.
Does linking an event change the risk score?
No. An event is evidence about a rating rather than an input to it, so nothing is re-scored automatically. You decide, either in the risk's Assessment section or during a review pass, and the assessment is kept in History with the reason you gave. The link's job is to put the evidence in front of you before you decide.
Why does RiskOS say a risk is underrated?
Because the risk has materialised more often than its likelihood rating implies. The warning appears on the risk in Intelligence and carries a suggested rating — what the frequency actually observed in your linked events would justify. It is a prompt, not a correction. Nothing changes until you move the rating yourself, and the warning stays until evidence and rating agree.
How many events does it take before a suggestion appears?
At least two linked events over a full year. One incident could be bad luck; two inside twelve months is the start of a rate, and a rate is the only thing a likelihood rating can honestly be compared against. The threshold also keeps the register calm on the morning after a single dramatic failure.
Can one event be linked to more than one risk?
Yes, and it often should be. A supplier outage can be evidence for the vendor risk that predicted it and for the continuity risk that describes the consequence. Link both. The Event column in the list shows every risk attached to an entry, so the reach of a single incident stays visible without opening it.
What is detection delay, and why record it?
It is the distance between the date an event occurred and the date you detected it, shown as its own column in the Events list. It is the honest test of the detectability rating on the risk. A risk you rated as quickly noticed, with linked events showing week-long delays, has a rating that needs revisiting.
Should I log near misses as events?
Yes. Frequency is what the register reads, and a near miss occurred as surely as an expensive one. Record it with a low severity as experienced, a cost of nothing if that is true, and the real occurred and detected dates. Near misses are usually the cheapest evidence you will ever get about a likelihood rating.