How to map controls to NIST CSF 2.0 on Mac
You can do this with RiskOS, a risk register for macOS. Map from either side, and let coverage report what is true rather than what is hoped for.
A framework is a public statement of what a careful organisation is expected to have in place. Your control register is a private statement of what you actually have. Mapping is the short bridge between the two, and it is worth building properly, because it turns a vague sense of being broadly covered into a page you can put in front of someone.
The bundled NIST Cybersecurity Framework 2.0 catalogue carries the framework's own structure at category level, labelled as exactly that. The mapping is yours to make: nothing is mapped for you, because only you know what you actually run.
Why a mapping is worth making
A mapping answers one question repeatedly and without argument: for each thing this framework expects, what do we have, and is it working? That question arrives in an audit, in a customer's security review, in a board paper and in your own planning, and each time it is asked the honest answer takes hours to assemble unless it has already been written down.
A control mapped to a category is a claim. RiskOS checks that claim against the control's own status rather than taking it on trust, which is why coverage here has three states rather than a tick box.
Where frameworks live
Choose Reference ▸ Frameworks in the sidebar. The catalogues you have are listed there, including the bundled NIST Cybersecurity Framework 2.0 structure and the RiskOS Control Baseline 1.0, each named for what it is. Select one and its requirements fill the middle of the window, grouped by their source group — for this framework, that means grouped by function — and kept in catalogue order rather than re-sorted into something tidier.
Above the list sit a search field and a coverage filter. The panel on the right shows whatever you select: the requirement, what it asks for, the controls currently mapped to it, and its coverage state. You can work from the other end too. A control's own panel maps it to requirements directly, which is usually the faster direction once your control register has some weight to it.
Map your controls, step by step
-
Open the NIST CSF 2.0 catalogue
Choose Reference ▸ Frameworks and select the NIST Cybersecurity Framework 2.0 entry. Its categories appear grouped under the six functions — govern, identify, protect, detect, respond and recover — in the order the framework itself uses.
-
Read the category before you map anything
Select a category and read what it asks for in the panel. Categories are broader than a single measure, so the question to hold in mind is not "do we have a document about this" but "what do we rely on to make this outcome true today". The answer is usually one or two controls, not eight.
-
Map from the requirement side
With the category selected, map the controls that satisfy it from its panel. This is the direction to use when you are working through a framework end to end, because you move down the list once and nothing is missed. Each control you map is listed on the category with its status, so the panel shows immediately whether the claim stands up.
-
Map from the control side
Choose Controls in the sidebar, open a control such as CTL-0001 Endpoint detection and response, and map it to the categories it serves. Mapping works from either side and produces the same result, so use whichever end you happen to be working at. This direction suits the moment you add a new control and want its framework relevance recorded while you are thinking about it.
-
Set the status that decides coverage
Open each mapped control and check its status. Only controls that are implemented or operating count as coverage. A planned control — CTL-0003 Quarterly restore rehearsal, for instance, strong as it will be — reduces nothing yet and covers nothing yet, and RiskOS says so rather than letting the intention pass as a fact.
-
Record effectiveness and the evidence behind it
While the control is open, set its effectiveness and write the evidence notes: what you saw, when you saw it, and where it came from. Set the owner and the next review date at the same time. Coverage that nobody can substantiate is the kind that collapses in the first ten minutes of a review.
-
Filter by coverage to find the gaps
Back in Reference ▸ Frameworks, use the coverage filter to show only what is not mapped, then only what is mapped but not operating. The first list is your genuine gap. The second is work already started that needs finishing, which is usually the cheaper of the two to close.
-
Put coverage into a report
Choose Reports, switch on the framework coverage section, and export. ⇧⌘P produces a paginated PDF with your branded cover; ⇧⌘E produces a single self-contained HTML file that opens in any browser. Both come from the same snapshot as the rest of the report, so the coverage page and the register agree.
The three coverage states
Coverage is deliberately not a percentage with a tick beside it. A category is in one of three states, and the difference between the middle state and the first is the difference between a plan and a protection.
| State | What it means | What to do about it |
|---|---|---|
| Covered | At least one mapped control is implemented or operating. | Keep the evidence current and the review date honest. |
| Mapped but not operating | A control is mapped, but it is still planned or is no longer running. | Finish it. The mapping is right; the control is not live yet. |
| Not mapped | Nothing in your control register claims this category. | Either add the control, or record why the category does not apply. |
The middle state is the useful one. Most coverage arguments go wrong because a plan and a protection were recorded the same way, and six months later nobody could tell which was which. Here, CTL-0002 Immutable offsite backups is operating and covers what it is mapped to. CTL-0003 Quarterly restore rehearsal is planned, so the categories it is mapped to sit in the middle state until the day its status changes.
The six functions, and what usually lands in each
Categories in this framework group under six functions. Reading them in plain terms makes the mapping quicker, because most controls announce their own function the moment you describe what they do.
| Function | What it asks of you | A control that usually lands here |
|---|---|---|
| Govern | Who decides, what the appetite is, how third parties are held to it. | A documented risk appetite and a vendor review cadence. |
| Identify | Knowing what you have and what threatens it. | An asset register and the risk register itself. |
| Protect | Keeping the bad outcome from happening. | CTL-0002 Immutable offsite backups. |
| Detect | Noticing when something is going wrong. | CTL-0001 Endpoint detection and response. |
| Respond | Acting once it has. | CTL-0009 Secondary logistics partner. |
| Recover | Getting back to normal, and proving you can. | CTL-0003 Quarterly restore rehearsal, once it is operating. |
The bundled catalogue sits at category level rather than descending into every subcategory. That is a deliberate altitude for mapping work: category level is specific enough that a control clearly belongs or clearly does not, and coarse enough that a small organisation can complete the pass in an afternoon instead of abandoning it in week three.
Mapping that survives scrutiny
Anyone can attach a control to a category. The mappings that hold up are the ones made with a little discipline about what is being claimed.
Map the control that does the work
A policy that says restores will be tested is not the control. The rehearsal is the control. Map the thing that would actually change the outcome, and if the policy matters to you, record it as its own control with its own status rather than letting it stand in for the practice it describes.
One control can serve several categories
Mapping is not one-to-one, and it should not be forced into it. Immutable offsite backups sit under protect and under recover, and in an organisation where a supplier runs them, they touch govern too. Map the control everywhere it genuinely contributes. When its status changes, every category it touches updates at once.
Never map what you intend to build
Mapping a planned control is allowed and often sensible — it records the intent and puts the category into the middle state, where it reads as work in progress. What is not sensible is marking that control as operating so the coverage page looks better. RiskOS takes the status at face value, so the only way to turn a category green is to make the control real.
Keep the register and the framework in step
The same controls that map to categories are the ones your risks link to. Change a control's status or effectiveness and RiskOS re-scores every risk deriving from it and updates coverage in the same movement. That is what makes one control register worth the discipline: the residual score of RSK-0007 and the recover function are reading the same underlying fact, recorded once.
Record why something does not apply
Some categories will not apply to you, and leaving them as not mapped is indistinguishable from having forgotten them. Where a category is genuinely out of scope, create a control that states the scoping decision, map it, and put the reasoning in its evidence notes. The next person to read the coverage page then sees a decision rather than a hole.
Your own catalogue, and newer revisions
The bundled frameworks are not the limit. RiskOS takes your own catalogue as CSV or JSON, so an internal control standard, a customer's questionnaire or a regulator's schedule can sit alongside the bundled ones and be mapped the same way.
Revisions are worth understanding before you need one. Re-import a newer revision of a catalogue and your mapping work is kept wherever requirement identifiers match. Before anything is replaced you are shown exactly what the file adds, what it removes, what it retitles, and how many of your existing mappings survive. Nothing changes until you confirm, so a bad file is a cancelled dialogue rather than an afternoon of repair.
Two further behaviours are worth holding in mind. Bundled frameworks cannot be deleted, so the NIST CSF 2.0 structure and the RiskOS Control Baseline stay available even after you have added your own. And identifiers are what carry mappings across a revision, so if you maintain your own catalogue, keep its identifiers stable even when you rewrite the wording.
Troubleshooting
I mapped a control but the category still is not covered
Open the control and look at its status. Only implemented or operating controls produce coverage. Planned controls — and controls that have been retired — leave the category in the mapped but not operating state, which is the register telling you the intent is recorded and the protection is not yet in place.
Coverage dropped and nobody changed a mapping
A control's status changed. Retiring a control, or moving one back to planned while it is rebuilt, removes it from coverage everywhere it was mapped, and re-scores every risk that derives from it. Check the control register for anything recently retired; the show-retired toggle brings retired controls back into the list.
I cannot find the requirement I am looking for
Check the coverage filter first. If it is set to show only unmapped categories, everything you have already mapped is hidden from the list. If the filter is clear, remember that the bundled catalogue sits at category level, so a subcategory identifier you are used to quoting will live inside the category above it. Search the wording rather than the identifier when you are not sure.
I cannot delete the bundled framework
That is intentional. Bundled frameworks cannot be deleted, because a catalogue that your mappings and reports depend on should not disappear on a mis-click. If you are not using it, leave it be and work in your own catalogue; the frameworks list holds both without complaint.
Some mappings did not survive a catalogue import
Mappings follow requirement identifiers. Where an identifier in the new revision matches one in the old, the mapping is kept; where the identifier changed, the requirement is new as far as the import is concerned and arrives unmapped. The preview shown before you confirm states how many mappings survive, which is the number to read before deciding to go ahead.
A routine that keeps coverage honest
Mapping is a project once and a habit afterwards. These are the habits that keep it worth having.
- Map in one pass, function by function. Work down the list from govern to recover in catalogue order rather than jumping to the categories you already feel good about.
- Close the middle state first. Categories that are mapped but not operating are already half-built, and finishing one usually costs less than mapping a new control from nothing.
- Set a review date on every mapped control. Coverage decays quietly, and the control's own next review is what brings it back for a look.
- Write evidence notes as you go. The sentence you write today is the one you will be reading out in a review months from now.
- Re-read the coverage filter monthly. Five minutes with the not-mapped list is the cheapest assurance activity available to you.
- Include framework coverage in the quarterly report. A coverage page beside the register shows what you have, what is missing and what it is protecting, in one document.
- Keep identifiers stable in your own catalogues. Wording can change freely; identifiers are what carry your mapping work forward.
Frequently asked questions
Does RiskOS support NIST CSF 2.0?
Yes. RiskOS ships the NIST Cybersecurity Framework 2.0 structure at category level, labelled as exactly that, alongside the RiskOS Control Baseline 1.0. You map your own controls to its categories from either side, and coverage is then reported for every category from the status of the controls you mapped.
What does "mapped but not operating" mean?
It means a control is mapped to the category, but that control is planned or retired rather than implemented or operating. The intent is recorded; the protection is not live. It is the state that separates work in progress from real coverage, and it usually marks the cheapest gaps to close, because the work has already started.
Can one control cover more than one framework category?
Yes, and most real controls do. Offsite backups typically serve both a protect category and a recover category. Map the control everywhere it genuinely contributes. When its status or effectiveness changes, every category it is mapped to updates together, so there is no second list to keep in step by hand.
How do I map controls to a framework RiskOS does not ship?
Import your own catalogue as CSV or JSON from the Frameworks section. It then sits beside the bundled catalogues and behaves identically: requirements grouped by their source group, search, a coverage filter, and mapping from either the requirement or the control. An internal standard or a customer questionnaire works exactly the same way.
Will importing a newer version of a framework wipe my mappings?
No. Mapping work is kept wherever requirement identifiers match between the old catalogue and the new one. Before anything is replaced, RiskOS shows what the file adds, removes and retitles, and how many of your mappings survive. Nothing changes until you confirm, so you can read that summary and cancel.
Why is my framework coverage lower than I expected?
Usually because planned controls are being counted as intentions rather than protections. Filter the categories by coverage and look at the mapped but not operating group first. If that group is small, the remaining gap is genuine: categories with nothing in your control register claiming them at all.
Can I show framework coverage to an auditor or a board?
Yes. Switch on the framework coverage section in Reports and export. The PDF is paginated A4 with a branded cover and a running header and footer; the HTML output is a single self-contained file that opens in any browser. Both are produced from the same snapshot as the register, so the two always agree.
Does my mapping work leave my Mac?
No. Everything here happens on your Mac. There is no account, nothing is uploaded, and your register never leaves the machine except in a file you export or back up yourself. Catalogues you import are read from the file you choose, and the only network use is Apple's App Store, for purchases.