What a risk register is, and what belongs in one
RiskOS is a risk register for macOS. Here is what a register is for, the fields that earn their place, and what keeps one readable three years from now.
Every organisation carries risk whether or not anyone writes it down. A risk register is the decision to write it down: one list of the things that could go wrong, each rated for how likely it is and how much harm it would do, each with a name beside it and a date by which someone will look again. Everything else — the matrix, the bands, the controls, the reports — exists to make that list comparable, current and defensible.
Everything here happens on your Mac. There is no account, nothing is uploaded, and your register never leaves the machine.
What a register is actually for
A register earns its keep in three moments. The first is the meeting where two risks compete for the same budget and someone has to say which matters more. The second is the morning after something goes wrong, when the question is whether anyone saw it coming. The third is a year later, when a new person inherits the list and has to understand why a risk sits where it does without the meeting that put it there.
Those three moments set the standard for what belongs in a register. A field earns its place if it helps you compare, act or explain. If it does none of those it is decoration, and decoration is what makes registers go stale — every column nobody uses is a column somebody has to maintain.
Where the register lives
In RiskOS, the register is Risks in the sidebar, under Register. The middle of the window holds a sortable table — Ref, Risk with its category, Owner, Inherent, Residual, Target, Trend, Appetite, Status and Review — and selecting any row opens the full risk in the panel on the right.
Around it sit the sections a register leans on rather than duplicates: Controls and Actions for what you are doing about the risks, Review for the pass that keeps them current, Indicators and Events for evidence that a rating is right or wrong, and Assets and Vendors for what the risks threaten and who else they involve. The register is the spine; those sections are what stop it becoming a document written once and read never.
Build a register that earns its keep
-
Decide what the register covers
Write one sentence saying what is in scope — an organisation, a programme, a client engagement — before the first entry goes in. A register that mixes enterprise exposures with individual project issues cannot be sorted meaningfully, because the two are not rated against the same consequences. If you need both, keep them apart: a separate profile dresses the whole of RiskOS for a different scope, with its own methodology, appetite and branding.
-
Agree the scales before the first entry
Likelihood runs Rare, Unlikely, Possible, Likely, Almost Certain. Impact runs Insignificant, Minor, Moderate, Major, Severe. Agree what each point means in your organisation — a cost, a duration, a regulatory outcome — and agree the window you rate likelihood against, usually a year. Settings ▸ Methodology shows the scales and the band thresholds, so everyone is reading the same definitions.
-
Write each risk as an event, not a topic
A good entry names something that could happen: Backup restoration has never been tested end to end, or Supplier concentration in a single logistics partner. A topic — "Backups", "Suppliers" — cannot be rated, because nobody knows what they are rating. Add a short description of what would actually follow, and the next person can pick up the rating without asking you.
-
Rate the inherent exposure
Set inherent likelihood and impact on the 1–5 steppers in the risk panel's Assessment section. Inherent means the risk with nothing standing in its way — the honest starting point, and the only pair of numbers you type. RiskOS multiplies them into a score from 1 to 25 and names the band: Low 1–4, Medium 5–9, High 10–16, Critical 17–25.
-
Record the controls separately
List what you rely on as controls of their own, then link them to the risk from the panel's Controls section. The residual score is calculated from the effectiveness of the controls you linked, so the register can always show how it got from one number to the other. Only controls that are implemented or operating reduce anything; a planned control, however strong it will be, reduces nothing yet.
-
Give every risk an owner and a cadence
Put a person's name in Owner in the Summary section, not a department, and set a review cadence — monthly, quarterly or annually — so a next review date schedules itself. A risk with no owner belongs to nobody, and a risk with no cadence ages out of accuracy without anything in the register noticing.
-
State where you intend to get to
Set a target likelihood and impact, choose a treatment strategy — Mitigate, Accept, Transfer or Avoid — and write the plan with a due date. The comparison grid then shows inherent, residual, target and the gap between them, with a line telling you what strength of control would close it. A risk with a target but no plan is a wish; a plan with no target has no way of knowing when it is finished.
-
Set an appetite so the register can argue back
In Settings ▸ Appetite, set the highest residual score your organisation tolerates. Every risk above it is flagged wherever it appears — in the table, in the panel, on the dashboard and in reports. Categories warranting less tolerance can carry their own threshold with the reason beside it, and an individual risk can override both.
-
Back the whole thing up
Choose File ▸ Back Up RiskOS… or press ⇧⌘B. RiskOS writes one file carrying everything — risks, history, controls, actions, assets, vendors, frameworks, indicators, events and settings — saved wherever you choose, such as Documents ▸ RiskOS. A register is a record, and a record you cannot restore is a draft.
The fields that earn their place
Registers tend to grow columns. The test for each one is whether removing it would change a decision. These are the fields that pass.
| Field | What it holds | Why it earns its place |
|---|---|---|
| Reference | RSK-0001, issued once | A stable name across minutes, reports and years. References are never reissued, so an old paper still points at the right row. |
| Title and description | The event, and what would follow | A title naming a topic rather than an event is the commonest cause of two people rating a risk differently. |
| Category | Cybersecurity, Cloud, Compliance & Regulatory | Shows concentration. Six of twelve risks sitting in one category is itself a finding. |
| Owner | A named person | Turns the register into commitments rather than observations, and prepares a one-to-one in one sort. |
| Inherent rating | Likelihood × impact, before controls | The exposure itself. Keeping it separate from residual is what lets you show what a control is worth. |
| Residual rating | Calculated from linked controls | Where you actually stand this morning. The number to sort on and to report. |
| Target rating | Where you intend to get to | Gives a treatment plan a finish line. |
| Treatment and plan | Mitigate, Accept, Transfer or Avoid, with a date | Records the decision, not only the concern. Accepting deliberately is a valid answer; blank is not. |
| Review cadence | Monthly, quarterly, annually | The mechanism that keeps every other field honest. |
| Status | Active, closed, accepted | Lets a register shrink in the reading without losing anything from the record. |
The fields worth adding when they change a decision
Three more sit in the Assessment section and are worth filling in when they would alter what you do. Onset velocity is how fast a risk arrives once it starts. Detectability is how likely you are to notice. Neither feeds the score, which stays likelihood × impact — but a Medium risk that arrives immediately and goes unnoticed often deserves attention ahead of a High one you would see coming for months. Exposure amount is an optional figure for risks where a number carries more than a word does.
The fields that do not earn their place
A residual score typed in by hand is the classic one. It looks like data and behaves like an opinion, and it is the first thing anyone reviewing the register will pull on. RiskOS calculates residual from the controls you link, or from an effectiveness value you set deliberately — and when a hand-set value disagrees with the linked controls, the risk's panel says so rather than quietly picking a side. The same logic rules out free-text status columns that duplicate the status picker, and second owner columns that drift apart within a quarter.
What a register connects to
Each row can point at the rest of your work, and that is where a register stops being a record and starts earning its place in decisions. None of this is required to start; each piece answers a question a rating on its own cannot.
| Section | The question it answers | What it gives the register |
|---|---|---|
| Controls | What is standing in the way? | A residual score with an argument behind it. |
| Actions | What is being done, and by when? | Every action in one place, grouped by overdue, due soon and later. |
| Indicators | Is this getting worse? | A measured number with warning and breach thresholds, so movement shows before anyone re-scores. |
| Events | Has this already happened? | What it cost and how long it took to notice — and a challenge to a likelihood rating reality disagrees with. |
| Assets | What is threatened? | Systems, data, facilities and processes, each with a criticality and its worst residual risk. |
| Vendors | Who else is involved? | Third parties with a criticality, an owner, a review date, and every risk they bring. |
| Frameworks | Are we covered? | Coverage in three honest states: covered, mapped but not operating, and not mapped. |
What keeps a register defensible
Defensible means someone can ask why a risk is rated as it is, a year after the meeting that rated it, and get the answer from the register rather than from memory. Three things carry that.
A record of every assessment
Each risk's History keeps every assessment ever made, with the reason it was made and the score it produced, plus a chart of the residual score over time. That is what turns a snapshot into a record. A re-score that changes nothing is recorded as a confirmation, so the absence of movement is evidence too, rather than an absence of evidence.
Closing rather than deleting
Risks are closed, never deleted. A risk that no longer applies still explains why the register looked as it did last year, and a closed risk keeps its original reference. Filters hide closed and accepted risks from the day-to-day view, so the record stays complete while the working list stays short.
Numbers that are always calculated
Scores are never read in from a file. When risks or controls are imported, RiskOS recalculates every score from the ratings and the controls rather than trusting a column, and out-of-scale values are clamped rather than silently accepted. A register assembled from several sources still holds together under one method.
How big should a register be
Smaller than people expect. A register is read by humans in meetings, and a list that takes an hour to walk will not be walked. Twelve to forty active risks suits most organisations, and the number matters far less than whether every row still earns a conversation.
When a register grows past what anyone reads, the cause is usually granularity rather than genuine exposure — five rows describing one dependency, or day-to-day problems recorded as though each were a separate exposure. Merge them into the risk they all describe, close the rest, and let categories and business units do the dividing. For a sense of the right altitude, Risk Library holds thirty-nine example risks across seven categories, each written at the level a register can use.
Troubleshooting
My register has grown and nobody reads it
Sort by residual score and read the top ten. If the rows below are variations on the same few themes, the register is too granular. Merge the variations into the risk they describe and close the duplicates — closing keeps the record while taking them out of the view. Then set a cadence on what remains, so the list is maintained by routine rather than by effort.
Half my rows have no owner
Select the unowned rows together and the panel becomes a bulk editor. Tick only Owner, choose a name, and apply it to every selected risk; fields you leave unticked stay exactly as they were. It is the fastest way to fix a whole column without opening rows one at a time.
I cannot tell which rows are out of date
The Review column shows each risk's next review date, and the dashboard counts what has fallen behind. Review then walks the risks that are due, one at a time, worst first, with full context beside the scoring inputs. Confirming or re-scoring stamps the review date and schedules the next one from the risk's cadence.
Two entries describe the same risk
Keep the one with the better history, move anything useful across from the other, and close the duplicate with a note saying which reference it was merged into. Closing rather than deleting means the old reference still resolves when someone opens last quarter's report and asks what happened to it.
The board asked what changed and I could not say
The Trend column shows the direction of travel on each risk, and each risk's History chart shows the residual score over time. For the meeting itself, a report can carry an executive summary, the matrix, the top risks, open actions and framework coverage from one snapshot, so every output format agrees with the others.
Habits that keep a register alive
A register is a routine more than a document. These habits do most of the work.
- Read the register weekly, not quarterly. Ten minutes on the dashboard — what is over appetite, overdue for review, or late on its actions — catches drift long before a quarterly pass would.
- Keep the working view short. Right-click the table header to hide the columns this pass does not need, then use Save Current Filter… to name the view and bring it back in one click.
- Write the reason, always. A rating without a reason is an opinion with a number attached. The description is where next year's reader finds out what drove it.
- Let the evidence challenge the rating. Indicators move before scores do, and events tell you whether a likelihood rating was ever right. Link both to the risks they belong to.
- Close deliberately. When a risk is genuinely gone, close it with a reason rather than leaving it to drift down the sort order.
- Review on a cadence, not on a scare. A register updated only after incidents records your surprises, not your exposures.
- Back up on a schedule. Set a reminder interval you will honour — weekly, fortnightly or monthly — and keep the dated file somewhere you would still find it in a bad week.
Frequently asked questions
What is a risk register?
A risk register is a single list of the things that could go wrong in an organisation, each rated for likelihood and impact, each with an owner, a treatment decision and a date for the next review. It exists so risks can be compared on the same basis, acted on by named people, and explained long after the meeting that recorded them.
What should a risk register include?
At minimum: a stable reference, a title naming an event, a short description, a category, an owner, an inherent rating, the controls you rely on, a calculated residual score, a treatment strategy with a plan and date, a review cadence and a status. In RiskOS each of those is a field on the risk, and the residual score is calculated rather than typed.
What is the difference between a risk register and a risk assessment?
An assessment is the act of rating a risk at a point in time. The register is the living list those assessments accumulate in. RiskOS keeps every assessment in the risk's History with the reason behind it and the score it produced, so the register shows both where a risk stands now and how it got there.
How many risks should a risk register have?
Few enough that the list is read. Twelve to forty active risks suits most organisations. If yours is much longer, the cause is usually granularity rather than exposure: several rows describing one underlying dependency. Merge them into the risk they describe and close the duplicates, which keeps the record intact while shortening the working view.
How often should a risk register be reviewed?
Set a cadence per risk rather than one for the whole register — monthly for fast-moving exposures, quarterly for most, annually for the stable ones. RiskOS schedules the next review date from that cadence each time you confirm or re-score, and Review mode walks everything that is due, worst first, one risk at a time.
Who should own the risk register?
One person maintains the register; each risk has its own owner. That split matters. The maintainer keeps the method consistent and the reviews moving, while the risk owner answers for the exposure and the plan. Sorting the table by owner gives you exactly what one person holds, which is what makes a one-to-one about risk short.
Do I need a risk register for ISO 27001?
Standards of that kind expect a documented, repeatable risk assessment: identified risks, a consistent method, owners, treatment decisions and evidence that reviews happen. A register recorded that way is what you would show. RiskOS keeps the assessment history and control evidence alongside each risk, and maps controls to framework requirements so coverage can be read directly.
Where does my risk register live, and does it leave my Mac?
It stays on your Mac. There is no account, no sign-in, no sync and no telemetry, and nothing is uploaded. Your register leaves the machine only when you export or back it up yourself, which writes a single dated file wherever you choose. The only network use is Apple's App Store, for purchases, and it never sees your register.