How to change whether controls reduce likelihood or impact on Mac
You can do this with RiskOS, a risk register for macOS. One choice in Methodology, and every residual score in the register answers to it.
Two registers can hold the same risks, the same ratings and the same controls, and still disagree about what is left after treatment. The difference is usually one methodology choice: whether the strength of a control comes off the likelihood, off the impact, or off both. It is a small setting with a long reach, because every residual score in the register is worked out through it.
Changing this setting re-scores every risk straight away. Nothing you typed is lost: your inherent ratings and your control effectiveness stay exactly as they were. What moves is the residual score calculated from them, and everything that follows from it.
Where the choice lives
Press ⌘, to open Settings, which is a section of the same window rather than a separate one. Settings has three parts — Methodology, Appetite and Privacy. Methodology holds the likelihood and impact scales, the band thresholds, and with them the setting this page is about.
The effect is easiest to watch inside a risk. Choose Risks in the sidebar, select a row, and open Assessment. The matrix there carries three markers: inherent, residual and target. Change the methodology and the residual marker glides to the cell the new rule puts it in, while the inherent marker stays exactly where you rated it.
The Controls section of the same panel holds the linked controls and the effectiveness the risk is working from. That is the input. Methodology is the rule that turns it into a number, and RiskOS shows the working in the comparison grid below the matrix, so you can see which of the two you need to change.
Change what your controls reduce
-
Back up the register first
Choose File ▸ Back Up RiskOS… or press ⇧⌘B, and save the file wherever you keep your records. One backup carries the whole register, its history and your settings, so you have a fixed point to compare against once everything has re-scored. RiskOS asks where you want to save it, and the suggested name carries the date, so a run of backups sorts itself into order.
-
Note where the register stands today
Open Risks and switch on the over appetite only filter, then write down how many rows it leaves. Add the band filter if you want a finer picture. A minute spent here turns "everything moved" into a short list of risks that genuinely crossed a line.
-
Open Settings and choose Methodology
Press ⌘, and choose Methodology. It shows the five likelihood ratings, the five impact ratings, the thresholds that separate Low, Medium, High and Critical, and the setting that decides what control effectiveness reduces.
-
Decide which axis your controls actually move
Look at the controls you rely on most and ask what they do when they work. A control that keeps the event from occurring reduces likelihood. A control that limits what the event costs once it has happened reduces impact. If your register carries a mixture, and most do, both is the honest answer.
-
Choose likelihood, impact or both
Select the option you settled on. It applies to the whole register immediately, with no separate recalculation to run. Nothing you rated is edited: the inherent likelihood and impact on every risk, and the effectiveness on every control, stay as you left them.
-
Watch the register re-score
Return to Risks. Every residual score, band badge and matrix marker now follows the new rule, and so does every place a residual appears: the table, the dashboard, each risk's comparison grid, and the line that tells you what strength of control would reach the target.
-
Check what crossed a band or an appetite line
Switch the over appetite only filter back on and compare the count with the one you noted. Risks that have newly crossed the threshold need their owner told and their treatment plan read again. Risks that dropped below it deserve a look too: none should leave the watch list on arithmetic alone.
-
Refresh any client profiles
A profile keeps its own snapshot of the methodology, so a change in Settings does not reach the others by itself. Cycle through them with ⌃⌘P and choose Update from Current Settings on each one you want to follow the new rule. Leave a client on the old rule if that is what was agreed with them.
-
Re-issue anything you have already sent
A report is a snapshot of the register at the moment it was made, so anything exported before the change still carries the old numbers. Make a fresh one: ⇧⌘P exports a PDF and ⇧⌘E exports HTML.
What each option does
The three options are not three levels of strictness. They are three descriptions of how your controls behave, and the right one is whichever matches the controls you have actually recorded.
| Setting | What control effectiveness reduces | Where the residual marker moves | Suits a register whose controls |
|---|---|---|---|
| Likelihood | The likelihood rating only. Impact stays as you rated it. | Along the likelihood axis, at the same impact | mostly stop events happening |
| Impact | The impact rating only. Likelihood stays as you rated it. | Along the impact axis, at the same likelihood | mostly limit the damage afterwards |
| Both | Both ratings. | Diagonally, across both axes at once | do some of each |
Likelihood, for controls that stop the event
Choose likelihood when the controls you rely on exist to keep the event from occurring at all. Access reviews, patching regimes, supplier due diligence and segregation of duties all work this way: when they hold, nothing happens. What they do not change is how bad the day would be if they failed. A prolonged outage costs what it costs, whether or not you reviewed privileged access last quarter.
Impact, for controls that limit the damage
Choose impact when your controls are about containment and recovery. CTL-0002 Immutable offsite backups does not make ransomware less likely to arrive; it makes the day survivable. Failover arrangements, rehearsed recovery procedures, transferring the cost elsewhere and a second supplier all belong in the same family.
It keeps a register honest that would otherwise flatter itself. RSK-0001 Ransomware encrypts primary file shares is not rarer because you have good backups, and a rule that pretended otherwise would understate how often you should expect to be tested.
Both, for a mixed control set
Most registers land here. A risk sitting behind a detection control and a recovery control really is both less likely and less expensive. Choosing both applies the reduction to each factor of the score, so the residual falls further than under either single axis for the same strength of control. That is not leniency; it is what multiplying two smaller numbers does.
Why the same control gives different numbers
A score is likelihood multiplied by impact, so where a reduction is taken from decides how much of the score it removes. Take a risk rated Likely and Minor: four times two is eight, a Medium. Move one step down the likelihood and it scores six, still Medium. Move the same single step down the impact instead and it scores four, which is Low. Same risk, same control, one band apart.
Further up the scale the two options converge. A risk at Likely and Severe scores twenty and sits in Critical. A step off the likelihood gives fifteen; a step off the impact gives sixteen. Both are High, and the practical answer is the same either way.
The effect is largest where the two ratings sit furthest apart. A frequent nuisance with a small consequence, and a rare event with a catastrophic one, are exactly the rows that respond differently to the setting.
The floor of the scale
Scores do not fall below one, and no rating drops below the bottom of its scale. A risk already rated Rare has nowhere further to go on the likelihood axis, so under a likelihood-only rule even a strong operating control leaves its residual where it is. If a group of rare, severe risks refuses to move whatever you link to it, that floor is usually the reason.
What changes when you switch, and what does not
The switch changes calculated values. It does not change anything you typed.
| In the register | What the switch does to it |
|---|---|
| Inherent likelihood and impact | Nothing. These are your ratings and they are never rewritten. |
| Control effectiveness | Nothing. The strength recorded on each control is unchanged. |
| Residual scores | Recalculated for every risk at once, including risks whose effectiveness you set by hand. |
| Bands, badges and matrix markers | Follow the new residual, wherever they appear. |
| Over-appetite flags | Re-evaluated against the new residual, in the table, on the dashboard and in reports. |
| Target ratings | Nothing. The pair you set stays put; what moves is the gap to it. |
| The suggested control strength | Restated, because it is now answering a different question. |
| Actions, indicators, events, assets, vendors, framework coverage | Nothing. |
| Reports and exports already made | Nothing. They are snapshots and keep the numbers they were made with. |
Because your ratings survive untouched, the change is reversible: choose the previous option and the register re-scores from the same inputs, arriving back where it was.
Rules that hold whichever option you choose
Four things stay true regardless of the setting.
A residual score never exceeds its inherent score. Controls reduce exposure; they cannot manufacture it. No setting will push a treated risk above the rating you gave it untreated.
No score falls below one. The scale has a bottom, and the arithmetic respects it rather than producing a zero that would suggest a risk had been eliminated.
A stronger control never raises a score. If strengthening something appears to have pushed a number up, the cause is elsewhere — a re-rated inherent likelihood, or a different control that changed status at the same time. The risk's History keeps every assessment with the reason behind it, which is the fastest way to find out which.
Only implemented or operating controls reduce anything. CTL-0003 Quarterly restore rehearsal is recorded at high effectiveness, but while its status is Planned it reduces nothing at all, and RiskOS says so on the control and on every risk that links to it. Changing the methodology does not soften that, and no setting will make a plan behave like a running control.
Troubleshooting
Every residual score changed and nobody edited a risk
Two things produce a register-wide move without a single risk being touched. Someone changed the methodology in Settings ▸ Methodology, or the app is showing a different profile. Each profile carries its own snapshot of the methodology, so switching to a client's profile can present the same risks scored under a different rule. Check the profile in the sidebar footer before you go looking any further.
One risk did not move when the rest did
Open it and look at Controls. A risk with no linked control, or with only planned controls in front of it, has no effectiveness to apply, so no methodology will move its residual away from its inherent score. The other common cause is the floor of the scale: a rating already at its lowest point on the axis your setting reduces cannot go lower.
Far more risks are now above appetite
That is the switch doing its job. Appetite compares a threshold with the residual score, so moving every residual moves the flags with it. Decide which number was wrong: if the register now describes your controls accurately, the threshold in Settings ▸ Appetite may be what needs revisiting, per category rather than across the board.
The report I sent last week does not match the app
Reports are made from a snapshot, which is what lets the PDF, the HTML file, the workbook and the printed copy agree with one another. A file made before the change keeps the rule it was made under. Export again, and note in the executive summary that the scoring rule changed, so the difference reads as a decision rather than a mistake.
Habits that keep the choice defensible
- Back up before you switch. ⇧⌘B takes a few seconds and gives you a file you can compare against, or restore from, with no argument about what the numbers used to be.
- Write the reason down where it will be read. Put the choice and its justification into the executive summary. A residual score is defensible only if the rule that produced it is stated somewhere.
- Keep control status honest. The setting decides which axis moves; control status decides whether anything moves at all. A control left at Planned for six months makes the register look worse than it is.
- Refresh profiles deliberately. Update from Current Settings brings a profile in line with the change. Leaving a client on the methodology you agreed with them is a legitimate choice, as long as it is a choice.
- Re-score in one pass afterwards. Review walks the risks that are due, worst first, with the full context beside the scoring inputs. It is a sound way to sanity-check a register that has moved.
- Leave it alone once it is right. The setting describes your controls, not your mood about them. Changing it often leaves the score history on every risk hard to read.
Frequently asked questions
Should controls reduce likelihood or impact?
It depends on what your controls do. Controls that stop an event happening reduce likelihood. Controls that limit the damage once it has happened reduce impact. Most registers carry both kinds, so the "both" option is the usual honest answer. RiskOS applies whichever you choose to every risk, so the register stays consistent.
Does changing the scoring methodology rewrite my risk ratings?
No. The inherent likelihood and impact you set on each risk are never rewritten, and neither is the effectiveness recorded on any control. Only the calculated residual scores change, along with the bands, matrix markers and appetite flags that follow from them. Choose the previous option and the register returns to where it was.
Why did my residual scores change when I switched client profiles?
Each profile keeps its own snapshot of the methodology and the risk appetite, so one client can be scored under a different rule from another. Switching profiles presents the register under that profile's methodology. Use Update from Current Settings when you want a profile to adopt the rule now in Settings.
Can different risks use different scoring rules?
Not within one register, and deliberately so. A register earns its value from comparison, and rows scored under different rules cannot be sorted against each other honestly. The choice is made once in Settings ▸ Methodology and applies everywhere. Appetite is the setting that varies by category, not the scoring rule.
Does this setting change my target risk scores?
No. A target is a pair of ratings you set yourself, so it stays exactly where you put it. What changes is the distance to it, and the line in the comparison grid that tells you what strength of control would close the gap. Under a different rule, that answer is naturally a different one.
What happens to risks whose only controls are planned?
They do not move, whichever option you choose. Only controls that are implemented or operating reduce risk, so a planned control reduces nothing yet however strong it will be when it runs. RiskOS states this on the control and on each risk linked to it. Set the status once the control is genuinely working, and every risk deriving from it re-scores.
Does changing the methodology send anything anywhere?
No. Everything here happens on your Mac. There is no account, nothing is uploaded, and your register never leaves the machine. The re-scoring runs locally and immediately, and your register leaves the Mac only in a file you export or back up yourself.