ISO 31000 is guidance, not a checklist, and not something an organization gets certified against. It sets out principles, a framework and a process, and leaves every threshold to you. This guide covers what the standard asks for and how a small operational risk team runs it week to week against a live register.
ISO 31000:2018 applies to any organization and any kind of risk — operational, financial, project, legal. It is short by the standards of standards, and most of its length goes on describing how risk management should be embedded in an organization rather than on how to score a risk.
It is written as guidance. There is no certification body issuing an ISO 31000 certificate to an organization, and no audit that awards one. What an auditor can do is hold you to the process you wrote down — which is why the criteria you set matter more than the framework you name.
Eight principles sit at the top: risk management should be integrated into the organization rather than run beside it, structured, tailored to the organization, inclusive of the people who hold the knowledge, dynamic as circumstances change, built on the best information available, attentive to human and cultural factors, and continually improved. None of them is a rule you can pass or fail. They are the argument for why a register lives in daily work rather than in a quarterly spreadsheet.
The framework is the organizational scaffolding — leadership commitment, then design, implementation, evaluation and improvement. In a company of thirty people this collapses to something modest: one named person accountable for the register, a documented cadence, and a route by which risks reach whoever decides. The standard does not ask for a risk department.
This is the step teams skip, and skipping it is why their registers argue with themselves. Three questions have to be answered before the first risk is written down.
Criteria are the part with teeth. A likelihood of 3 has to mean the same thing in the finance workshop as in the engineering one, or the register cannot be sorted, and the board is comparing numbers that were never comparable.
The standard does not present a numbered list of five steps. It describes risk assessment in three parts — identification, analysis and evaluation — followed by treatment, and it puts communication and consultation, monitoring and review, and recording and reporting alongside all of them rather than at the end. What a team runs week to week distils to five, and the naming below is that working shorthand, not a quotation of the standard.
List everything that could go wrong, working through processes, departments or value streams. Record cause and consequence in separate fields — “server outage” is not a risk; “customer-facing outage caused by an unpatched dependency, leading to an SLA breach” is. A risk without a named owner is a note, not an entry.
Output: A raw register of candidate risks, each with an owner.
Score likelihood and impact before existing controls are taken into account — the inherent score. A 5×5 matrix turns two judgements into one number that can be compared across categories, which is what makes a register sortable at all. The scale matters less than using the same one everywhere.
Output: Inherent likelihood × impact = inherent severity for every entry.
Compare inherent severity against the criteria set earlier. Anything above the tolerance line needs treatment; anything below is accepted and monitored. This is the step that turns a list into a decision, and the one that fails when nobody wrote the tolerance line down.
Output: A prioritized shortlist of risks that require action.
Choose a strategy per risk — avoid, reduce, transfer or accept — and record the specific actions, their owners and their dates. Then score again for residual likelihood and impact. The distance between inherent and residual is the claim your controls make, and it should be justified in writing when it is large.
Output: Named actions, owners, and a residual score per treated risk.
Give every risk a review interval proportionate to its severity, and re-score when something changes rather than when the calendar says so. A register whose review dates have quietly passed is the most common audit finding, and it is the one thing software can prevent outright.
Output: A live register with next-review dates and a history of every change.
Communication and consultation is the part that has no box in the diagram. The people who know where a process breaks are rarely the people who maintain the register, which is the practical reason viewers and stakeholders need to reach it without a license standing in the way.
The standard treats the record as part of the process rather than a by-product of it. In practice that means two things an auditor will ask for and a spreadsheet cannot give: a history showing who changed a score and when, and evidence that a review happened at the point it was due rather than the week before the audit.
Most findings land here. The scoring method is rarely disputed; the missing trail behind it usually is.
Every column the process needs — inherent scoring, treatment strategy, residual scoring, owner, next review date — is laid out in our free Excel template, with severity, the next review date and the justification check already calculated. Enough for a first register.
What a spreadsheet cannot do is the last part of this guide: keep a history nobody can rewrite, and tell you when a review has fallen due. That is where EasyRisk.io starts.