Controls & Treatment

What makes a control actually reduce risk

Every control in RiskOS, a risk register for macOS, either moves a number or it does not. Four conditions decide which, and the register is honest about all four.

A risk register loses its credibility at the same quiet point. A long list of controls accumulates, every one of them real work done by real people, and the risk scores beside them barely move. Nobody is lying. The controls are recorded, but nothing in the record yet says they stand between the organisation and the thing it fears. Four conditions decide whether a control reduces a number, and it is worth knowing all four before someone asks why.

Note

A residual score in RiskOS always shows the reasoning behind it. When a control is not moving a number, the panel says what it is waiting on rather than leaving you to work it out.

Where the proof of a control lives

Two places hold the answer, and they are meant to be read together. Choose Controls in the sidebar for the control's own record: a sortable table of Ref, Control with its detail, Type, Status, an effectiveness meter, Owner, a Risks count and a review date. Glance at the Risks count first, because a control linked to nothing reduces nothing, whatever it says about itself.

Then choose Risks, select the risk you are questioning and open the Controls section of its panel. That list shows each linked control with its status and its effectiveness side by side, along with the toggle that decides whether the risk takes its residual score from those controls or from a value somebody typed. Between the two views you can see both halves of the claim: what the control is, and what the register is prepared to credit it with.

Check whether a control is really reducing a risk, step by step

  1. Open the risk you are questioning

    Choose Risks in the sidebar and select the row whose score looks wrong — usually one where the inherent and residual figures sit closer together than the effort spent on it would suggest. The panel opens with the reference, the band badge and the trend at the top.

  2. Read the linked control list

    Open the Controls section of the panel. Every linked control appears with its status and its effectiveness. Read the statuses first and the strengths second, because a strength only counts once the status has let it through.

  3. Unlink anything that does not genuinely stand between this risk and the event in its title. A control linked because it is adjacent in subject matter inflates the count in the table and teaches everyone to stop reading the list. Unlinking leaves the control itself untouched and available to the risks it does reduce.

  4. Check the status of the strongest control

    Open the control that is meant to be doing most of the work and read its status. Only controls that are implemented or operating reduce a score. If it reads planned, it is reducing nothing yet, however strong it will be once it lands. Set the status to what is true today, not to what was agreed in a meeting.

  5. Test the strength against the evidence

    Read the effectiveness rating and its descriptor, then the evidence notes beneath it. If the notes do not describe something observed — a rehearsal, a sample, a report someone read — the rating is an opinion and should come down until it can be supported. Editing the strength re-scores every risk deriving from this control immediately.

  6. Confirm the risk is deriving from its controls

    Back on the risk, check the derive-from-controls toggle in the same section. With it on, the residual follows the strongest operating control. With it off, the risk keeps a value set by hand, and a control could improve all year without the score noticing. A divergence warning means the hand-set value and the linked controls disagree, and one of them is out of date.

  7. Read the residual and the gap it leaves

    Open Assessment and read the comparison grid: inherent, residual, target and the distance between them, with the matrix markers showing the same thing spatially. Beneath it sits the line that answers the real question — what strength of control would reach the target you have set.

  8. Turn whatever is missing into an action

    If the control is planned rather than operating, or rated below what the target needs, raise a remediation action in the control's own panel with an owner and a due date. It appears in Actions with the rest of the register, grouped by how late it is, so the gap is tracked as work rather than as a note in a description.

The four conditions

None of these is a hurdle for its own sake. Each answers a question an auditor, a regulator or a new chief executive will eventually ask, and each is set somewhere you can point at.

The four conditions a control must meet before it reduces a risk score
ConditionThe question it answersWhere it is set
LinkedDoes this control stand between this particular risk and the event described in its title?The Controls section of the risk's panel
LiveIs it implemented or operating today, rather than agreed or retired?The control's status
RatedHow much of the exposure does it actually remove, and what evidence says so?The control's effectiveness and evidence notes
DerivedIs the risk reading its controls, or holding a number somebody typed?The derive-from-controls toggle on the risk

Miss any one and the arithmetic stops. That is the design: a register that lowered scores on the strength of good intentions would be confidently wrong in the direction that gets organisations hurt.

Status is the condition most registers fail

Of the four, status catches the most people. A control is written up in the week it is approved, rated for the strength it will have when finished, then left at planned for a year while everyone reads the strength and assumes the risk is covered. RiskOS refuses that reading, and says so on the control rather than ignoring it quietly.

