How to run an ISO 27001-style risk assessment on Mac
Do it in RiskOS, a risk register for macOS. Inventory, exposure, controls, treatment and a residual score with its working still attached.
The standard asks a short list of questions and expects the same answers every year: what are you protecting, what could go wrong, who answers for it, what reduces it, what is left, and did anyone agree that what is left is acceptable. Most assessments come apart on the last two — the residual figure traces back to nothing, and nobody wrote down what acceptable meant.
Everything here happens on your Mac. There is no account, nothing is uploaded, and your register never leaves the machine.
Where each piece of the assessment lives
An assessment is not one screen. It is six or seven pieces of work that have to agree with each other, and the sidebar runs in roughly the order you will do them: Inventory for Assets and Vendors, Register for Risks, Controls, Actions and Review, Reference for Frameworks and the Risk Library, and Output for Reports, Import & Export and Settings. The panel on the right edits whatever you select.
| What the assessment asks for | Where you do it | What it leaves behind |
|---|---|---|
| The scope you are protecting | Assets and Vendors | Entries with a criticality and an owner |
| The risks to that scope | Risks | A numbered row per risk, with an owner |
| Likelihood and impact | The Assessment section of a risk | An inherent score from 1 to 25 and its band |
| Risk acceptance criteria | Settings ▸ Appetite | A threshold, refined per category |
| Controls and their effect | Controls, linked to risks | A residual score with the reasoning beside it |
| Treatment decisions | The Treatment section of a risk | A strategy, a plan and a date |
| Controls mapped to requirements | Frameworks | Coverage in three honest states |
| A documented result | Reports | A dated, branded document from one snapshot |
| Evidence of review over time | Review, and a risk's History | Stamped dates, and the reason for each change |
Run the assessment, step by step
-
Set the rules before you rate anything
Press ⌘, to open Settings. Methodology holds the scales, the band thresholds and one choice that carries further than it looks: whether controls reduce likelihood, impact or both. Then open Appetite and set the highest residual score your organisation will tolerate. That figure is your acceptance criterion, and it is the sentence most assessments lack.
-
Build the inventory you are protecting
Choose Assets and press ⌘N for each system, data set, facility or process in scope, giving every one a type, a criticality and an owner. Do the same under Vendors for third parties, recording criticality, the relationship owner and a next review date. Keep to what you would genuinely defend; a short accurate inventory is worth more than a long one nobody maintains.
-
Name one risk for each threat worth assessing
Choose Risks, press ⌘N and write the event rather than the worry: Ransomware encrypts primary file shares can be rated, Malware cannot. Set the category, owner, business unit and review cadence. The reference — RSK-0001 upward — is issued for you and never reused, so it is safe to cite in minutes. For a starting point, the Risk Library holds thirty-nine worked examples, which arrive as drafts.
-
Rate the exposure before any control is counted
Open Assessment and set inherent likelihood and impact on the two 1–5 steppers, rating the risk as it would be with nothing standing in its way. The score appears at once, from 1 to 25, with its band beside it. Set onset velocity and detectability as well: neither changes the score, and both change what you do about it.
-
Attach each risk to the assets and vendors it threatens
Open Context and add what the risk touches. Each appears with its criticality badge, so a High-criticality asset hanging off a Critical risk is visible without cross-referencing two lists. Read the other way, an asset shows its worst residual risk and a vendor shows every risk it brings — the trail an assessor tends to follow.
-
Record the controls you actually rely on
Choose Controls and press ⌘N for each measure you depend on: name, description, type, status, owner, an effectiveness rating with its descriptor, a next review date and evidence notes. Status is where assessments are generous with themselves. Only controls that are implemented or operating reduce risk; a planned control, however strong it will be, reduces nothing yet.
-
Link the controls and read the residual score
Back on the risk, open Controls and link what applies, creating anything missing from the same picker. Leave derive effectiveness from linked controls switched on and the residual follows your strongest operating control. Three lines hold, and you can state them plainly: residual never exceeds inherent, never falls below 1, and a stronger control never raises a score.
-
Decide a treatment for everything above appetite
Filter the register to over-appetite only and work down what is left. For each, open Treatment, choose Mitigate, Accept, Transfer or Avoid, write the plan and set a due date. Acceptance is a legitimate answer, as long as it is recorded as a decision with a name against it. Add the work itself as actions, each with an owner and a date.
-
Map the controls to your requirement catalogue
Choose Frameworks and map each control to the requirements it satisfies. Mapping works from either side: from the framework, requirement by requirement, or from a control that covers several at once. Requirements group by their source group in catalogue order, with a search and a coverage filter, so you can work through one domain at a time.
The inventory behind the assessment
Criticality is the word that does the work
Criticality is not a measure of what an asset cost or how much anyone likes it. It states what happens to the organisation when that asset is unavailable, wrong or exposed. Rate it against consequence and the badge still means something beside a risk three months later. Rate it against affection and everything ends up Critical, which tells a reader nothing.
Third parties belong in the same picture
Suppliers are not a separate assessment. A vendor entry carries its criticality, a relationship owner and a next review date, and gathers every risk that supplier brings into one place. The vendor list counts overdue reviews in its subtitle, usually the first sign that third-party oversight has slipped behind the rest of the work.
Acceptance criteria, and what sits above them
Appetite is what turns a register into an assessment. Without a threshold, a list of scores is only a list of scores; with one, every risk is either inside the line or outside it, and the outside ones are your findings. A risk above appetite is flagged everywhere it appears. Thresholds sit at three levels and resolve in a fixed order.
| Order | Where the threshold comes from | When it applies |
|---|---|---|
| 1 | The risk's own override | Its Appetite section has the override switched on, with its own stepper |
| 2 | The category threshold | That category has a threshold in Settings, with the rationale recorded beside it |
| 3 | The organisation threshold | The single figure every risk falls back to |
| 4 | None | Nothing is set at any level, so no risk is flagged as a breach |
Take RSK-0007, Backup restoration has never been tested end to end: inherent 20, residual 15, target 4, against an appetite of 9. Six points over is the figure an executive summary carries, and the distance between 15 and 4 is what the treatment plan exists to close.
Reading coverage honestly
Coverage is the part of an assessment most often overstated, because a mapping is easy to mistake for a working control. RiskOS keeps the two apart and reports three states rather than one flattering figure.
| Coverage state | What it means | What to do next |
|---|---|---|
| Covered | A mapped control is implemented or operating | Keep the evidence notes and the review date current |
| Mapped but not operating | A control is mapped, but its status means it reduces nothing yet | Finish the implementation, or map one already operating |
| Not mapped | No control is mapped to the requirement at all | Map an existing control, or record what you actually rely on |
The middle state is the useful one. Seven of twenty-eight requirements covered on the RiskOS Control Baseline, with several more mapped but not yet live, is an accurate picture of an assessment in progress, and a better thing to present than a number that collapses under one question.
Bringing your own requirement catalogue
RiskOS ships its own Control Baseline 1.0 and the NIST Cybersecurity Framework 2.0 structure at category level, each labelled with exactly what it is. To assess against a different requirement list, import your own catalogue from CSV or JSON and map to it the same way. Catalogues get revised, and the mapping is the expensive part: re-import a newer revision and your mappings are kept wherever requirement identifiers match.
The record you hand over
Reports turns the register into the document. Fill in the cover fields — report title, organisation, prepared by — then choose from ten sections: executive summary, risk matrix, top risks, the full register, per-risk detail pages, controls, open actions, indicators, events and framework coverage. One scope switch decides whether closed and accepted risks are included: usually yes for an audit copy, no for a board pack.
Four outputs come from the same snapshot, so they never contradict one another. PDF is paginated A4 with a branded cover, a running header and footer, and rows that do not split across a page. HTML is one self-contained file that opens in any browser and loads nothing from the internet. Excel is a live workbook of seven sheets whose formulas re-score themselves when a likelihood changes. Print is exactly the PDF, sent to the printer.
Put your identity on all four once, with Set Up Branding. The live preview shows the real header and footer, so what you approve is what prints.
Troubleshooting
Every residual score is identical to its inherent score
Nothing is reducing those risks yet. Either no control is linked, or the linked controls are still planned. Open each control, set its status honestly, and every risk deriving from it re-scores. If a whole column reads this way, the register is telling you the truth about the assessment.
I was asked how I arrived at a number and could not answer
Open the risk's History, which keeps a residual score chart and every assessment ever made, each with its recorded reason. For the current figure, the comparison grid shows inherent, residual, target and the gap, and the Controls section names what the residual is derived from.
My requirement catalogue has been revised and I do not want to remap everything
You will not have to. Import the newer revision and the mapping is kept wherever requirement identifiers match. The preview tells you what the file adds, removes and retitles, and how many of your mappings survive. Nothing changes until you confirm.
I run assessments for more than one organisation
Use profiles. A profile dresses the app for one client — its own methodology, appetite, report defaults, client name and logo — and ⌃⌘P cycles between them. Exports carry that client's prepared-for name and logo, while your own identity stays primary.
Keeping the assessment current
The first assessment is the hard one. Keeping it true is a routine.
- Give every risk a cadence, not a date. The next review date then schedules itself each time a risk is confirmed or re-scored, so the assessment ages evenly instead of all at once.
- Work the queue rather than the list. Review takes a scope — overdue, due within 30 days, above appetite, or all active risks — and presents them one at a time, worst first, with full context beside the scoring inputs.
- Let indicators challenge a rating. A key risk indicator measures something real on a cadence, with warning and breach thresholds, and flags movement before anyone reopens the assessment.
- Let events challenge it harder. Record what happened, link it to the risk it came from, and when a risk materialises more often than its rating implies you are told so.
- Save the views you keep rebuilding. Save Current Filter… names a combination such as over-appetite compliance risks, so the same evidence returns in one click at the next audit.
- Close risks, and keep them. A risk that no longer applies is closed rather than deleted, so last year's assessment stays readable.
- Back up around every review pass. ⇧⌘B writes everything — risks, history, controls, frameworks and settings — to one dated file, saved wherever you choose.
Frequently asked questions
Can RiskOS be used for an ISO 27001 risk assessment?
Yes. Scope, risks, owners, likelihood and impact, acceptance criteria, treatment and residual risk all map onto the register directly. RiskOS holds the assets and vendors in scope, the risks against them, the controls that reduce them, the appetite you assess against, and the dated report that carries the result.
Does RiskOS include the Annex A control list?
RiskOS ships its own Control Baseline 1.0 and the NIST Cybersecurity Framework 2.0 structure at category level, each labelled with exactly what it is rather than dressed up as something else. To assess against the standard's own control list, import it as your own catalogue from CSV or JSON and map your controls to it.
What are risk acceptance criteria and where do I set them?
They state how much residual risk you are willing to carry. Set the organisation-wide threshold in Settings, and give individual categories their own threshold and rationale where tolerance differs. Anything above the applicable threshold is flagged as a breach wherever it appears, which makes an assessment's findings assemble themselves.
How do I show an auditor how a residual score was calculated?
Open the risk. The Controls section names each linked control with its status and effectiveness, the comparison grid shows inherent, residual, target and the gap, and History keeps every assessment with the reason behind it. Scores are always calculated in RiskOS from what you have recorded, never read in from a file.
How often should an information security risk assessment be reviewed?
Set a cadence per risk rather than one date for everything: quarterly for the exposures that move, annually for the stable ones. Each confirmation or re-score stamps the review date and schedules the next from that risk's cadence, and a review pass can be scoped to whatever is overdue, due soon, or above appetite.
What does mapped but not operating mean in framework coverage?
A control is mapped to the requirement, but its status says it is not live yet, so it reduces nothing and covers nothing. It is reported separately from covered and from not mapped because the three call for different work, and because a coverage figure that counted intentions would not survive being questioned.
Does an assessment done this way stay on my Mac?
Yes. There is no account, no sign-in, no sync and no telemetry of any kind. Your assessment stays on your Mac and leaves it only when you export a report or write a backup yourself. The only network RiskOS uses is Apple's App Store, for purchases, and it never sees your register.