How to import controls from CSV on Mac
RiskOS takes a control catalogue from a CSV file, shows you every line before it writes anything, and re-scores the risks that lean on whatever changed.
Control catalogues rarely begin life inside a risk register. They arrive as an annex to a policy, a list kept for a certification body, or the answers somebody wrote to a customer's security questionnaire — eighty rows that already exist, already have owners and are already out of date in two places. Retyping them costs a day and introduces mistakes of its own. Bringing them in from a CSV file costs a file, a preview and one confirmation, and the risks that depend on what changed answer straight away.
Nothing is written until you agree to it. A control import opens a preview first, showing line by line what will be created, what will update an existing control, what will be skipped, any problems found and any columns it ignored.
Where control import lives
Choose Import & Export in the sidebar, under Output. It handles every part of the register that moves in and out as a file: risks, controls, assets and vendors. Each reads a CSV file, and each opens the same preview before a single row is written, so the screen you learn once is the screen you get every time.
The place the rows land is Controls, under Register. Open that first and look at the table, even while it is empty: reference, control name with its detail line, type, status, an effectiveness meter, owner, a count of linked risks, and the next review date. Those columns are the shape of your file. Seeing them makes it obvious which parts of your source list are worth tidying before the import and which can wait.
Templates for the CSV files RiskOS reads ship in its Examples folder. The control template carries the headings the import expects and a filled-in row showing what a good value looks like in each of them, which removes most of the guesswork from a first attempt.
Import a control catalogue, step by step
-
Back up the register before you import
Choose File ▸ Back Up RiskOS… or press ⇧⌘B, and save the file somewhere you will find it again, such as Documents ▸ RiskOS. The file RiskOS writes holds everything — risks, history, the audit trail, controls, actions, assets, vendors, frameworks, indicators, events and settings — and its default name carries the date, like Risk Register 2026-09-21. An import you would rather not have run then costs a minute instead of an afternoon.
-
Start from the control template
Open the control template that ships with RiskOS in its Examples folder and build your file on top of it. Keep the headings exactly as they arrive and put one control on each row. A file assembled this way imports cleanly first time far more often than one assembled from memory, because the template names every column the import knows how to read.
-
Decide which rows create and which update
A row whose control reference matches one already in your register updates that control instead of adding a second copy, and so does a row whose control name matches an existing entry. That is what turns a re-import into a correction rather than a duplication. If the catalogue is new to the register there is nothing to match against, so every row is created, each taking the next free reference from CTL-0001 onwards in the order the rows are read.
-
Write names that read on their own
Give each control a short name describing the activity rather than the intention. Quarterly restore rehearsal says what someone does and how often; Backup strategy says nothing anyone can check. Use the description column for the working detail — what runs, how often, who performs it and what it covers. The name is what appears on every risk the control is linked to, so it has to make sense a long way from this file.
-
Set the type, status and effectiveness honestly
Type records how a control works: whether it stops something happening, notices when it has, or puts it right afterwards. Status and effectiveness are the two columns that move numbers. Only controls that are implemented or operating reduce risk, so a catalogue imported entirely as planned changes no score at all, however strong those controls will eventually be. Effectiveness runs Low, Moderate, High and Very High — rate each one as it runs today, not as it was designed.
-
Add owners, review dates and the evidence behind each control
Put a person's name against every control, since a control nobody owns is a control nobody maintains. Give each one a next review date so the Review column has something to sort on and the catalogue does not quietly age. Use the evidence notes column for what proves the control runs: the report that is produced, the log that is checked, the ticket queue it is worked through. That is the column an auditor's first question lands on.
-
Open Import & Export and read the preview line by line
Choose Import & Export, choose the control import and pick your file. Nothing is written yet. The preview lists every row with what it will do — create, update or skip — names any problem it found in a value, and lists any columns it ignored. Read it properly, especially the balance of creations to updates: a screen full of creations when you expected updates means the references or names in your file do not match the ones in the register.
-
Confirm the import, then check what re-scored
Confirm and the rows are written. Open Controls and sort by the effectiveness meter to see the weakest of what has arrived, with the Risks count beside each one showing how much leans on it. Then open Risks: every risk taking its effectiveness from a control whose status or strength the import changed has already re-scored, with the new residual figure in the table and the reason on the risk itself.
What each field does once it lands
A control file is short, and every column in it earns its place by doing something visible in the register. It helps to know which ones are cosmetic and which ones change arithmetic before you decide how much time to spend on them.
| Field | What it does in the register | What to put in it |
|---|---|---|
| Reference | Matches the row to a control you already hold. References read CTL-0001 onwards and are never reissued. | The existing CTL number when you are correcting a control you already have. |
| Name | Identifies the control in the table, on every linked risk and in every report. Matches an existing control when no reference is given. | The activity, short and checkable. |
| Description | Fills the detail line under the name and the description on the control's own panel. | What runs, how often, who performs it, what it covers. |
| Type | Fills the Type column and feeds the type filter above the table. | Whether the control prevents, detects or corrects. |
| Status | Decides whether the control counts at all. Only implemented and operating controls reduce risk. | The state the control is in today. |
| Effectiveness | Fills the effectiveness meter, and sets how far the residual score falls on every risk deriving from it. | Low, Moderate, High or Very High. |
| Owner | Named on the control and carried into the controls section of a report. | One person, spelled the same way across the file. |
| Next review | Fills the Review column, so an ageing catalogue is visible by sorting on it. | The date the control is next due to be checked. |
| Evidence notes | Sits on the control's panel as the record of what proves it runs. | The artefact someone could be shown. |
Values that cannot be read as written
Files come from everywhere, so not every value will be one RiskOS recognises. Out-of-scale values are clamped to the nearest end of the scale, values it cannot interpret fall back rather than being invented, and every problem of either kind is named on its row in the preview. Nothing is guessed at silently. If the preview names more than a handful of problems, close it, correct the file at source and import again — the register is still exactly as it was.
Scores are never read from a file
A control file carries what a control is and how well it works. It does not carry risk scores, and no file can set one. RiskOS recalculates every score from the ratings on the risk and the effectiveness of the controls linked to it, so an import can never smuggle in a number that does not add up. That is what makes an imported catalogue as defensible as one typed in by hand.
Created, updated, skipped: how the preview reads
The preview is the whole safety net, and it is worth understanding rather than clicking through. Every row has exactly one outcome, and the outcome tells you whether your file matched the register the way you thought it did.
| In the preview | When it happens | What to do about it |
|---|---|---|
| Created | Nothing in the register matches the row's reference or its name. | Expected for a new catalogue. Unexpected elsewhere — check the spelling against the register. |
| Updated | The reference matches an existing control, or the name does. | Read which controls are being updated before confirming. This is the outcome you want on a re-import. |
| Skipped | The row cannot be read as a control. | The rest of the file still imports. Fix the named row and bring it in on a second pass. |
| Problem named on a row | A value is out of scale or not recognised. | Correct it at source and import again, or accept the clamped or fallback value knowingly. |
| Ignored column | The file carries a column the import does not use. | Nothing, usually. It is listed so that a column you thought was landing is never dropped in silence. |
What an import changes elsewhere in the register
Controls are not an island. They sit between the risks that rely on them and the framework requirements they answer, so a file that changes a status or a strength moves more than the controls table.
Risks re-score on confirmation
When an import changes a control's status or its effectiveness, every risk relying on that control is re-scored. A risk set to derive its effectiveness from its linked controls follows the strongest of them that is operating, so a catalogue arriving with three planned controls marked as operating will drop several residual scores at once. Sort the register by residual afterwards and read the top of it — that is where the effect of the import shows most clearly.
Hand-set values may now disagree
A risk can keep an effectiveness value you set by hand rather than following its controls. When an import moves the linked controls away from that value, the risk's panel points out the disagreement rather than quietly picking a side. Work through those warnings after a large import: either switch the risk to derive from its controls, or leave the hand-set value and know that you chose it.
Framework coverage answers too
Coverage has three honest states: covered, mapped but not operating, and not mapped. A requirement counts as covered only when a control mapped to it is implemented or operating. An import that brings a planned control into operation can therefore flip a requirement from mapped but not operating to covered without anyone touching a framework. Check Frameworks after a catalogue import for exactly that reason.
Troubleshooting
Every row says it will be created, but these controls already exist
Nothing in your file matched. Matching works on the control reference first and the control name second, so a file whose names differ by a word, a plural or a piece of punctuation reads as a list of new controls. Read the spelling off the register, correct the file and import again. The preview will then show updates, and it will still show them before anything is written.
The import went through and not one risk score moved
Three things to check, in order. First, status: controls that are planned or retired reduce nothing, so a catalogue of good intentions changes no arithmetic. Second, linking: a control only affects a risk it is linked to, and linking happens in the app rather than in the file. Third, the risk itself: a risk holding a hand-set effectiveness does not follow its controls until you switch it over.
An effectiveness value came in different from the one in my file
That is the clamping and fallback behaviour working as intended, and the preview named it on the row before you confirmed. A value beyond the ends of the scale is brought to the nearest end; a value that cannot be recognised falls back rather than being invented. Correct the source file and re-import to set it exactly, since a re-import updates the control rather than duplicating it.
A column I care about was listed as ignored
The import reads the columns it knows and lists the rest so you can see they were seen. If something you need was ignored, compare your headings with the control template in the Examples folder and rename the column to match. Anything genuinely outside a control's fields belongs in the description or the evidence notes, both of which are free text and both of which import.
I imported the wrong file
Choose File ▸ Restore from Backup… and use the backup you made before the import. RiskOS tells you exactly what a restore means and asks you to confirm before replacing anything, and an older backup always restores. This is the reason the first step of this guide is a backup rather than a suggestion.
Habits that keep an imported catalogue trustworthy
A catalogue is only useful while it still describes what the organisation actually does. A few habits keep it that way without turning imports into a project.
- Import into a backed-up register, always. One keystroke before the import turns every mistake that follows into something reversible.
- Keep one name per control. Names are how rows match when references are not in the file, so a control that is written two ways becomes two controls.
- Import statuses as they are, not as you hope. A planned control recorded as operating lowers real scores on the strength of work nobody has done yet.
- Re-import to correct rather than to add. Fix the source file and run it again; matching rows update in place, so the register converges on the file instead of accumulating copies.
- Read the ignored-columns line every time. It is the one part of the preview people skip, and it is where a quietly missing field announces itself.
- Check the risks, not only the controls. The point of a control catalogue is the effect it has on residual scores, and that effect is visible in the register within a second of confirming.
- Link the new controls to their risks afterwards. An imported control that is linked to nothing is a record, not a reduction.
- Back up again once the dust settles. The post-import register is the one you want to return to, not the one from twenty minutes earlier.
Frequently asked questions
How do I import controls from a CSV file on a Mac?
Choose Import & Export in the sidebar, under Output, choose the control import and pick your file. A preview opens showing line by line what will be created, updated or skipped, any problems found and any columns ignored. Nothing is written until you confirm. A template carrying the expected headings ships with RiskOS in its Examples folder.
Will importing controls create duplicates of ones I already have?
Not where the rows match. A control reference matching an existing control updates it, and so does a control name matching an existing entry. Anything that matches nothing is created with the next free reference. The preview tells you which outcome each row will take before you confirm, so a file full of unexpected creations can be corrected rather than imported.
Does importing controls change my risk scores?
Yes, when it changes a control's status or its effectiveness. Every risk relying on that control is re-scored as soon as you confirm. A risk that derives its effectiveness from its linked controls follows the strongest one that is operating, so bringing planned controls into operation can drop several residual scores at once.
Why did a control I imported not reduce any risk?
Most often because it is planned rather than implemented or operating. Only controls that are implemented or operating reduce risk, however strong they will eventually be. The other two causes are a control that is not linked to any risk yet, since linking happens in the app rather than in the file, and a risk holding a hand-set effectiveness instead of following its controls.
What happens if a value in my file is not recognised?
It is handled rather than guessed at. Values beyond the ends of a scale are clamped to the nearest end, values that cannot be interpreted fall back, and every problem of either kind is named on its own row in the preview. You can correct the file and import again, which updates the same controls rather than duplicating them.
Do I need to put risk scores in the control file?
No, and you cannot. Scores are never read from a file. RiskOS recalculates every score from the ratings on the risk and the effectiveness of the controls linked to it, so an import cannot set a number that the register could not defend. The control file carries what the control is, who owns it, its status and how well it works.
Can I undo a control import?
Back up first and you can return to exactly where you were. File ▸ Back Up RiskOS… writes the whole register to a single file, and Restore from Backup… puts it back after RiskOS tells you what that means and asks you to confirm. An older backup always restores. Taking that backup before an import is the habit worth keeping.
Is anything uploaded when I import a file?
No. Everything here happens on your Mac. There is no account, nothing is uploaded, and your register never leaves the machine. The file you import is read locally and the controls it creates stay where the rest of your register is, leaving only when you export or back it up yourself.