What each control status does to the score of a linked risk
StatusReduces a linked risk?What it is telling you
PlannedNoThe work is agreed and not yet done. The strength is a forecast, not a claim.
ImplementedYesIt exists and is in place. Its rated strength now counts against every risk it is linked to.
OperatingYesIt is running and being used, and there should be evidence of it running.
RetiredNoIt has been stood down. Any score that leaned on it rises back towards the inherent figure.

A planned control still earns its place

Record it anyway. A planned control with an owner, and a remediation action carrying a date of its own, is a treatment plan somebody can be asked about, and it shows a reviewer the gap is known rather than missed. It does not move a number until it is real. When it goes live, change the status and every risk deriving from it re-scores at once.

Retiring rather than quietly dropping a control

When a control is withdrawn, set it to retired. The scores that depended on it rise, which is uncomfortable and correct: the exposure went back up the day the control stopped. The controls table has a show-retired toggle, so retired controls stay out of the way without disappearing from the record of what you used to rely on.

Strength decides how far a score moves

Once a control is linked and live, its effectiveness rating decides the size of the reduction. A risk deriving from its controls follows its strongest operating control. That single rule explains most of the surprises people meet in their first month with a register.

It means a second, weaker control on the same risk changes nothing about the score. Defence in depth is real and worth recording — it protects you when the primary control fails — but the register will not count it twice, because there is no honest way to know how independent two controls are. It also means one control raised from moderate to high can move several risks at once, which is why editing a control is never a local change.

Changes that move a derived residual score, and changes that do not
What you changeWhat happens to the residual
A planned control becomes operatingThe score falls, if that control is now the strongest one operating
The strongest operating control is rated higherThe score falls
A second, weaker operating control is linkedNo change. The strongest control is already setting the pace
The strongest operating control is retiredThe score rises back towards the inherent figure
A control is unlinked from the riskThe score is recalculated from what is left
The inherent rating is raisedBoth figures are recalculated from the new exposure
Methodology changes which rating controls reduceEvery risk in the register re-scores immediately

What the arithmetic will never do

Three guarantees hold everywhere in the register, and they are worth quoting when somebody suspects the numbers. A residual score can never exceed its inherent score, because controls do not make an exposure worse than having none. It never falls below 1, because no control removes a risk entirely. And a stronger control never raises a score, so improving a control is always safe to record.

Which rating a control reduces

One choice in Settings ▸ Methodology sits behind all of this: whether controls reduce likelihood, impact or both. Preventive measures plausibly reduce likelihood; a rehearsed recovery reduces impact. Decide which model your organisation reports against, set it once and leave it alone — changing it re-scores every risk immediately, which is the right behaviour and a disconcerting thing to do the week before a board pack goes out.

A worked example, end to end

Take RSK-0007, Backup restoration has never been tested end to end, owned by M. Halvorsen in Business Continuity. Its inherent score is 20 and its residual is 15, which looks strange for a risk with two controls linked to it and a target of 4.

The two controls explain it. CTL-0002, Immutable offsite backups, is operating and rated moderate, so it is the control doing the work and the residual reflects its strength. CTL-0003, Quarterly restore rehearsal, is rated high, and it is the control that would genuinely address this risk, since the risk is about untested restoration rather than absent copies. Its status is planned, so it contributes nothing — and nothing next quarter either, unless the rehearsal starts happening.

So the register shows a residual of 15 against an appetite of 9, six points over, flagged on the row, on the dashboard and in the report. The comparison grid names the strength of control that would reach the target of 4. The honest response is not to re-rate anything: raise a remediation action against CTL-0003 with an owner and a date, run the first rehearsal, set the status to operating, and let the score fall on the strength of something that happened.

What a live control counts for elsewhere

The same status that gates the score gates the rest of the register, which keeps every view telling the same story.

Framework coverage uses the same test

Map controls to the requirements of a framework and Frameworks reports coverage in three honest states: covered, where a mapped control is implemented or operating; mapped but not operating, where the intent exists and the control does not run yet; and not mapped, where nothing has been claimed at all. The middle state is the one worth reading. A framework that showed a requirement as covered because a planned control had been pointed at it would be telling you exactly the thing you least want to be wrong about.

Appetite and the flag that follows it

A risk whose residual sits above the appetite threshold is flagged everywhere it appears. Because the residual is derived from live controls, that flag clears when a control genuinely starts working and not before. It is the closest thing a register has to an alarm that cannot be turned off by editing a description.

Evidence is what makes the rating survive a question

Each control carries evidence notes and a next review date. The notes are where you record what you saw: the date of the last restore test, the sample of access reviews you checked, who confirmed the alerting fires. A strength rating with evidence behind it survives being asked about a year later. One without it will be the first thing challenged, and challenged successfully.

