How to check framework coverage on Mac
Read it in RiskOS, a risk register for macOS. Three states, no half credit, and a filter that shows you only the gaps.
Coverage is the question a framework always comes down to: of everything this catalogue asks for, how much are we actually doing? A single percentage is a poor answer, because there is a real difference between a requirement nobody has addressed and one addressed by a control that has not started working yet. RiskOS keeps those two apart, and keeps them apart everywhere coverage is shown.
Covered means a mapped control is implemented or operating. A control that is still planned leaves its requirement in the middle state, however strong it will be once it lands.
Where framework coverage lives
Choose Frameworks in the sidebar, in the Reference group. The list shows every catalogue you have available, including the ones that ship with the app and any you have imported yourself. Select one and its requirements fill the middle of the window.
Requirements are grouped by their own source group and held in catalogue order, so the list reads the way the framework itself is written rather than in an order the app invented. Above them sit a search field and a coverage filter. Select a requirement and the panel on the right shows it in full, along with the controls mapped to it and what each of those controls is currently doing.
That last point is the whole of it. Coverage in RiskOS is not a field anyone types. It is read from the controls you have mapped and the state those controls are in, which means it moves on its own when the work moves.
Check coverage on a framework, step by step
-
Open Frameworks
Choose Frameworks in the sidebar, under Reference. The catalogues you can measure against are listed there, each labelled with exactly what it is, so you always know whether you are looking at a full control set or a structure at category level.
-
Choose the catalogue you are measuring against
Select one framework and work it to the end before opening another. Coverage is only meaningful within a single catalogue, because two frameworks ask for different things at different levels of detail and a combined figure would average away the difference.
-
Read the headline figure first
Take the overall count before you look at any single requirement — seven of twenty-eight covered, for example. It is the number you will be asked for, and reading it first stops you forming an impression from whichever requirement happens to sit at the top of the list.
-
Filter to one coverage state at a time
Use the coverage filter above the requirement list to show only what is covered, only what is mapped but not operating, or only what is not mapped. Working one state at a time turns a long catalogue into three short, specific jobs, each with its own question to answer.
-
Open a requirement to see what is mapped to it
Select any requirement and read the panel on the right. It carries the requirement's own text and the controls mapped to it, each with its status and effectiveness beside it, so you can see not only that something is claimed but what is being claimed and how strong it is.
-
Separate the nearly done from the not started
Filter to mapped but not operating and work that list first. Every entry in it is a requirement where the thinking is already done and only the status is holding it back. These are usually the cheapest moves you can make on a coverage figure.
-
Map a control to an uncovered requirement
For anything reading not mapped, decide whether you already do the work. If you do, map the control that does it — the connection can be made from the requirement or from the control's own record, because it is one relationship seen from two ends. Coverage updates as soon as the mapping exists.
-
Turn what is left into dated work
Genuine gaps deserve an owner and a date rather than a note. Open the control that will close the gap and add a remediation action in its own panel, with a title, an owner and a due date. It then appears in Actions with everything else that is outstanding, grouped by how late it is.
The three coverage states
Most coverage figures flatter their owners because they count intentions. Three states remove that comfort: a requirement is either answered by something that is working, answered by something that is not working yet, or not answered at all. Each one calls for a different conversation.
| State | What it means | What to do about it |
|---|---|---|
| Covered | At least one mapped control is implemented or operating. | Confirm the control is still reviewed on its cadence and that its evidence notes are current. |
| Mapped but not operating | A control is mapped, but its status has not reached implemented or operating. | Find out what it is waiting on. This is the shortest route to a better figure. |
| Not mapped | No control is mapped to the requirement at all. | Decide whether you do the work and have not recorded it, or do not do it yet. |
Why a planned control earns no credit
It is the same rule that governs every score in the register: only a control that is implemented or operating reduces anything. A quarterly restore rehearsal rated highly effective but still marked planned protects nobody this quarter, and giving it coverage credit would be a promise recorded as a fact. RiskOS holds it in the middle state instead, where it is visible without being counted.
Not mapped is not the same as not done
On a first pass through a catalogue, most of the not-mapped list is usually work you already do that nobody has connected to the wording. That is why the first sweep of a framework is mostly recording rather than remediation, and why coverage often climbs sharply in the first hour and then slows to the pace of real change.
What the bundled catalogues are
Two catalogues ship with the app, and each is labelled with exactly what it is so that nobody reads more into a figure than it can carry. You can bring in your own alongside them.
| Catalogue | What it contains | Best used for |
|---|---|---|
| RiskOS Control Baseline 1.0 | A general control set covering the ground most organisations need first. | A starting measure when no external framework has been chosen. |
| NIST Cybersecurity Framework 2.0 | The framework's structure at category level, labelled as such. | Reporting posture in language a board or a client already recognises. |
| Your own catalogue | Whatever you import from CSV or JSON. | A regulator's schedule, a customer's questionnaire, or an internal standard. |
Bundled catalogues cannot be deleted, which keeps a measure you have been reporting against from disappearing between one quarter and the next. Anything you imported yourself remains yours to manage.
What happens when a catalogue is revised
Frameworks change, and the mapping work you did against the old revision is worth protecting. Re-import a newer revision and RiskOS keeps your mappings wherever the requirement identifiers still match. Before anything is replaced it shows what the file adds, what it removes, what it retitles, and how many of your mappings survive. Nothing changes until you confirm.
Reading a coverage number honestly
The figure is only as good as the reading someone gives it, and a few habits keep it from being oversold in a meeting.
Count requirements, not controls
Coverage measures how much of the catalogue is answered, not how many controls you own. A register with sixty controls can cover a fraction of a framework if they all cluster around the same few requirements, and a compact set of well-placed controls can cover a great deal more.
One control can answer several requirements
Mapping is not one-to-one. Endpoint detection and response may sit against several requirements at once, and a single change to its status will move every one of them together. That is a strength when the control is operating and a concentration when it is not, which is worth noticing before you report a comfortable figure that rests on three controls.
Coverage is not assurance
A requirement reads as covered because a mapped control is operating, not because anyone has tested it this quarter. Keep each control's review date current and its evidence notes filled in, and the coverage figure stands on something a reader can inspect rather than on the word operating alone.
Showing coverage to other people
Coverage is rarely checked for its own sake. It is checked because somebody is going to ask, and the answer usually has to travel out of the app.
Choose Reports in the sidebar and switch on the framework coverage section. Fill in the report title, the organisation and who prepared it, then choose your output. ⇧⌘P exports a paginated PDF with a branded cover and a running header on every page, ⇧⌘E writes a single self-contained HTML file that opens in any browser and loads nothing from the internet, and ⌘P sends exactly the PDF to the printer. All four outputs are built from the same snapshot, so the coverage figure in the PDF and the one in the workbook cannot disagree.
Pair the coverage section with open actions in the same report. A gap with a named owner and a date reads very differently from a gap on its own, and it is the pairing that turns a list of shortfalls into a plan.
Troubleshooting
A requirement says not mapped, but I know we do it
Doing the work and recording it are separate acts, and only the second one counts here. Open the requirement, find the control that does the work, and map it. If no such control exists in Controls yet, that is the real finding: the work is being done by habit rather than by a control anyone can point to.
Coverage fell and nobody changed a mapping
A control's status changed. Coverage follows the state of the controls you have mapped, so a control moved out of operating — during a migration, or when it was retired — takes every requirement leaning on it back to mapped but not operating. Open the control and its status will say what happened.
Some of my mappings did not survive a re-import
Mappings are carried across wherever requirement identifiers match between the old revision and the new one. Where an identifier has been retired or renumbered there is nothing to carry them to. The preview shown before the import says how many mappings survive and what the file adds, removes and retitles, so check that screen before confirming rather than after.
I cannot delete a framework
The catalogues that ship with the app are permanent, so a measure you have reported against stays available. If a bundled framework is not one you work to, leave it alone and select the catalogue you do use; nothing about an unused framework affects the register or any other coverage figure.
The requirement list is too long to work through
Use the two narrowing tools together. Set the coverage filter to a single state, then search within it for the group or the wording you are dealing with. A catalogue of a few hundred requirements becomes a handful of rows, and you can work it in sittings without losing your place.
Routines worth keeping
- Work the middle state first. Mapped but not operating is where the cheapest improvements live, because the control already exists and only its status is holding the requirement back.
- Sweep for unrecorded work once. On a new catalogue, go through the not-mapped list asking only "do we already do this?" before you plan a single new control.
- Check coverage after any control status change. Promoting one control to operating can move several requirements at once, and it is satisfying to watch it happen.
- Give every genuine gap an owner and a date. A remediation action on the control puts the gap into Actions with everything else that is outstanding.
- Read the import preview properly. It is the one moment where you can see what a revision will do to your mapping work before it does it.
- Report coverage with open actions beside it. The two sections answer each other, and together they say what is true and what is being done.
- Re-check before each review cycle. Coverage drifts quietly as controls move, so read it at the start of a quarterly pass rather than the night before the meeting.
Frequently asked questions
What does framework coverage mean?
It is the share of a framework's requirements that are answered by a control you have mapped and that is actually working. RiskOS reports it in three states rather than one percentage: covered, mapped but not operating, and not mapped. The figure is read from your controls and their statuses, never typed in by hand.
Why does a requirement with a control mapped to it still count as a gap?
Because the control is not operating yet. Only a control that is implemented or operating counts as coverage, so a planned one leaves its requirement in the middle state. It is visible and credited as progress, but it is not counted as done, and the distinction is what stops a coverage figure from measuring good intentions.
Which control frameworks come with RiskOS?
Two. The RiskOS Control Baseline 1.0, a general control set to measure against when no external framework has been chosen, and the structure of the NIST Cybersecurity Framework 2.0 at category level. Each is labelled with exactly what it is, so nobody mistakes a category-level structure for a full control catalogue.
Can I check coverage against my own framework?
Yes. Import your own catalogue from CSV or JSON and it sits alongside the bundled ones, with the same three coverage states, the same grouping by source group, and the same search and coverage filter. A regulator's schedule, a customer's security questionnaire or an internal standard can all be measured the same way.
Will re-importing a framework lose my control mappings?
Mappings are kept wherever requirement identifiers match between revisions. Before anything is replaced, RiskOS shows what the file adds, removes and retitles, and how many of your mappings survive, and nothing changes until you confirm. Identifiers that have been retired or renumbered are the only place mappings cannot be carried across.
How do I show framework coverage to an auditor or a board?
Switch on the framework coverage section in Reports and export. The PDF is paginated A4 with a branded cover and a running header, the HTML output is one self-contained file that loads nothing from the internet, and both come from the same snapshot as the workbook, so the figures always agree.
Can I delete a framework I do not use?
The catalogues that ship with the app cannot be deleted, so a measure you have already reported against stays available quarter after quarter. Catalogues you imported yourself remain under your control. An unused framework costs you nothing: select the one you work to and the rest sits quietly out of the way.
Does checking coverage send anything to the internet?
No. Everything here happens on your Mac. There is no account, nothing is uploaded, and your register never leaves the machine. Frameworks, mappings and coverage figures are read and written locally, and they leave only in a report or an export you produce yourself.