A risk taxonomy is the classification scheme an organization uses to name its risks consistently: a hierarchy of categories, each defined, in which every risk the organization identifies has exactly one home. It is the architecture underneath every other risk artifact. The risk register uses it to group entries, the risk and control self-assessment uses it to structure questions, the loss database uses it to classify events, the key risk indicators are organized by it, scenario analysis draws on it, the risk appetite statement sets tolerances by it, and the internal audit universe maps to it. When these tools share a taxonomy, their outputs can be aggregated and compared; when they do not, the board receives four reports in four vocabularies and nobody can say what the organization’s largest risk is.
This guide explains how to build one. It covers what a taxonomy is and what it is not, the six design rules that prevent the usual failures (double counting, causes mixed with events, categories that mean different things to different people), the three-level architecture, a full worked example with about sixty categories, how the same structure flexes between a bank and a manufacturer, how to map the taxonomy to the organization’s structure and to the audit universe, who may change it and how, the failures that make taxonomies useless, and a worked example of a food manufacturer replacing a flat list of 140 risks with a taxonomy that its register, RCSA, loss data and audit plan now share. It sits in the site’s Risk Library with the risk register, risk appetite and RCSA guides, which assume a taxonomy exists.
In this guide
- What a risk taxonomy is, and what it is not
- Why it matters: aggregation and the end of double counting
- Six design rules
- Cause, event, effect: the confusion that breaks most taxonomies
- The three-level architecture
- A full three-level example
- The same structure for a bank and for a manufacturer
- Writing definitions that prevent disputes
- Mapping the taxonomy to the organization and to the audit universe
- Governance: who may change it, and how
- Aligning with external taxonomies
- Eight failures that make taxonomies useless
- How internal audit uses and tests the taxonomy
- Template: the category definition card
- Worked example: Brightwater Foods replaces a flat list with a taxonomy
- Questions about risk taxonomies
- Related guides
What a risk taxonomy is, and what it is not
| Artifact | What it is | Relationship to the taxonomy |
|---|---|---|
| Risk taxonomy | The classification scheme: categories, hierarchy, definitions | The thing itself; changes rarely |
| Risk register | The list of specific risks the organization has identified, with owners, ratings and controls (guide) | Each entry is classified to one taxonomy category; the register changes constantly |
| Risk universe or inventory | Sometimes used for the full population of risks before prioritization | Classified by the taxonomy; often the same thing as the register at a lower threshold |
| Audit universe | The auditable entities (processes, units, systems) internal audit can choose from (guide) | A different axis; mapped to the taxonomy so coverage can be shown by risk category |
| Control taxonomy | The classification of controls (preventive, detective, manual, automated) (guide) | Separate; controls are classified by their own attributes and linked to risks |
| Risk appetite statement | Tolerances by category (guide) | Written against the level-1 and level-2 categories |
| Loss event classification | The categories used to code loss events | Should be the same taxonomy, or a documented mapping to it |
The distinction that matters most is between the taxonomy and the register. The taxonomy says “credit risk is a category, defined as follows”. The register says “the risk that our largest customer defaults, owned by the CFO, rated High”. Organizations that confuse the two end up with a taxonomy of several hundred items that is really a register, and no way to classify anything.
Why it matters: aggregation and the end of double counting
Three problems disappear when a taxonomy exists and everyone uses it. Aggregation: the board can be told that operational losses in the period were $2.1 million, of which $1.4 million was process failure, because every event was classified the same way; without a taxonomy, losses recorded by six units in six vocabularies cannot be added. Double counting: a risk recorded as “cyber attack” by IT, “data breach” by compliance and “reputational damage from a breach” by communications is one risk counted three times and owned by nobody; a taxonomy with a rule that each risk has one home forces the three to be reconciled. Comparison: a residual rating of High in the lending RCSA and High in the treasury RCSA mean the same thing only if the categories and scales are shared, and the taxonomy is half of that. The ERM misconceptions guide lists the symptoms of a program without one; the ERM role guide explains why internal audit cares.
Six design rules
| Rule | What it means | Test |
|---|---|---|
| 1. Mutually exclusive | A risk fits one category and only one | Take twenty register entries and ask three people to classify them; disagreements show overlapping categories or missing definitions |
| 2. Collectively exhaustive | Every risk the organization could face has a home; “other” is not a category | Classify the last two years of incidents, audit findings and near misses; anything that does not fit means a gap |
| 3. Events, not causes or effects | Categories describe what could happen (the event), not why (the cause) or what it leads to (the effect); see the next section | Every category name should complete the sentence “the risk that [event] occurs” |
| 4. Stable at the top, flexible at the bottom | Level 1 changes only by board decision and rarely; level 3 can be added to by the risk function | Level 1 has six to ten categories and has not changed in three years; level 3 grows |
| 5. Defined with inclusions and exclusions | Each category has a one-sentence definition, examples of what is in it, and a statement of what is not and where that goes | The definition card template below |
| 6. Owned and versioned | One function owns the taxonomy; changes are logged; every tool uses the current version | A version number appears in the register, the RCSA tool and the loss database |
Cause, event, effect: the confusion that breaks most taxonomies
A risk has three parts: a cause (why it might happen), an event (what happens) and an effect (the consequence). “Inadequate training leads to incorrect customer pricing which causes revenue loss and complaints” has a cause (training), an event (incorrect pricing) and two effects (revenue, complaints). Taxonomies break when categories are drawn from different parts of that chain: a taxonomy with “people risk” (a cause), “pricing error” (an event) and “reputational damage” (an effect) will classify the same risk three ways. The rule is to build the taxonomy on events, because events are what the organization can count (they happen or they do not), what controls act on, and what losses attach to. Causes become a separate root-cause classification used in incident analysis (the root cause guide gives one), and effects become the impact dimensions of the rating scale (financial, customer, regulatory, operational, reputational). Reputational risk is the classic casualty of the confusion: it is almost always an effect of another event, and most mature taxonomies treat it as an impact dimension rather than a category, with the reputation risk primer explaining the exception for organizations whose reputation is itself the product.
The three-level architecture
| Level | Purpose | Count | Who uses it | Who may change it |
|---|---|---|---|---|
| Level 1 | Board-level aggregation; appetite statements; the chapters of the risk report | 6 to 10 | Board, executive committee, regulators | Board, on the CRO’s proposal, rarely |
| Level 2 | Management aggregation; RCSA structure; KRI families; audit coverage reporting | 25 to 50 | Risk committee, business heads, internal audit | Risk committee, annually |
| Level 3 | Classification of individual risks, loss events and findings; the level at which the register is coded | 80 to 200 | Risk owners, the risk function, auditors | The risk function, with a change log |
Two levels is too few for any organization large enough to need a taxonomy (level 1 becomes unusable for coding events). Four is too many for almost everyone; the fourth level is usually the register trying to climb into the taxonomy. The Basel operational risk event types, which many banks adopt as part of level 2 and 3, are themselves a two-level scheme (seven level-1 event types with level-2 subtypes) nested inside the bank’s operational risk category, which shows how an external taxonomy slots into a three-level architecture.
A full three-level example
The example below is a general-purpose taxonomy with eight level-1 categories, which fits most mid-size organizations and can be extended for a bank (see the next section). Level 3 is shown for the categories where it is least obvious; a complete version runs to about 120 level-3 entries.
| Level 1 | Level 2 | Level 3 (examples) |
|---|---|---|
| 1. Strategic | 1.1 Strategy selection and execution; 1.2 Market and competitive position; 1.3 Mergers, acquisitions and partnerships; 1.4 Product and innovation; 1.5 Macroeconomic and geopolitical | 1.2.1 Demand shift; 1.2.2 New entrant or substitute; 1.3.1 Integration failure; 1.3.2 Valuation and due diligence; 1.5.1 Trade and tariff change; 1.5.2 Currency regime |
| 2. Financial | 2.1 Credit; 2.2 Market (interest rate, FX, commodity, equity); 2.3 Liquidity and funding; 2.4 Capital and solvency; 2.5 Financial reporting and tax | 2.1.1 Customer default; 2.1.2 Counterparty and settlement; 2.1.3 Concentration; 2.2.1 Interest rate; 2.2.2 Foreign exchange; 2.2.3 Commodity price; 2.3.1 Funding availability; 2.3.2 Cash flow timing; 2.5.1 Misstatement; 2.5.2 Tax position |
| 3. Operational | 3.1 Process execution; 3.2 People and workforce; 3.3 Physical assets and facilities; 3.4 Business disruption and resilience; 3.5 Fraud (internal and external); 3.6 Health, safety and environment | 3.1.1 Transaction processing error; 3.1.2 Data entry and reconciliation; 3.1.3 Product or service quality; 3.2.1 Key person loss; 3.2.2 Capacity and capability; 3.2.3 Employment practices; 3.4.1 Site outage; 3.4.2 Supply interruption; 3.5.1 Internal fraud; 3.5.2 External fraud |
| 4. Technology | 4.1 Cyber and information security; 4.2 System availability and performance; 4.3 Change and development; 4.4 Data integrity and governance; 4.5 Technology obsolescence | 4.1.1 Unauthorized access; 4.1.2 Ransomware and destructive attack; 4.1.3 Data breach; 4.2.1 Core system outage; 4.3.1 Failed change; 4.4.1 Data quality; 4.4.2 Model and algorithm error |
| 5. Legal, regulatory and compliance | 5.1 Regulatory compliance; 5.2 Legal and contractual; 5.3 Conduct and customer treatment; 5.4 Financial crime compliance; 5.5 Privacy and data protection | 5.1.1 Licensing and reporting; 5.1.2 Regulatory change; 5.2.1 Contract breach; 5.2.2 Litigation; 5.3.1 Mis-selling; 5.3.2 Complaints handling; 5.4.1 Money laundering; 5.4.2 Sanctions; 5.5.1 Unlawful processing |
| 6. Third party and supply chain | 6.1 Supplier performance and failure; 6.2 Outsourcing and service providers; 6.3 Concentration and fourth parties; 6.4 Supply chain integrity | 6.1.1 Critical supplier failure; 6.2.1 Service provider control failure; 6.3.1 Single-source dependency; 6.4.1 Counterfeit or substandard inputs |
| 7. Governance and people leadership | 7.1 Board and executive governance; 7.2 Culture and ethics; 7.3 Organizational change | 7.1.1 Oversight failure; 7.1.2 Decision rights unclear; 7.2.1 Misconduct tolerance; 7.3.1 Restructuring execution |
| 8. Environmental, social and climate | 8.1 Physical climate; 8.2 Transition; 8.3 Social and community; 8.4 Sustainability reporting | 8.1.1 Acute weather event; 8.1.2 Chronic change; 8.2.1 Carbon pricing and regulation; 8.4.1 Disclosure error |
Three choices in the example are deliberate and contestable. Reputational risk is absent as a category and present as an impact dimension, for the reason given above. Fraud sits under operational risk as an event family (3.5) rather than as a level-1 category, because that is where its losses are counted and where the Basel event types place it; organizations with a large fraud exposure sometimes promote it. And conduct (5.3) sits under legal, regulatory and compliance rather than operational, because its oversight usually lives in compliance; the fraud tree and the conduct risk guide give the level-3 detail for those two.
The same structure for a bank and for a manufacturer
The level-1 structure survives across industries; what changes is the weight and depth of each branch. A bank’s financial risk branch is where the capital is and gets the most level-3 detail; a manufacturer’s operational and supply chain branches carry the business. The table shows the same eight level-1 categories as they appear in the two organizations used in examples across this site: Lakeshore Bancorp, a $9 billion regional bank, and Brightwater Foods, a $180 million food manufacturer.
| Level 1 | Lakeshore Bancorp (bank) | Brightwater Foods (manufacturer) |
|---|---|---|
| Strategic | Modest: strategy execution, M&A, competitive position against digital entrants | Larger: customer concentration (two retailers at 48 percent of sales), category shifts, private-label competition |
| Financial | The core: credit (commercial, consumer, concentration), interest rate (EVE, NII), liquidity, capital; aligned to the OCC’s risk categories so examiners recognize it; level 3 runs to 30 entries | Thin: commodity price (ingredients, packaging), FX on imported inputs, customer credit, covenant compliance; eight level-3 entries |
| Operational | Process (payments, lending operations), fraud, people; Basel’s seven event types nested at level 3 for loss data | The core: production quality and food safety, plant downtime, workforce (skilled operators, seasonality), physical assets, health and safety; level 3 runs to 25 entries |
| Technology | Cyber, core banking availability, change, data, models (CECL, fraud scoring) | ERP availability, OT and plant control systems, cyber (ransomware readiness) |
| Legal, regulatory and compliance | Large: prudential, consumer protection, financial crime, conduct, privacy; regulator relationship | Food safety regulation, labeling, employment law, environmental permits |
| Third party and supply chain | Core provider, cloud concentration, outsourced servicing | Sole-source ingredient and packaging suppliers, co-packers, logistics, cold chain |
| Governance and people leadership | Board oversight under heightened standards; culture; conduct tolerance | Family-ownership transition; a first audit committee; safety culture |
| Environmental, social and climate | Transition risk in the loan book; physical risk to branches; disclosure | Physical risk to plants and crops; water; packaging regulation; emissions reporting to retail customers |
Writing definitions that prevent disputes
A category name is not a definition. “Third party risk” means outsourcing to the risk function, suppliers to procurement and vendors to IT, and without a definition each will classify differently. A definition that works has four parts: a one-sentence statement in the form “the risk that [event] occurs”, two or three inclusions (examples that belong), two or three exclusions with their correct home (“excludes failure of a supplier’s own supplier, which is 6.3 concentration and fourth parties”), and the boundary with its nearest neighbor. Exclusions do the most work; they are what the classifier reads when a risk seems to fit two places. The template at the end gives the card.
Mapping the taxonomy to the organization and to the audit universe
A taxonomy is one axis of a matrix whose other axis is the organization: business units, processes, legal entities, geographies. The matrix is where risk ownership lives (unit X owns category Y’s risks within its operations) and where the audit universe connects. Internal audit’s universe is built from auditable entities (the universe guide), and mapping each entity to the taxonomy categories it carries lets the function report coverage by risk category (“we audited 70 percent of the entities carrying technology risk this cycle”) rather than only by entity. The annual risk assessment uses the same matrix to score entities, and the plan guide shows the coverage view. A simple rule keeps the matrix honest: every level-3 category must appear against at least one owner, and every auditable entity must carry at least one category; blanks in either direction are findings.
Governance: who may change it, and how
| Element | Rule that works |
|---|---|
| Owner | The risk function (the chief risk officer or head of ERM); internal audit is a user and a tester, never the owner |
| Level 1 changes | Proposed by the owner, approved by the board or its risk committee; expect one every few years |
| Level 2 changes | Approved by the executive risk committee at the annual review |
| Level 3 changes | Made by the owner on request, logged with the date, the requester and the reason; published quarterly |
| Version control | A version number and date; every tool (register, RCSA, loss database, KRI library, audit universe) records which version it uses; a mapping table when categories are merged or split so history can be restated |
| Retirement | A category is retired, not deleted; historical events keep their code with a pointer to the successor |
| Review trigger | Annual, plus a material change in the business (acquisition, new line), a regulatory taxonomy change, or evidence from classification disputes |
Aligning with external taxonomies
Several external schemes exist and the question is whether to adopt one, map to one or ignore them. The Basel Committee’s operational risk event types (internal fraud; external fraud; employment practices and workplace safety; clients, products and business practices; damage to physical assets; business disruption and system failures; execution, delivery and process management) are mandatory for banks’ loss data in most jurisdictions and are best nested at level 3 under operational risk. The OCC’s risk categories for national banks (primer) are the examiner’s vocabulary and a bank’s level 1 should be reconcilable to them. ORX, the operational risk consortium, publishes a reference taxonomy for operational and non-financial risk that many financial institutions use as a starting point for level 2 and 3. COSO’s ERM framework (2017) and ISO 31000 (2018) do not prescribe taxonomies but expect one. The frameworks comparison covers the differences. The practical rule: adopt the external scheme where a regulator will test against it, map to it where a peer group reports by it, and otherwise build for the organization’s own use.
Eight failures that make taxonomies useless
| Failure | How it shows | Fix |
|---|---|---|
| Causes, events and effects mixed | “People risk”, “pricing error” and “reputational damage” as sibling categories | Rebuild on events; move causes to root-cause codes, effects to impact dimensions |
| The register in disguise | 300 “categories”, each a specific risk | Separate the register from the taxonomy; cap level 3 |
| “Other” as a category | A third of events coded to other | Analyze the other bucket; add the missing categories |
| Different taxonomies in different tools | RCSA tool, loss database and audit universe each with their own | One version, published; mapping tables for the transition |
| No definitions | Classification disputes; the same event coded three ways | Definition cards with exclusions |
| Level 1 too long | Eighteen level-1 categories; the board report has eighteen chapters | Six to ten; demote the rest |
| Changed without versioning | Trend reporting breaks; last year’s data cannot be compared | Change log; restatement mapping |
| Owned by nobody | Each function edits its own copy | Name the owner; make the risk committee the approver |
How internal audit uses and tests the taxonomy
Internal audit uses the taxonomy twice and tests it once. It uses it to structure the audit universe and to report coverage by risk category, as above; and it uses it to classify findings, so that the annual report can say which categories produced the year’s High findings, which is the insight Domain I of the Standards asks for. It tests it as part of the framework audits: the operational risk framework audit’s test T3 traces the taxonomy into every tool and finds the places where it diverges, and the classification sample in the loss data test finds the events coded wrongly. A function advising on a taxonomy’s design, as in the worked example, must keep the advice within the objectivity safeguards of Standard 2.3: internal audit can propose and challenge; the risk function decides and owns.
Template: the category definition card
Category: [6.1 Supplier performance and failure]. Level: [2]. Parent: [6 Third party and supply chain]. Definition: The risk that a supplier of goods or services fails to perform, delivers below the agreed standard, or ceases to supply. Includes: insolvency of a supplier; late or short delivery; quality failure in supplied inputs; a supplier’s withdrawal from the market. Excludes: failure of a supplier’s own supplier (6.3 Concentration and fourth parties); control failures at an outsourced service provider operating a process on our behalf (6.2 Outsourcing and service providers); counterfeit or adulterated inputs (6.4 Supply chain integrity); the cost effect of commodity price moves (2.2.3 Commodity price). Nearest neighbor and boundary: 6.2 covers providers who run a process for us; 6.1 covers providers who sell us something. Typical owners: procurement, plant managers. Related KRIs: supplier on-time-in-full rate; critical supplier financial watch flags. Loss event mapping: Basel event type 7 (execution, delivery and process management) when the failure causes a loss. Version: [2.1, 2026-06-30]. Change history: [split from “Supply chain” in v2.0].
Worked example: Brightwater Foods replaces a flat list with a taxonomy
Brightwater Foods, the $180 million food manufacturer with three plants used in examples across this site, had a risk register of 140 entries built up over five years by whoever was asked to add to it: “key person leaves”, “inadequate training”, “customer complaint volume”, “ransomware”, “loss of major customer”, “bad publicity”, “supplier goes bust”. Its first chief audit executive, in the function’s second year, found that the register mixed causes, events and effects, that the plant safety incident log, the IT incident system and the register used three different vocabularies, and that the board’s risk report listed the top twenty entries without any way to say what kind of risk dominated. The CAE proposed, as an advisory engagement under the objectivity safeguards, that the finance director (who held the ERM role) build a taxonomy, with internal audit as challenger.
The build took one quarter and about 90 hours across the finance director, the quality director and internal audit. The eight level-1 categories above were adopted unchanged. Level 2 was drawn by classifying the 140 register entries plus two years of safety incidents, IT incidents and audit findings: 31 level-2 categories, with operational risk carrying nine of them. Level 3 ran to 94 entries. Classifying the register was the revealing step: 140 entries became 71 risks once causes were stripped into a root-cause list and effects into impact dimensions, 22 entries were duplicates of each other under different names, and 9 described events the company had no control over and no response to, which were kept as level-3 categories with a note that they were monitored rather than managed. Definitions with exclusions were written for all 31 level-2 categories; the dispute that took longest was whether a co-packer’s failure was 6.1 (supplier) or 6.2 (outsourcing), resolved as 6.2 with the boundary written into both cards. The register, the plant RCSA, the safety and IT incident systems and internal audit’s universe were all re-coded to version 1.0 in the following quarter.
| Measure | Before | After (version 1.0) |
|---|---|---|
| Structure | Flat list, 140 entries | 8 / 31 / 94 three-level taxonomy; 71 register risks coded to level 3 |
| Cause, event, effect | Mixed | Events only; 18 root-cause codes; 5 impact dimensions in the rating scale |
| Duplicates | 22 identified | 0 |
| Definitions | None | 31 level-2 cards with exclusions |
| Tools sharing the taxonomy | 0 (three vocabularies) | 5: register, RCSA, safety incidents, IT incidents, audit universe |
| Board report | Top 20 entries | Profile by level 1 with the top risks under each; losses and incidents aggregated by category |
| Owner and governance | None | Finance director; level 1 by the board; change log; annual review |
| Internal audit coverage view | By plant and function | By plant and by risk category; technology risk coverage found at 40 percent, raised in the next plan |
The first board report on the new basis showed operational risk carrying 61 percent of the year’s incidents and third-party risk 18 percent, which was the first time the board had seen the shape of its own risk; the audit committee asked for the resilience assessment described in the third-party resilience guide on the strength of it. The CAE’s own test, a year later, took twenty new register entries and had three people classify them: two disagreements, both resolved by tightening a definition.
Questions about risk taxonomies
How many level-1 categories should a taxonomy have?
Six to ten. Fewer than six forces unlike risks together; more than ten makes the board report unreadable and usually means causes or effects have crept into level 1.
Should reputational risk be a category?
Usually not. Reputational damage is the effect of some other event, and treating it as a category produces double counting. Most mature taxonomies make reputation an impact dimension in the rating scale. Organizations whose reputation is itself the product (ratings agencies, professional firms) sometimes keep a narrow category for events that directly attack it.
Where does cyber risk go?
Under technology at level 2 in most taxonomies, with level-3 entries for unauthorized access, destructive attack and data breach. Banks following the Basel event types also map cyber events to the operational risk event types for loss data, which a mapping table handles.
Is a risk taxonomy the same as a risk universe?
No. The taxonomy is the classification scheme; a risk universe is the population of identified risks, which the taxonomy classifies. The audit universe is different again: the auditable entities, mapped to the taxonomy so coverage can be shown by category.
Who should own the taxonomy?
The risk function, under the risk committee, with level-1 changes approved by the board. Internal audit uses and tests it and may advise on its design, but should not own it, because it will later assure the framework the taxonomy belongs to.
How often should it change?
Level 1 rarely, by board decision; level 2 at an annual review; level 3 as needed with a change log. Every change is versioned so that history can be restated and trends compared.
Can a small organization skip the taxonomy?
A 200-person organization can manage with two levels and twenty categories, but it still needs the discipline: events not causes, one home per risk, definitions with exclusions, one owner. The cost is a few days; the benefit is a risk report that can be aggregated.
Related guides
- The risk register — the list the taxonomy classifies.
- Risk appetite statements that guide decisions — tolerances by category.
- How to run an RCSA — the assessment structured by the taxonomy.
- Key risk indicators by risk type — indicators organized by category.
- OCC risk categories — the examiner’s taxonomy for banks.
- Risk management frameworks compared — COSO, ISO 31000 and NIST.
- Five misconceptions about ERM — the symptoms of a program without a taxonomy.
- Internal audit’s role in ERM — advising without owning.
- Building the audit universe — the other axis of the coverage matrix.
- The annual internal audit risk assessment — scoring entities by category.
- Preventive, detective and corrective controls — the control taxonomy, kept separate.
- Root cause analysis for audit findings — the cause classification.
- Reputation risk for internal auditors — the exception to the impact-dimension rule.
- The ACFE fraud tree — level-3 detail for fraud.
- Third-party risk management end to end — level-3 detail for third parties.
- Operational risk guide — the Basel event types explained.
- Risk Appetite vs Tolerance vs Capacity vs Limits, Explained — the four layers defined and cascaded, with a testable appetite statement
- Compliance Risk Assessment: Method, Scoring, Worked Example — obligations inventory, exposure scoring and prioritization that regulators accept
- Auditing the ERM Program: Criteria, Maturity, Independence — criteria, maturity and the independence trap when auditing the second line
Leave a Reply