Troubleshooting

Several controls are linked and the residual has barely moved

Look at the statuses, then the strengths. The residual follows the strongest operating control, so a risk with four linked controls of which one is operating at moderate strength scores exactly as though that were the only control. Adding weaker controls beside it changes nothing; raising that one, or bringing a stronger planned control into service, changes everything.

Our best control is rated high and nothing happened

Its status is almost certainly planned. A rating describes how much a control would remove if it were running; the status decides whether it is running. Open the control, set the status to implemented or operating once that is true, and every risk deriving from it re-scores as you do it.

A score moved on a risk nobody opened

Controls are shared, so a change in one place lands in several. Someone retired a control, lowered a strength, or ran an import that updated a control's status, and every risk deriving from it was re-scored. Open the risk's History to see the assessment that was recorded and the score it produced.

The risk panel says my value disagrees with the linked controls

That is the divergence warning: the effectiveness set by hand on the risk does not match what the linked controls support. Neither value is deleted and nothing is chosen for you. Decide which is out of date — usually the hand-set number was right months ago and the controls have moved since. Switching the risk back to deriving from its controls settles it for good.

No control we could build would reach the target

Then the target needs revisiting, or the treatment strategy is wrong. The comparison grid names the strength that would be required; if that is not achievable at any sensible cost, the honest answers are transfer, avoid, or accept with a recorded rationale. A target nobody can reach is not ambition. It is a permanent red row everyone learns to scroll past.

Habits that keep controls honest

  • Rate the control, not the team. The effectiveness field is a claim about how much exposure is removed, not an assessment of how hard anybody worked on it.
  • Change the status the day reality changes. A control that went live in March and still reads planned in September has been quietly understating your position for six months.
  • Read the Risks count in the controls table. A control linked to nothing is either mislinked or unnecessary, and both are worth ten seconds of attention.
  • Leave risks deriving from their controls. A derived residual explains itself. A typed one is a number with nothing behind it, and it will be the first figure anyone challenges.
  • Write the evidence as you find it. The note takes a minute during the review and saves an afternoon of reconstruction when somebody asks how the rating was reached.
  • Treat a planned control as work, not as cover. Give it a remediation action with an owner and a date so it appears in the register's list of what is overdue.

Frequently asked questions

When does a control start reducing a risk score?

The moment its status says it is implemented or operating, provided it is linked to the risk and the risk is deriving its effectiveness from its controls. RiskOS re-scores every risk relying on that control immediately. Until the status changes, the control's rated strength is a forecast and the score stays where it is.

What makes a control effective rather than merely present?

Three things together: it is running rather than planned, it addresses the specific event in the risk's title, and someone can show evidence that it worked recently. A control that meets all three earns a high strength rating. One that exists on paper, or that reduces a neighbouring problem, does not, however well documented it is.

Why is my residual risk still high when we have many controls?

A derived residual follows the strongest control that is actually operating, not the number of controls linked. Check the statuses first: a list of planned controls reduces nothing. Then check the strengths, since several moderate controls score the same as one moderate control. Raising the strongest control, or bringing a stronger one into service, is what moves the number.

Is a risk with five controls safer than one with two?

Possibly in reality, but not in the score. RiskOS takes the strongest operating control rather than adding effectiveness together, because there is no honest way to know how independent two controls are. Record every control you rely on for the day the primary one fails, and expect the residual to reflect the best of them rather than the count.

Can a control ever make a risk score worse?

Not by being improved. A stronger control never raises a score, and a residual can never exceed its inherent score or fall below 1. A score does rise when a control is retired or downgraded, which is not the control making things worse but the register recording that the protection you were counting on is no longer there.

How do I prove a control is working?

Use the evidence notes on the control. Record what was observed and when: the date of the last test, the sample you checked, who confirmed it. Set a next review date so the claim is revisited rather than inherited. A report can then carry the controls section alongside the risks, with the strengths those notes support.

Do controls reduce likelihood or impact?

Whichever your methodology says. Settings offers three models — controls reduce likelihood, reduce impact, or reduce both — and the choice applies to the whole register. Changing it re-scores every risk immediately, so decide it early and leave it alone. Preventive controls fit the likelihood model; recovery and continuity controls fit the impact model.

What does "mapped but not operating" mean in framework coverage?

A control has been mapped to that requirement, but its status is not yet implemented or operating, so the requirement is not genuinely covered. RiskOS shows it as its own state rather than counting it as covered or as a gap. It is the most useful state on the coverage view, because it lists exactly the work that is already agreed and not yet done.