How to set a risk appetite per category on Mac
You can do this with RiskOS, a risk register for macOS. One threshold rarely fits every category, so give the ones that differ a number and a reason.
Few organisations tolerate the same amount of risk everywhere. A delivery slip in an internal migration is survivable at a score that would be indefensible against a regulatory obligation, and a single organisation-wide threshold flattens that difference until the register flags the wrong rows. Per-category appetite puts the distinction back: one number, one reason, applied to everything filed under that category.
Everything here happens on your Mac. There is no account, nothing is uploaded, and your register never leaves the machine.
Where per-category appetite lives
Appetite is set in one place and read everywhere else. Press ⌘, to open Settings, or choose Settings in the sidebar, and open Appetite. The organisation threshold sits at the top: the highest residual score you are willing to live with across the whole register. Beneath it is the per-category list, where any category can carry a threshold of its own and the rationale that explains it.
The result shows up in the register itself. The risks table carries an Appetite column alongside Inherent, Residual, Target and Trend, so you can see which threshold each row is held to. RiskOS flags a risk sitting above the threshold that applies to it wherever it appears — in the table, in the risk's own panel header, in review, and in anything you export.
Set a category appetite, step by step
-
Open the appetite settings
Press ⌘, to open Settings and choose Appetite. You will see the organisation threshold first and the per-category thresholds below it. Nothing here changes a score; appetite only decides which scores get flagged.
-
Read the organisation threshold first
Every category without its own number inherits this one, so it is the baseline your exceptions are measured against. Settle it before you start carving out categories: a per-category threshold only means something once the default behind it is deliberate.
-
Choose the category that needs its own number
Work down the per-category list and pick the one where the organisation figure is plainly wrong. The list is the one your register already uses — the seeded categories plus any of your own — so you are choosing between areas that hold real risks rather than abstractions. Start with the category whose consequences are least like the rest: a regulatory obligation, a safety duty, a contractual commitment with a penalty attached.
-
Set the threshold for that category
Give the category the highest residual score you will tolerate in it, on the same 1 to 25 scale as every other score in the register. Tightening compliance from an organisation-wide 9 down to 6 means anything in Compliance & Regulatory scoring 7 or more is now over appetite, while the rest of the register carries on at 9.
-
Write the rationale beside it
Each category threshold carries a rationale, and it is the part that survives a change of staff. Say what the number is protecting and who agreed it — "Regulatory obligations. Board tolerance set at Medium and below, agreed March" reads far better in a year's time than a bare 6.
-
Check what the change re-flags
Go to Risks and switch on the over-appetite only filter. The filter icon fills while it is on, and the table narrows to the rows sitting above whatever threshold applies to them. Tightening a category usually pulls in rows that were comfortably within the old figure, and those are the rows the change exists to surface.
-
Override a single risk only where it is warranted
Open a risk and find the Appetite section in its panel, which names the threshold the risk has inherited and where it came from. Switch on the override and set its own stepper when one risk genuinely sits outside its category's logic — a single accepted exposure carrying a board decision, for example. Use it sparingly: an override is a number nobody can see the reason for from the settings screen.
-
Work the new flags in review
Choose Review and pick the Above appetite scope; the count beside it is live, so it already reflects the thresholds you have set. Risks arrive one at a time, worst first, with the owner, actions, controls and last review beside the scoring inputs, so you can decide whether each needs treatment, a target, or an honest acceptance.
How appetite resolves for a risk
Three levels can supply a threshold, and only one of them wins. RiskOS resolves them in a fixed order and always shows the result in the risk's Appetite section, so you never have to guess which number a row is being held to.
| Level | Where it is set | When it applies |
|---|---|---|
| Risk override | The Appetite section of that risk's panel | Always, for that risk alone. It beats everything below it. |
| Category threshold | Settings ▸ Appetite, in the per-category list | When the risk has no override and its category carries a threshold. |
| Organisation threshold | Settings ▸ Appetite, at the top | When there is no override and no category threshold. |
| None | Nothing set at any level | The risk is never flagged as over appetite, whatever it scores. |
Two consequences follow. A category threshold does not have to be tighter than the organisation one; set it higher and that category is held to a looser standard, which is the right answer where the organisation knowingly runs hot. And an override is per-risk, so changing a category threshold leaves every overridden risk in it exactly where it was.
Choosing a threshold that holds
Appetite is read against the residual score — what RiskOS works out is left once the effectiveness of your controls is taken into account — not the inherent one. An organisation whose controls are strong can hold a tight appetite without every row turning red; one still building them will flag half the register at the same figure, and a threshold that flags half the register stops being read.
Because the threshold is a residual score, it lands inside one of the four bands, and the band is the plainest way to explain the choice to people who do not think in numbers.
| Threshold | Tolerates up to | What it says |
|---|---|---|
| 4 | The top of Low | Anything above negligible needs treatment. Rare outside safety and regulatory work. |
| 6 | Lower Medium | Some residual exposure is accepted, but not much. A common setting for compliance. |
| 9 | The top of Medium | Everything in High and Critical is flagged. The usual organisation-wide default. |
| 12 | Lower High | Real exposure is tolerated while a plan runs. Suits delivery and change work. |
| 16 | The top of High | Only Critical is flagged. Use where the organisation has consciously chosen to run hot. |
A worked set of thresholds
Take a register of twelve active risks with an average residual of 9.6 and an organisation threshold of 9, where four rows are over appetite. Tighten two categories, leave the rest inherited, and the picture changes line by line.
| Category | Threshold | Highest residual in it | Result |
|---|---|---|---|
| Compliance & Regulatory | 6 | RSK-0005 at 10 | Over by four |
| Artificial Intelligence | 6 | RSK-0006 at 9 | Over by three |
| Cybersecurity | 9 (inherited) | RSK-0001 at 15 | Over by six |
| Business Continuity | 9 (inherited) | RSK-0007 at 15 | Over by six |
| Third-Party / Vendor | 9 (inherited) | RSK-0011 at 12 | Over by three |
| Project Delivery | 12 | RSK-0009 at 9 | Within appetite |
Tightening compliance to 6 creates no new flag here — RSK-0005 was already over at 10 — but it changes the distance, and the distance is what a treatment plan has to close. Tightening artificial intelligence does create one: RSK-0006 sat exactly at 9 and was therefore within appetite; at 6 it is three points over. Loosening project delivery to 12 changes nothing today, which is the point of writing it down. A delivery risk that climbs to 11 next quarter will not raise a flag, because you decided in advance that it should not.
Writing a rationale worth reading
The rationale is not administration. It is the difference between a threshold people respect and one the next risk owner changes because nobody could remember why it was 6.
Say what the number protects
Name the obligation or the consequence the figure exists to guard — a reporting deadline, a customer contract, a statutory duty. A rationale that describes an outcome can be tested later; one that says "important area" cannot.
Say who agreed it and when
Appetite is a governance decision rather than an assessment, so record the forum and the month. When someone proposes moving the number, the rationale tells them who to go back to.
Say what would change it
A line on what would justify revisiting the threshold keeps it from calcifying. "Revisit once the quarterly restore rehearsal is operating" gives the appetite a natural review point rather than a permanent verdict.
Where the over-appetite flag appears
A threshold is only useful if its consequence is visible without anyone going looking, so an over-appetite risk is marked in every place it turns up.
In the register
The Appetite column shows the threshold applying to each row, and the over-appetite only filter narrows the table to the rows above theirs. Combine it with a band filter and use Save Current Filter… to name the combination so it comes back in one click each week. Right-click the table header to move the Appetite column next to Residual, where the comparison is easiest to read; the arrangement is remembered.
In the risk panel
The panel header carries an over-appetite flag beside the band badge and the trend, so the state is visible the moment a risk is selected. The Appetite section below explains the threshold in words: which level supplied it, and what it is.
In review and in reports
Review offers Above appetite as a scope with a live count, which makes a natural agenda after a threshold change. Exports carry the flag through from the same snapshot, so the PDF, the HTML file, the workbook and the printed copy all agree about which risks are outside tolerance.
Troubleshooting
I set a category threshold and nothing changed
Check the category on the risks themselves. A threshold applies to risks filed under that exact category, so rows sitting under a near-duplicate category created earlier carry on inheriting the organisation figure. Select them in Risks, then use the bulk editor to tick category and set them all to the right one.
A risk shows an appetite I did not set for it
That is inheritance working. The Appetite section in the risk's panel names where the number came from — its own override, its category, or the organisation. A surprising figure usually means the category carries a threshold set for a different reason than the one you have in mind.
Two risks in the same category show different appetites
One of them has an override switched on. Open each risk's Appetite section: the one with the override says so plainly. Switch it off and that risk falls back to its category threshold, or to the organisation threshold if the category has none.
Tightening a category flagged far more than I expected
Appetite is compared against residual scores, so a category full of risks whose controls are still planned will flag heavily at any tight threshold. Only controls that are implemented or operating reduce risk, and RiskOS says so. Before loosening the number again, check whether the real problem is a set of controls waiting to go live.
My category thresholds are missing in a client profile
A profile keeps its own appetite as a snapshot, so it does not follow a later change in Settings. Switch to the profile and use Update from Current Settings to refresh its methodology and appetite, or set that client's thresholds within the profile if they were always meant to differ.
Habits that keep appetite honest
- Settle the organisation threshold first. Per-category numbers are exceptions, and exceptions only make sense against a default somebody has actually decided.
- Tighten by exception, not by habit. Three or four categories with their own thresholds is a policy. Twelve is a second methodology nobody will maintain.
- Write the rationale in the same sitting. The reason is never easier to write than in the minute you chose the number.
- Check the over-appetite list straight after a change. A threshold that flags nothing new and a threshold that flags half the register both need a second look.
- Keep overrides rare and dated. An override hides a decision from the settings screen, so note the reason in the risk's description where the next reader will find it.
- Re-read the thresholds when the methodology moves. Changing whether controls reduce likelihood, impact or both re-scores every risk at once, and thresholds that were comfortable may no longer be.
- Save the view you use every week. Over appetite, sorted by residual, saved as a named filter, is the shortest route to a list worth discussing.
Frequently asked questions
What is a risk appetite in a risk register?
It is the highest residual score you are willing to tolerate. In RiskOS it is a number on the same 1 to 25 scale as every score in the register, set organisation-wide in Settings. Any risk scoring above the threshold that applies to it is flagged as over appetite everywhere it appears, from the table through to exported reports.
Can different risk categories have different risk appetites?
Yes. Any category can carry its own threshold and its own rationale, set in the per-category list in Settings ▸ Appetite. Categories without one inherit the organisation threshold. This is how a compliance category can be held to 6 while delivery work runs at 12, inside one register.
How do I choose a risk appetite score?
Pick the band boundary you can defend rather than a number that feels right. A threshold of 9 flags everything in High and Critical; 6 flags most of Medium as well; 12 tolerates real exposure while a plan runs. Then test it: if the flagged list is empty or enormous, the number is wrong for the register you actually have.
What happens when a risk goes over appetite?
It is flagged, not blocked. The flag appears in the risks table, on the risk's panel header, in the Above appetite review scope and in anything you export. Nothing is changed for you, because an over-appetite risk can be a legitimate decision. The flag exists so the decision is visible rather than assumed.
Does a category appetite override the organisation appetite?
For risks in that category, yes. RiskOS resolves appetite in a fixed order: a risk's own override first, then its category's threshold, then the organisation threshold, and if none of those is set, the risk is never flagged. The risk's Appetite section says which level supplied the number it is being held to.
Can a single risk have its own appetite?
Yes. Open the risk, find the Appetite section in its panel and switch on the override, which gives that risk its own stepper. The section also explains the threshold it would otherwise inherit, so you can see what you are departing from. Overrides survive later changes to the category and organisation thresholds.
How do I find every risk that is over appetite?
Go to Risks and switch on the over-appetite only filter; the filter icon fills while it is active. Sort by Residual to put the worst first, and use Save Current Filter… to name the view so it comes back in one click. Review offers the same population as its Above appetite scope, with a live count.
Should risk appetite be measured against inherent or residual risk?
Residual. Inherent describes the exposure before anything stands in its way, which would put almost every register permanently over appetite. Residual is what is left once the effectiveness of your linked controls is taken into account, so comparing it against a threshold answers the question that matters: is where we actually stand acceptable?