A risk taxonomy is the ordered list of categories an organisation uses to classify all of its risks, with a definition for each one. It makes sure the same risk has the same name in every department, and it lets you add things up: how many cyber risks sit above appetite, which area concentrates fraud, what has changed since the last committee meeting.
Without a taxonomy, each department writes its register its own way. Finance records “payment fraud”, Procurement “supplier impersonation” and IT “phishing aimed at accounts payable”. It is the same risk assessed three times with three different scores, and the consolidated report never notices.
Three levels are usually enough
The usual shape is a hierarchy. Level 1 has a few broad categories that the executive committee understands. Level 2 breaks them into subcategories that each risk manager works with. Level 3 is the specific risk as it appears in the register, with its owner and its rating.
More than three levels is rarely worth it. Every extra level is one more decision when a risk is added, and when the decision is hard people end up choosing “other”. For level 1, six to ten categories are usually enough: with fewer, everything lands in “operational”; with more, the committee can no longer read the report at a glance.
Don't start from scratch: Basel and ORX
The most widely used classification comes from banking. The Basel Framework defines operational risk as the risk of loss resulting from inadequate or failed internal processes, people and systems, or from external events. It includes legal risk and leaves out strategic and reputational risk (OPE10.1). To classify losses, the same framework uses seven level 1 event types (OPE25.17, table 2), which work for almost any company, bank or not.
| Event type (level 1) | What it covers |
|---|---|
| Internal fraud | Acts intended to defraud, misappropriate property or get around the law or company policy, involving at least one internal party. |
| External fraud | The same, committed by a third party: theft, forgery, hacking with a financial loss. |
| Employment practices and workplace safety | Breaches of employment, health or safety laws, personal injury claims and discrimination cases. |
| Clients, products and business practices | Failing, through negligence, to meet a professional obligation to specific clients, or a badly designed product. |
| Damage to physical assets | Loss of or damage to physical assets from natural disasters or other events. |
| Business disruption and system failures | Failures of hardware, software, telecommunications or utilities. |
| Execution, delivery and process management | Errors in processing transactions, missed deadlines and failures with counterparties and vendors. |
The problem with this list is when it was written. It does not separate cybersecurity, conduct or third-party dependency, which are now the questions that most often reach the committee. To fill that gap, the industry association ORX published in November 2019, together with Oliver Wyman, a reference taxonomy of event types that adds those risks without breaking with the Basel types. ORX itself says it is not meant to be adopted wholesale, but as a starting point for each organisation's own taxonomy.
If your company is not a bank, this is what we would do: use the seven Basel types as the backbone of operational risk and add at level 1 what Basel leaves out, such as strategic and financial risk. Technology and third parties deserve their own category once they carry real weight in the business; until then, they can stay as subcategories of operational risk.
Event, cause and consequence: keep them apart
This is the mistake that does most damage to a taxonomy. The same register lists “lack of staff training”, “payment to an impersonated supplier” and “reputational damage” as separate risks. The first is a cause, the second an event and the third a consequence. When they are mixed, the same problem is counted several times and controls are assigned at the wrong level.
A taxonomy classifies events. Causes help you choose preventive controls and consequences help you rate the impact. ORX reached the same conclusion: in 2020 it published a separate taxonomy of causes and impacts to sit alongside the event type taxonomy. Reputational risk fits better as a consequence than as a category, which is consistent with Basel leaving it out of its definition.
Rules that keep the taxonomy in use
- One definition per category. One or two sentences, with an example of what belongs and one of what does not. Without a definition, each department reads the category its own way.
- Categories that do not overlap. If a risk fits in two, the problem is in the definitions, not in the person classifying it.
- One owner per level 1 category. This is the person who settles doubts and presents that category to the committee.
- Keep an eye on “other”. If more and more risks end up there, a category is missing.
- Standards are not categories. ISO 27001, DORA or the GDPR are linked to risks through tags or through the controls. If “DORA” is a category, the risk of a cloud provider outage ends up duplicated under “DORA” and “Third parties”.
- Version it. Review it once a year and, if it changes, reclassify the history. Otherwise the comparison with last year stops making sense.
The taxonomy is the foundation of the risk analysis. With it in place, the rating of inherent and residual risk and the comparison with risk appetite can also be done by category.
The GlobalSuite® Risk Management module comes with risk and control catalogues already loaded for ISO 31000, COSO ERM and ISO 27005, and also supports each organisation's own methodology. If you want to see how your taxonomy would look, request a demo.
Sources: Basel Framework of the Basel Committee on Banking Supervision, chapters OPE10 and OPE25 (in force since 1 January 2023), and the ORX Reference Taxonomy. The examples are illustrative and do not refer to any client. Content reviewed in October 2026.
