How to import a control framework on Mac
Do it in RiskOS, a risk register for macOS. Your catalogue, your identifiers, and a preview that shows what a revision would change before it changes anything.
Most organisations are measured against a catalogue nobody ships: an internal control standard, a customer's security schedule, a sector code with numbering of its own. Those are the requirements that turn up in the questionnaire and in the audit, so those are the ones your coverage ought to answer. Bringing the catalogue in takes a file and a confirmation, and from then on your controls map to it exactly as they map to anything else.
Nothing is replaced until you agree to it. A framework import opens a preview first, showing what the file adds, removes and retitles, and how many of your existing mappings survive.
Where frameworks live
Choose Frameworks in the sidebar, under Reference. The list holds every catalogue the register knows about: the ones RiskOS ships and the ones you bring in yourself. Each is labelled with exactly what it is, so nobody has to guess whether they are reading a full standard or a structure held at category level.
Open a framework and its requirements group by their source group, in catalogue order, with a search field and a coverage filter above them. The order matters more than it sounds. A catalogue read out of sequence stops matching the document the auditor has open on the other side of the table, so the order in your file is the order you get back.
Import your own catalogue, step by step
-
Name the catalogue and its revision
Decide the name you want to see in the list before you touch the file, and put the revision inside it — the year, the version, the issue number, whatever the source document carries. A framework called Security Standard becomes a problem in eighteen months. One called Security Standard 2026.1 tells the next person which edition their coverage was measured against.
-
Settle the requirement identifiers
Every requirement needs an identifier, and it should be the one the source document uses rather than something invented for the import. Identifiers are what a later revision is matched against: where an identifier is unchanged, the mapping work you did carries over; where it changes, the requirement reads as brand new. Ten minutes spent here saves the whole of that work later.
-
Prepare the catalogue as CSV or JSON
RiskOS accepts a catalogue in either form. Each requirement is one entry carrying its identifier, its title and the group it belongs to, and the sequence you list them in is the sequence they will be read in. Keep the file somewhere you can find it again, such as Downloads, and give it the same name as the framework so the two are never confused.
-
Start the import from Frameworks
Choose Frameworks in the sidebar and begin an import of your own catalogue, then choose the file you prepared. Nothing is written at this point. The file is read, compared against what the register already holds, and handed back to you as a summary of the difference.
-
Read the preview before you agree to anything
The preview is the part worth slowing down for. It says how many requirements the file adds, how many it removes, how many it retitles, and — the figure most people look at first — how many of your existing mappings survive the change. Read the removals with particular care, because a requirement that disappears takes its place in your coverage with it.
-
Confirm the import
When the summary matches what you expected of this revision, confirm it. The catalogue is replaced in a single move, mappings whose identifiers still match stay attached to their requirements, and the framework appears in the list under the name you gave it. If the summary does not match, leave it, correct the file and come back. Until you confirm, the register is untouched.
-
Map your controls to the requirements
Open the framework and work down the groups, attaching the controls that satisfy each requirement. Mapping works from either side, so you can instead open a control and attach the requirements it answers — usually the quicker route when one control covers a dozen clauses scattered across the catalogue.
-
Read coverage and work the gaps
With the mapping done, the framework shows its coverage at a glance, and the coverage filter narrows the list to the state you want to work on. Begin with anything that reads as mapped but not operating: the control already exists, so the job is finishing it rather than inventing it.
What a requirement carries
A catalogue is a list of requirements, and each requirement is a small, fixed set of facts. Understanding what each one does is most of what makes an import behave the way you expected.
| Part | What it is | What it decides |
|---|---|---|
| Identifier | The clause or control number the source document uses. | How a later revision is matched. Keep it exactly as published. |
| Title | What the requirement asks for, in one line. | What you read in the list, and what appears in a report's framework coverage section. |
| Group | The section, function or domain the requirement sits under. | How the list is grouped, and therefore the shape of the whole catalogue. |
| Position | Where the requirement falls in the file. | The order requirements are shown in, kept as given rather than sorted. |
Titles that survive a meeting
Write the title as the requirement itself would be read aloud, not as a summary of your answer to it. Access rights are reviewed at least quarterly survives being read by somebody who has never seen the standard. Access review does not, and it makes the coverage list harder to work down when thirty requirements share a two-word heading.
CSV or JSON
The two forms describe the same catalogue, and the framework that results is identical either way. Use whichever the document arrived in. A standard that reached you as a table is already close to CSV, and reshaping it rarely improves anything.
JSON tends to be the easier form when group names carry commas, quotation marks or long parenthetical phrases, because the structure is explicit rather than positional. It is also the steadier form for a catalogue you maintain yourself across several revisions, because the identifier, the title and the group stay clearly separated as the document grows. Neither is treated as the better choice, and you can move between them at the next revision without losing mappings, since the matching is done on identifiers rather than on the shape of the file.
Re-importing a revised catalogue
Standards are revised, and a register that cannot follow a revision quietly goes stale. Re-importing is the same act as importing: choose the newer file, read the preview, confirm. What changes is that the preview now has something to compare against, and it tells you the four things you need to know before agreeing.
| Reading | What it means | What to do about it |
|---|---|---|
| Adds | Requirements in the file the register has not seen before. | Expected after a revision. They arrive unmapped, and they are your new work. |
| Removes | Requirements held now that the file no longer contains. | Check every one. A withdrawn clause is fine; a renumbered clause means an identifier moved. |
| Retitles | Requirements whose identifier matched but whose wording changed. | Read the new wording. A retitled requirement sometimes asks for more than it used to. |
| Mappings kept | How many of your control mappings survive the replacement. | Compare it against what you had. A low figure nearly always means identifiers moved. |
Why identifiers decide everything
Mapping work is held against the requirement's identifier, so that is the hinge the whole revision turns on. Where identifiers survive, your mappings survive with them and the new catalogue arrives already covered. Where a publisher renumbers a section, or where somebody trimmed a prefix while tidying the file, the old requirement reads as removed and the new one as added, and the mapping between them is the thing that falls through the gap. That is why the preview exists, and why it is worth reading rather than clicking past.
When a requirement disappears
A removal is not always a loss. Standards withdraw clauses, merge two into one and fold whole sections into a successor. The question is only whether the removal you are looking at is deliberate on the publisher's part or accidental on yours. If the figure for removals is larger than the revision's own change notes suggest, the file is the likelier culprit. Nothing has been replaced yet, so correcting it costs you a minute.
How coverage reads on your own catalogue
Once the catalogue is in, it behaves exactly like a framework that shipped with RiskOS. Coverage has three states rather than two, and the middle one is the reason the reading can be trusted.
| State | What is true | What it is telling you |
|---|---|---|
| Covered | A mapped control is implemented or operating. | Something real stands behind the requirement today. |
| Mapped but not operating | A control is attached, but it is planned rather than running. | The intention exists. The protection does not, yet. |
| Not mapped | No control is attached to the requirement at all. | Either a genuine gap, or mapping work still to do. |
Collapsing the middle state into "covered" is how a coverage figure becomes a story rather than a measurement. Keeping it separate means the number on the page matches what an assessor would find, and it gives you the most useful queue in the whole exercise: the requirements where the work is nearly done.
The frameworks that come with RiskOS
Two catalogues ship with RiskOS, and both say plainly what they are. The Control Baseline 1.0 is a general starting set for an organisation that has no external standard imposed on it. The NIST Cybersecurity Framework 2.0 structure is carried at category level, labelled as the structure rather than presented as the full text of the standard, so nobody mistakes the one for the other.
Neither can be deleted, which keeps a reference point in the register whatever else you bring in. Your own catalogue sits alongside them, and a control can map to requirements in more than one framework at once — which is usually the point, since the same access review tends to answer three different documents.
Troubleshooting
The preview says almost none of my mappings will survive
Identifiers have moved. Compare a handful of requirements in the new file against the same clauses in the register: a prefix dropped, a leading zero removed, a dot turned into a dash, and nothing matches any more. Restore the identifiers to their published form and re-read the preview. Since nothing is replaced until you confirm, you can do this as many times as it takes.
Requirements are in an order I did not expect
The order comes from the file, not from the app. Requirements group by their source group and sit in catalogue order inside it, so if a clause appears in the wrong place it is sitting in the wrong place in the file, or it has been given a group it does not belong to. Fix the sequence, import again and confirm.
The preview wants to remove requirements I still need
An import replaces a catalogue rather than adding to it, so a requirement missing from the file is a requirement being removed. This is almost always a partial file — one section exported rather than the whole document. Check the count against the source, complete the file and start again.
Everything reads as not mapped after the import
If this is a first import, that is correct: a new catalogue arrives with no mappings, and the mapping is the work that follows. If it is a re-import, the mappings-kept figure in the preview will have warned you, and the cause is the identifiers rather than the import.
I cannot delete a framework
The two catalogues that ship with RiskOS cannot be deleted. They are a fixed reference point, and they cost nothing to leave in place — a framework you are not working against does not appear in a report unless you ask for framework coverage in it.
Habits that keep a catalogue honest
- Keep the publisher's identifiers. They are the only thing connecting this revision of a standard to the next one, and rewriting them for neatness costs you every mapping you have made.
- Put the revision in the name. A coverage figure is only meaningful against a stated edition, and the name is where a reader finds out which one they are looking at.
- Read the preview properly, every time. Four figures, ten seconds, and it is the last moment at which a bad file costs nothing.
- Import the whole catalogue, not a section. A partial file reads as a wave of removals, because an import replaces the catalogue rather than topping it up.
- Map from the control when one control answers many clauses. Attaching requirements from the control's side is faster than hunting the same control down in eight separate groups.
- Work the middle state first. Requirements that are mapped but not operating are the shortest distance between where your coverage is and where you want it.
- Re-import when the standard moves, not when the audit is booked. The revision you have not read yet is the one that adds a requirement nobody owns.
- Back up before a large revision. RiskOS writes everything to a single file from File ▸ Back Up RiskOS…, so a catalogue change you regret is a restore away rather than an afternoon of remapping.
Frequently asked questions
What file formats can I import a control framework from?
CSV or JSON. Each requirement carries an identifier, a title and the group it belongs to, and the order in the file is the order RiskOS shows them in. The two forms produce an identical framework, so use whichever the source document reached you in rather than converting it first.
Will I lose my control mappings when I import a newer version?
Not where requirement identifiers match. Mapping work is held against the identifier, so an unchanged clause number keeps everything attached to it. Before anything is replaced, RiskOS tells you how many of your mappings survive, alongside what the file adds, removes and retitles, and nothing changes until you confirm.
Can I import my own internal control standard?
Yes. An internal standard, a customer's security schedule or a sector code all import the same way, and once imported yours behaves exactly like the catalogues that ship with RiskOS. Controls map to its requirements from either side, and coverage reads across it in the same three states.
Does importing a framework replace the one I already have?
It replaces that catalogue's requirements, which is why the preview matters. Requirements missing from the file are removals, so import the whole document rather than one section. Other frameworks are untouched, and the two catalogues that ship with RiskOS stay where they are and cannot be deleted.
Why does a requirement show as mapped but not covered?
Because the control attached to it is planned rather than implemented or operating. A control that has not landed protects nothing yet, so RiskOS keeps that state separate instead of counting it as coverage. It is also the most useful queue to work: the control exists, and finishing it moves the requirement across.
How many frameworks can I keep at once?
As many as you need. The two that ship with RiskOS stay in place, and your own catalogues sit alongside them. A single control can answer requirements in several frameworks at the same time, which is generally the point: one access review usually satisfies clauses in three different documents.
Does my control catalogue leave my Mac when I import it?
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 from wherever you keep it, and the catalogue it produces stays in the register until you choose to export or back it up yourself.
Can I undo a framework import?
The moment to stop one is the preview, which appears before anything is replaced and lists exactly what the file would change. After a confirmed import, re-importing the correct catalogue puts it back, and mapping work held against matching identifiers stays attached. If a revision went badly wrong, Restore from Backup… returns the whole register to its earlier state.