The register is one technique. The standard lists more than forty.

Here is an uncomfortable audit you can run on your own risk framework in about a minute. List the techniques your organisation actually used in its last full assessment cycle. For most, the honest list has two entries: a risk register, and a consequence/likelihood matrix to rate what is in it. Identification, analysis, evaluation and reporting, four different jobs, all done with the same pair of tools.

Now put that against the standard. IEC 31010, the assessment techniques companion to ISO 31000, catalogues more than forty techniques, organised by the question each one answers: eliciting views, identifying risk, finding sources and causes, analysing controls, understanding consequence and likelihood, analysing dependencies, measuring risk, evaluating significance, selecting between options, recording and reporting. ISO 31000 itself says plainly that an organisation "can use a range of techniques for identifying uncertainties that may affect one or more objectives". The range exists because the questions differ. A framework that answers every question with the same two tools has stopped asking which question it is on.

The standard's own warning label

This is not an argument against the matrix. It is an argument the standard itself makes, on the matrix's own page. IEC 31010's entry for the consequence/likelihood matrix lists its strengths, it is easy to use, fast, and communicates clearly, and then a limitations list that is longer than the strengths. Two entries deserve to be read aloud in every framework review.

First: its use "is very subjective and different people often allocate very different ratings to the same risk. This leaves it open to manipulation." The standard, not a critic, is telling you that your primary analysis tool can be gamed.

Second: "Risks cannot be directly aggregated", one cannot say whether some number of Low risks equals a Medium. Which means the matrix cannot answer the question executives most want to ask of a register: how much risk are we carrying in total?

A tool with those limitations is still worth having. Sixty risks need triage, and the matrix triages. The failure is not using it; the failure is asking it to do jobs it was never designed for, when the catalogue next to it holds tools that were.

What choosing a technique is supposed to look like

IEC 31010 clause 7.2 describes a selection discipline most frameworks skip entirely. The choice "should be tailored to the context and use", and, critically, "the number and type of technique selected should be scaled to the significance of the decision". Not the size of the risk: the significance of the decision. A minor risk feeding a major investment decision deserves more technique than a major risk nobody is deciding anything about.

The clause lists what should drive the choice: the purpose of the assessment, stakeholder needs, legal and regulatory requirements, the importance of the decision, the time available, the information available, the complexity of the situation, the expertise on hand. It also contains a sentence worth keeping for the next time someone dismisses quantitative methods for lack of data: "in some cases where data is not sufficient, the rigour needed to apply a quantitative technique can provide an improved understanding of the risk, even though the result of the calculation might be uncertain". The discipline of specifying a model teaches you things even when the output carries wide error bars.

And the clause blesses plurality outright: "applying more than one technique can sometimes provide useful additional understanding".

A short tour, by question

The catalogue is too large to summarise honestly, so here is a deliberately small sample: one or two techniques per question, chosen for being usable without specialist software or a consulting engagement.

When the room cannot speak freely. The Delphi technique (B.1.3) runs expert judgement in structured anonymous rounds, and the nominal group technique (B.1.4) has participants write before anyone speaks. Both exist because the standard's authors knew what everyone knows: in a live workshop, the most senior voice sets the anchor and dissent arrives pre-softened. If your risk workshops always converge comfortably, the comfort is probably the hierarchy, not the risk profile.

When you suspect the register is missing things. Structured what-if technique, SWIFT (B.2.6), works a system through prompted what-if questions with the people who run it; HAZOP (B.2.4) does the disciplined version for processes, driving guidewords through every part of a design; scenario analysis (B.2.5) builds "models of how the future might turn out" and walks your objectives through them. All three exist because a register populated by asking "what are our risks?" mostly collects last year's answers.

When the argument is about whether the controls actually hold. Bow tie analysis (B.4.2) maps every pathway from cause to consequence and forces an effectiveness judgement on each control along it; layers of protection analysis (B.4.4) asks, quantitatively, whether the barriers stacked between cause and consequence are enough. Both belong to a category, "techniques for analysing controls", that many frameworks have no technique in at all, despite controls being where most of the money goes.

When one number will not carry the decision. Fault tree analysis (B.5.7) decomposes an event into the combinations of failures that produce it; event tree analysis (B.5.6) plays a single initiating event forward through the barriers that might stop it; Monte Carlo simulation (B.5.10) does the arithmetic once inputs are ranges rather than points, which is the honest shape of most cost and schedule uncertainty. This is the family that answers "how much?", the question the matrix's aggregation limitation concedes it cannot.

When the assessment must end in a choice. Cost/benefit analysis (B.9.2), decision tree analysis (B.9.3) and multi-criteria analysis (B.9.5) are the techniques for the step everything else feeds: selecting between options. A framework that assesses risk exhaustively and then chooses treatments by advocacy has stopped one technique short.

Risk is not the only thing on the table

One more push for breadth, from Australian guidance rather than the international standard. Infrastructure Australia's Assessment Framework guide draws a working line between risk, "events that have probabilities of occurrence that are predictable and outcomes that can be estimated with some confidence", and uncertainty, "events where probabilities of occurrence are difficult to predict and outcomes are challenging to quantify", and it structures its tooling advice around the difference: tools to analyse risk, and separate tools, scenario planning and real options among them, to analyse uncertainty. In practice, the guide notes, there is "a spectrum between risk and uncertainty", and investigation can move things along it.

The register-and-matrix pair lives entirely at the risk end of that spectrum. The strategic questions that most deserve assessment, market shifts, technology transitions, climate horizons, mostly live at the other end, where probability estimates are not honestly available and scenario-based techniques are the ones that work. A framework with no uncertainty tools has quietly limited itself to the questions its one tool can hold.

Broadening without boiling the ocean

Nobody should read IEC 31010 cover to cover and attempt all of it. The practical discipline is smaller: for the next assessment that matters, ask what question you are actually trying to answer, check which category of the catalogue owns that question, and add exactly one technique from it alongside the register you were going to use anyway. One Delphi round before the workshop. One bow tie on the risk the committee keeps arguing about. One Monte Carlo model where a contingency number has to survive scrutiny. One scenario exercise where nobody can honestly state a probability.

Clause 7.2's test is the one to keep: scale the technique to the significance of the decision. Some of the decisions crossing your desk are significant. The catalogue is written, the techniques are in it, and two tools were never going to be enough.

_Several of the techniques above have free browser implementations on this site: bow tie analysis with control effectiveness ratings, Monte Carlo cost-risk simulation across a register, and single-event quantification with treatment cost-benefit. The knowledge base covers the methods behind them, with the standards cited by clause._