How to log a risk event on Mac
A register is a set of predictions. An event is one of them coming true. Record it in RiskOS, the risk register for macOS, and the prediction can be checked against what happened.
Most of a register is forward-looking: this could happen, about this often, and it would cost about this much. An event is the moment one of those sentences stops being a forecast. Writing it down takes ten minutes while the detail is fresh, and it is the only way a rating you set eighteen months ago can ever be held to account.
An event records something that happened once. An indicator records a number you measure on a cadence. Keeping the two apart is what allows the register to compare them later.
Where risk events live
Choose Events under Signals in the sidebar, below Indicators. The middle of the window holds the table of everything that has already happened; the panel on the right shows and edits whichever row you select. Both the sidebar and the panel resize, and RiskOS remembers where you leave them.
The table carries a reference, the event with the risks it is linked to, the date it occurred, the severity as it was experienced, the status, the detection delay and the cost. Search covers the list, so a half-remembered supplier name is enough to find something from two years ago. Events sit beside the register rather than inside it: they are the evidence, and the risks are the argument.
Log an event, step by step
-
Open the events list
Choose Events under Signals in the sidebar. The table shows every event already recorded, and the panel on the right opens whichever row you select. The search field above the list covers the section, so an entry from two years ago is a few keystrokes away.
-
Create the event
Press ⌘N while Events is the section you are in. A new event appears ready to fill in, and the register issues its reference in the Ref column so you never have to keep a numbering scheme in your head.
-
Name what actually happened
Give the event a title that states the occurrence rather than the category — Payroll provider offline for eleven hours on the last working day of the month rather than Payroll incident. A title that names the thing is what makes the list readable at a glance a year later.
Use the description for the sequence: what started it, what it affected, who was involved, what was done and when it was resolved. Write it as though the reader has no memory of the week it happened, because eventually nobody will.
-
Set the date it occurred and the date you noticed
Fill in both the occurred date and the detected date. They are separate fields for a reason: the gap between them is the detection delay, and the register works it out and shows it as its own column in the table.
Where the start is genuinely unknown, use the earliest point you can defend and say so in the description. A soft estimate that is labelled as one is more useful than a confident date nobody can support.
-
Rate the severity as it was experienced
Set the severity to what the organisation actually felt, using the same five points the register rates impact with: Insignificant, Minor, Moderate, Major and Severe. This is not the rating on the risk and it is not what could have happened. It is the outcome, recorded honestly, including the times you were fortunate.
-
Record what it cost
Enter the cost as best you can establish it. Overtime, the replacement hardware, the credit issued to customers, the specialist brought in for a fortnight. An approximate figure with a note explaining what is inside it is worth far more than an empty field, because cost is what turns a risk conversation into a budget conversation.
-
Link the event to the risk it came from
Link the event to the risk that predicted it. This is the step that pays for all the others: the risk's Intelligence section then lists the event alongside its indicators, and the register can start comparing how often a risk has actually materialised with how often its likelihood rating says it should.
An event can link to more than one risk where it belongs to more than one, and an event with no plausible parent risk is itself a finding — you have recorded something your register did not anticipate.
-
Write the lessons and set the status
Fill in the lessons field with what you would do differently, then note who recorded the event and set its status to reflect where it has got to, so that something still being worked reads differently from something written up and closed out. Changes save as you type, and ⌘Z undoes anything you did not mean.
What an event record holds
The fields are few on purpose. A form long enough to feel like paperwork is a form nobody fills in on the day, and a half-finished record is worse than a short one because it looks complete. Everything below earns its place either by making the entry findable later or by letting the event be compared with the rating that failed to predict it.
| Field | What it holds | Why it earns its place |
|---|---|---|
| Title | One line naming the occurrence. | It is what the list, the linked risk and the report all show. |
| Description | The sequence, the scope and the resolution. | The only part that will still make sense to a stranger. |
| Occurred | The date the event began. | Anchors the event in time and drives frequency. |
| Detected | The date you found out. | Produces the detection delay without anyone calculating it. |
| Severity | How bad it actually was. | Lets you compare outcomes with the impact you predicted. |
| Status | Where the event has got to. | Separates what is still live from what is written up. |
| Cost | What it came to, as far as you can establish. | Turns a severity word into a figure a board responds to. |
| Recorded by | Who wrote the entry. | Gives the next reader somebody to ask. |
| Lessons | What you would do differently. | The part that becomes an action or a new control. |
| Linked risks | The risk or risks it came from. | Connects the evidence to the prediction it tests. |
Severity is the outcome, not the forecast
Rate what happened. A near miss that could have taken the whole month's billing with it was, as experienced, Minor — and recording it as Minor is what keeps the severity column meaningful. The place for "it could have been much worse" is the description and the lessons, where it belongs, and where it can drive a control rather than quietly inflating a number.
| Severity | A working reading for an event |
|---|---|
| Insignificant | Absorbed in the ordinary course of work. Nobody outside the team noticed. |
| Minor | Real disruption, handled within the team, over within the day. |
| Moderate | Management attention, measurable cost, recovery took days. |
| Major | Customers, regulators or the balance sheet felt it. |
| Severe | Threatened the organisation's obligations or its ability to operate. |
Cost is an estimate, and that is fine
Nobody has a precise figure in the first fortnight, and waiting for one is how event logs end up empty. Record your best estimate, write in the description what it does and does not include, and revise it when the true number arrives. A range you are honest about beats a blank you are precise about.
Detection delay, and why it matters
The detection delay is the distance between the occurred date and the detected date, and it is the one number on an event that says something about your controls rather than about the world. Two organisations can suffer the same failure; the one that noticed in four hours and the one that noticed in nine days are not in the same position, and their residual scores should not look identical.
Because the delay sits in the table beside every event, the log gives you a reading that is worth watching in its own right: how long things tend to run before anybody notices. A pattern of long delays is usually an argument for a detective control rather than a preventive one, and it pairs naturally with an indicator — a measure such as Days to detect a security event, watched on a cadence with a warning and a breach threshold, so the trend is visible between events rather than only after them.
What a shrinking delay tells you
Falling detection delays across a series of events are one of the few pieces of evidence that a control is genuinely working rather than merely implemented. Note it in the lessons of the most recent event and in the evidence on the control itself, so that the next person to question that control's effectiveness has something concrete to read.
Reading the events table
Seven columns, each answering a different question about the same entry. Knowing what each one is really telling you is most of what makes the log worth keeping.
| Column | What it shows | What you learn from reading down it |
|---|---|---|
| Ref | The reference the register issued. | A stable name for the entry in minutes and reports. |
| Event | The title, with the risks it is linked to. | Which risks keep turning up underneath real events. |
| Occurred | When it began. | Whether the last quarter was unusual, or typical. |
| Severity | How bad it was, as experienced. | Which events deserve a paragraph in the board report. |
| Status | Where the write-up has got to. | What is still open from the last review pass. |
| Detection delay | Occurred to detected. | Whether things are running unseen for too long. |
| Cost | What it came to. | Where the money has actually gone this year. |
When events argue with a rating
This is the reason the log exists. A risk rated Unlikely that has produced three events in a year is not Unlikely, whatever the register says, and someone has to notice. RiskOS does the noticing: when a risk materialises more often than its likelihood rating implies, the risk's panel says so and suggests the rating the observed frequency would justify. The comparison needs at least two linked events across a full year, so that a single bad fortnight does not rewrite an assessment on its own.
The suggestion is a prompt, not an instruction. You decide whether the events were the same underlying cause, whether the period was representative, and whether something has since changed. What you cannot do any more is fail to see the contradiction, which is how likelihood ratings usually go stale — quietly, and in the direction that requires no work.
Where the warning appears
Open the risk and go to Intelligence. That section carries the indicators watching the risk with their live status, the events linked to it, and the underrated-likelihood warning with its suggested rating when the evidence supports one. Everything that tests the rating is in one place, next to the rating it tests.
What to do with a suggestion you accept
Re-score in Review rather than in passing. The review pass shows the risk with its owner, actions, controls and last review beside the scoring inputs, updates the projected rating live before anything is written, and stamps the review date when you confirm. The assessment is then kept in History with your reason, and "three events in the year" is a reason that will still be convincing to an auditor in 2029.
Troubleshooting
The detection delay column is empty
One of the two dates is missing. The delay is derived from the occurred date and the detected date together, so an event with only one of them has nothing to subtract. Open the event and fill in whichever is blank, using the earliest date you can defend if the exact one is unknown.
Three events, and the register has not flagged the risk as underrated
Check two things. First, that all three events are actually linked to that risk — an event linked to nothing counts towards nothing. Second, that they span a full year; the comparison needs at least two linked events over a complete year before it will suggest anything, which stops one difficult month rewriting a rating.
I cannot find an event I know I logged
Use the search field above the list rather than scrolling. Searching the events list will find an entry from a title or a fragment of it, which is usually faster than remembering roughly when something happened. It is also the argument for titles that name the occurrence: a list of entries called Outage is a list you cannot search.
The severity does not match the risk's rating
That is information, not an error. An event's severity is what was experienced; the impact on the risk is what you expect a typical occurrence to cost. A run of events coming in consistently below the rated impact is worth a conversation about whether the impact rating was set from the worst imaginable case rather than the realistic one.
Nobody on the team fills the log in
Shorten what you ask for. Title, occurred date, detected date, severity and the linked risk take two minutes and deliver most of the value; cost and lessons can be added at the review. An event logged thinly on the day it happened is worth more than a thorough one that was never written because the form looked long.
Habits that keep an event log useful
The log only repays the effort if entries keep arriving. A few routines carry most of that.
- Log it the same week. Detail decays quickly, and the dates are the first thing to go. A thin entry written on the day beats a full one written from memory in March.
- Log near misses too. Severity Insignificant is a legitimate entry. Near misses are where frequency evidence accumulates cheaply, before anything expensive has happened.
- Always link to a risk. An unlinked event is a story; a linked one is evidence that can move a rating. If nothing in the register fits, add the risk the event has revealed.
- Turn lessons into actions. A lesson that stays in the lessons field is a sentence. Put it on the parent risk or a control as an action with an owner and a date, and it will show up in Actions until it is done.
- Read the log before a review pass. Ten minutes with the events since last quarter will tell you which ratings to challenge, so the review is not a re-confirmation of what you already believed.
- Watch the delays, not only the counts. Frequency argues about likelihood; detection delay argues about controls. Both are in the same table.
- Put events in the report. The report's risk events section carries what actually happened, which is what makes a board pack land — a register of predictions alone rarely does.
- Review the unlinked ones quarterly. Events with no parent risk are the clearest map of what your register is not yet looking at.
Frequently asked questions
What counts as a risk event?
Anything that actually happened and that a risk in your register predicted, or should have. An outage, a breach, a supplier failure, a missed deadline, a loss. Near misses count as well: record them with the severity that was genuinely experienced. In RiskOS an event carries its dates, its severity, its cost and a link to the risk it came from.
What is detection delay in a risk register?
It is the time between the date an event occurred and the date it was detected. RiskOS derives it from the two dates and shows it as a column in the events table. Long delays point at how well you would notice something rather than how likely it is, which usually calls for a detective control.
Should I log near misses as risk events?
Yes. Record them with the severity that was actually experienced, which will often be Insignificant or Minor, and use the description and lessons to explain what nearly happened. Near misses build frequency evidence cheaply, and frequency is what eventually challenges a likelihood rating that has drifted away from reality.
How does logging events change a risk score?
Not on its own. Events never overwrite a rating. When a risk materialises more often than its likelihood implies, RiskOS says so in the risk's Intelligence section and suggests the rating the observed frequency would justify. You decide whether to accept it, and the re-score is recorded in History with your reason.
How many events does it take before a risk is flagged as underrated?
At least two events linked to that risk, across a full year. The threshold exists so that a single difficult fortnight does not rewrite an assessment. Events not linked to the risk are not counted, which is why linking each event to its parent risk is the step that makes the rest of the record useful.
Can one event be linked to more than one risk?
Yes, and real incidents often belong to several. A supplier outage that also exposed a gap in your recovery testing genuinely tests both risks, and linking it to each means both see it in their Intelligence section. Only link where the event really is evidence for that risk; padding the links weakens every comparison that follows.
What is the difference between a risk event and a key risk indicator?
An event is one thing that happened, recorded once, with dates, a severity and a cost. An indicator is a number you measure on a cadence, with warning and breach thresholds, that moves before anything happens. Events are evidence after the fact; indicators are early warning. Both link to the risks they concern.
Does anything I log leave my Mac?
No. Everything here happens on your Mac. There is no account, nothing is uploaded, and your register never leaves the machine unless you export or back it up yourself. The only network RiskOS uses is Apple's App Store, for purchases, and it never sees what you have recorded.