How to add a control on Mac
RiskOS keeps controls beside the risks they reduce, so a change to one is answered in the other. Here is how to record one so it counts.
A control is whatever you rely on to make a risk less likely or less damaging: the backup that runs nightly, the review someone signs off, the second supplier you keep warm. Most organisations have plenty of them and nowhere that says who looks after each one or whether it is actually running. Writing them down is what turns a residual score into something with an argument behind it.
Everything here happens on your Mac. There is no account, nothing is uploaded, and your register never leaves the machine.
Where controls live
Choose Controls in the sidebar, under Register. The middle of the window holds a sortable table of everything you have recorded — reference, name with its detail line, type, status, an effectiveness meter, owner, a count of linked risks, and the next review date. Select a row and the panel on the right opens it for editing.
Three things sit above the table. A search field covers the control's name and detail. A type filter narrows the list to one kind of control. A show-retired toggle brings back the controls you have stood down, which are kept out of your way rather than removed. References read CTL-0001 onwards, numbered in the order you create them and never reissued, so a control named in a report can always be found again.
Add a control, step by step
-
Open the Controls section
Choose Controls in the sidebar. Before adding anything, search for a word from the control you have in mind — backup, review, access — with the show-retired toggle on. Duplicates are the fastest way to make a register untrustworthy, and reviving a retired control beats creating a second copy.
-
Create the control
Press ⌘N. A new control appears with the next free reference and the panel opens ready for its name. Changes are written as you type in RiskOS, so you can leave the panel and come back to finish.
-
Name it after the thing that happens
Give the control a short name that describes the activity, not the intention. Quarterly restore rehearsal tells you what someone does and how often; Backup strategy tells you nothing you can check. If two people would read the name differently, it is not specific enough yet.
-
Describe what it actually does
Use the description for the working detail: what runs, how often, who performs it, and what it covers. This is the field that survives the person who wrote it, and it is how a successor works out whether the control still matches the risk it was linked to.
-
Set the type
Choose the type that matches how the control works — whether it stops something happening, notices when it has, or puts it right afterwards. CTL-0001, Endpoint detection and response, is recorded as Detective: it does not prevent an intrusion, it finds one. Type also drives the filter above the table.
-
Set the status honestly
Status is the field that decides whether this control changes any score at all. Only controls that are implemented or operating reduce risk. A control you intend to build is Planned, however strong it will eventually be, and RiskOS says so plainly rather than letting a good intention quietly lower a number.
-
Record the effectiveness
Set how well the control works on the effectiveness meter. Each strength carries a written descriptor, so the rating means the same thing to everyone reading it. Rate the control as it runs today, not as it was designed: a nightly backup that has never been restored from is not a strong control.
-
Give it an owner and a review date
Name the person accountable for the control still working, and set the next review date. The owner appears in the table and in reports; the review date is what stops a control drifting from operating to nominal without anyone noticing.
-
Write down the evidence
Use the evidence notes to record what you would show someone who asked you to prove the control runs: the rehearsal you completed last month, the sign-off, the report it produces. Evidence is what separates a control you can defend from one you can only describe.
Status decides whether a control counts
Of all the fields on a control, status carries the most weight, because it decides whether the control is allowed to move a residual score at all. The rule is deliberately unforgiving, and RiskOS applies it without exception.
| Status | What it means | Effect on residual risk |
|---|---|---|
| Planned | Agreed, perhaps funded, but not yet in place. | None. It reduces nothing yet. |
| Implemented | Built and in place, running as intended. | Reduces risk at its recorded effectiveness. |
| Operating | In place and demonstrably running over time. | Reduces risk at its recorded effectiveness. |
| Retired | Stood down and kept for the record. | None. Hidden from the list unless you show retired controls. |
CTL-0003, Quarterly restore rehearsal, is the example worth sitting with. It is rated High and it is still Planned, so RSK-0007 — Backup restoration has never been tested end to end — keeps a residual of 15 against an inherent of 20. The rehearsal closes that gap on the day it first runs, and not a day earlier.
Retiring a control rather than removing it
When a control stops running, set it to Retired. It leaves the working list but stays on the record with its links intact, so a residual score that rose last spring still has an explanation attached. The show-retired toggle brings it back into view.
What the effectiveness meter is saying
Effectiveness is your judgement of how much exposure this control removes when it is working. The meter in the table gives you the shape of the register at a glance; the descriptor in the panel gives you the words, so nobody has to guess what a part-filled meter meant.
Rate against evidence rather than design. A control is as effective as its worst week. Where you are unsure, rate low and write the doubt into the description; raising a rating once a rehearsal has proved the point is easier than explaining an optimistic one later.
How effectiveness reaches the risk
A risk can take its effectiveness automatically from the strongest operating control linked to it, or keep a value you set by hand. With the derive toggle on, improving a control improves the risk without anyone editing the risk. With it off, your value stands, and if it disagrees with the linked controls the risk's panel points out the divergence rather than quietly choosing a side.
Reading the controls table
Each column answers a different question, and sorting on one turns the table into a working list for a particular job.
| Column | What it tells you | Sort on it when |
|---|---|---|
| Ref | The permanent reference, CTL-0001 onwards. | You are checking against a report or an import. |
| Control | Name with the first line of the detail beneath it. | You are scanning for duplicates. |
| Type | How the control works. | You are looking for a gap in one kind of defence. |
| Status | Planned, implemented, operating or retired. | You want everything that is not yet earning its keep. |
| Effectiveness | The recorded strength, as a meter. | You are deciding where to invest next. |
| Owner | Who is accountable for it working. | You are preparing for a conversation with one person. |
| Risks | How many risks rely on this control. | You want the single points of dependence. |
| Review | When it is next due to be looked at. | You are planning the quarter. |
What a control connects to
The value of a control comes from what you attach to it, and every connection can be made from either end.
Risks
Link a control to the risks it reduces, from either end. The risk's panel lists it with its status and effectiveness, and the residual figure moves if the control qualifies. The Risks column is the quickest measure of how much a single control is holding up.
Remediation actions
When a control needs work — a rehearsal to schedule, a gap to close — record it as an action in the control's own panel. It joins every other action in Actions, grouped by due state, so work on controls sits in the same queue as work on risks.
Framework requirements
Map the control to the requirements it satisfies, from either the control or the framework. Coverage is then reported in three honest states: covered, where a mapped control is implemented or operating; mapped but not operating; and not mapped at all. The middle state is the useful one.
Troubleshooting
I added a control and no risk score changed
Two things have to be true before a control moves a number: it has to be linked to the risk, and it has to be implemented or operating. Open the risk, check the Controls section lists it, then check the status. A Planned control appears in the list and contributes nothing.
The risk says my value disagrees with its controls
That is the divergence warning: the effectiveness set by hand on the risk is not what the linked controls would produce. Decide which you trust. Switch the derive toggle on to follow the controls, or keep your value and note in the risk's description why you are overriding it.
I cannot find a control I know I recorded
Check the two filters above the table. With a type filter set, controls of every other type are hidden; with the show-retired toggle off, a control you stood down will not appear. Clear both and search for one distinctive word rather than the whole name.
One control covers several risks and I have copied it
Record it once and link it to all of them. Duplicating a control splits its history and makes the Risks count meaningless. Where copies already exist, link the risks to the one you are keeping, unlink them from the rest, and retire the copies.
I edited one control and several risks moved
Editing a control's status or effectiveness re-scores every risk that derives from it, immediately. That is what the link is for. Each affected risk records the new assessment in its History, so the reason for the movement stays on the record.
Habits that keep a control register honest
- Add the control when you add the risk. The moment you know how you will reduce something is the moment you understand the control best. Link it there and then.
- Be strict about status. Planned means planned. The day a control first runs is the day its status changes, and the register shows the improvement then rather than in advance.
- Rate effectiveness from evidence. Put the proof in the evidence notes and let the rating follow it. A rating nobody can support is the first thing an auditor will test.
- Give every control an owner. A control without a name against it belongs to nobody and degrades quietly. The owner column is the fastest way to find the orphans.
- Sort on Risks once a quarter. The control at the top of that list is your largest single dependency, and deserves the most convincing evidence.
- Review controls on a cadence, not on a crisis. Set a next review date on each one and work the list the way you work overdue risks.
- Bring a catalogue in rather than retyping it. Controls import from CSV with a preview of what will be created, updated or skipped, and every risk relying on a changed control re-scores once you confirm.
Frequently asked questions
How do I add a control in RiskOS?
Choose Controls in the sidebar and press ⌘N. A control appears with the next reference, CTL-0001 onwards, and the panel opens for its name, description, type, status, owner, effectiveness, next review date and evidence notes. Changes save as you type. Link it to the risks it reduces from either end.
Why does my new control not reduce any risk score?
Because only controls that are implemented or operating reduce risk. A planned control, however strong it will be once it runs, reduces nothing yet, and RiskOS says so rather than letting an intention lower a number. Check too that the control is actually linked to the risk — an unlinked control changes nothing anywhere.
What is the difference between a control's status and its effectiveness?
Status says whether the control is running: planned, implemented, operating or retired. Effectiveness says how much of the exposure it removes when it is running, on a meter whose strengths each carry a written descriptor. Status decides whether the control counts at all; effectiveness decides how much it counts for.
Can one control be linked to more than one risk?
Yes, and it should be. Record the control once and link it to every risk it reduces. The Risks column counts those links, which is the quickest way to find the control most of your register depends on. Editing that control re-scores every risk deriving from it at once.
How do I record evidence for a control?
Each control has evidence notes in its detail panel. Write what you would show someone who asked you to prove it runs: the date of the last rehearsal, who signed it off, what report it produces and where that report goes. Keeping the evidence beside the control means the rating and its proof never drift apart.
What happens if I delete a control I no longer use?
Set it to Retired instead. A retired control leaves the working list but stays on the record with its links intact, so a residual score that rose when the control stopped still has its explanation attached. The show-retired toggle above the table brings retired controls back into view whenever you need them.
Can I import a list of controls instead of typing them?
Yes. Controls import from CSV, with a mandatory preview that shows line by line what will be created, updated or skipped, any problems and any columns it ignored. A reference matching an existing control updates it, and when an import changes a status or an effectiveness, every risk relying on that control is re-scored.
How does a control affect framework coverage?
Map the control to the requirements it satisfies, from either side. A requirement reads as covered only when a mapped control is implemented or operating. Where the control is mapped but not yet running, coverage reports it as mapped but not operating, which keeps the gap visible instead of counting an intention as protection.