ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
A risk taxonomy is a structured list of the kinds of risk an organization faces, with clear names and definitions, arranged so that everyone describes and groups risks in the same way. Without one, the same risk appears under three names, different departments count the same exposure differently and the board cannot see the total picture. With one, risks can be compared, aggregated and reported consistently.
This guide explains what a risk taxonomy is for, how to design one, how many levels to use, how to write good definitions, how to link it to ownership and reporting and how to keep it useful over time. It is general guidance that you should adapt to your sector and size.
A risk taxonomy answers a simple question: what kinds of risk do we have? It provides a common vocabulary so that a supply chain risk described in procurement matches the one described in finance. It also gives structure for the enterprise risk register, aggregation, reporting and analysis.
Free enterprise risk assessment
Which of your business risks sit above your appetite?
Set your criteria and appetite, pick from 36 strategic, financial, operational and compliance scenarios, rate them and decide how to treat each. Built to ISO 31000, and free.
Run the free enterprise risk assessment → or View premium report sample
ISO 31000 emphasises that risk management should be integrated and structured. A taxonomy is one of the tools that make this possible. See ISO 31000 on risk management for the principles. Without shared language, risk conversations turn into debates about definitions instead of decisions about what to do.
A good risk taxonomy is complete, meaning it covers all significant sources of risk, and mutually exclusive, meaning each risk fits in one place. It is simple enough to use, stable enough to compare over time and flexible enough to accommodate change. It matches how the organization is structured and how it reports.
Be careful of over-engineering. A taxonomy with two hundred categories will not be used. Aim for a handful of top-level categories and a manageable number of sub-categories, and let detailed descriptions live in the risk register.
Common top-level categories are strategic, operational, financial, compliance and legal, and external. Some organizations add technology and cyber, people, reputation, environmental and social, or project risk. Choose categories that reflect your business, your obligations and how leaders think about risk.
Start from existing sources: your risk register, incident logs, audit findings, regulatory requirements and industry lists. Interview managers and ask what keeps them awake. Test the draft by allocating a sample of real risks: if people cannot agree where a risk belongs, the categories need work.
| Level 1 category | Example level 2 risks | Typical owner |
|---|---|---|
| Strategic | Market shifts, competitor moves, strategy execution | Chief executive, strategy lead |
| Operational | Process failure, supplier disruption, people, technology | Operations, IT, HR |
| Financial | Liquidity, credit, market, reporting | Finance director |
| Compliance and legal | Regulatory breach, contract disputes, data protection | General counsel, compliance |
| External and emerging | Climate, geopolitical, pandemic | Executive committee |
Use two or three levels. Level one is the broad category. Level two breaks it down into specific risk types, such as “supplier failure” under operational. Level three, if needed, may describe specific scenarios. Going deeper adds effort with diminishing benefit.
Give each item an identifier and consistent naming. Use nouns or noun phrases for categories, and cause-and-effect statements for individual risks in the register. Keep the taxonomy separate from the register: the taxonomy classifies, the register records specific risks with ratings and owners. See the enterprise risk register for how they fit.
Each category needs a short definition and, ideally, examples and boundaries. State what is included and what is not. For example, “Operational risk: the risk of loss or disruption resulting from inadequate or failed internal processes, people, systems or external events affecting operations. Excludes strategic decisions, which are covered under strategic risk.”
Definitions prevent overlap and make classification consistent. Test them with new users, and refine wording that causes confusion. Publish the taxonomy where people can find it, with guidance and examples.
Assign an owner to each category or sub-category, someone senior who is responsible for the overall picture in that area. Link the taxonomy to risk appetite: appetite statements are often set by category, such as low appetite for compliance risk and higher appetite for strategic innovation risk.
Use the taxonomy in reporting: risk heat maps by category, key risk indicators by category and trends over time; see risk heat maps and KRI thresholds. Consistent categories let you aggregate and compare across business units, as discussed in risk aggregation.
You may need to map your taxonomy to regulatory categories, audit universes, insurance classes or standard frameworks. Keep a mapping table so that reports can be presented in the required structure without maintaining several separate lists. Compare your approach with COSO ERM principles and ISO 31000 vs COSO ERM to check for gaps.
Sector taxonomies, such as those used in banking or insurance, can be a useful starting point, but adapt them to your own risks rather than copying them wholesale.
Assign an owner, usually the head of risk, and review the taxonomy annually and after major changes such as acquisitions, new business lines or new regulation. Keep a change log, and avoid changes that break comparability without a good reason. When you do restructure, map old to new so history can be preserved.
Add a feedback route so users can propose changes or report confusion. If a risk repeatedly does not fit, the taxonomy may be missing a category. Use registers and incident data to find such patterns.
Frequent errors include too many categories, overlapping definitions, categories named after departments rather than risks, mixing causes and events, no owner, never updating the taxonomy and treating it as a substitute for judgement. Another is designing it in isolation, without testing on real risks.
Avoid these by keeping it simple, testing it, writing definitions and reviewing it regularly. A taxonomy is a tool for conversation, not an end in itself.
Some risks do not sit neatly in one category. Climate change touches strategy, operations, finance and compliance. Cyber threats span technology, operations and reputation. Assign a lead owner for each cross-cutting risk, list the contributing categories and make sure reporting shows the whole picture rather than fragments. Create a watch list for emerging risks that are not yet significant, review it each quarter and promote items to the main register when they mature.
Keep the approach practical. A short note on each cross-cutting risk, saying who leads, who contributes and how it is monitored, is usually enough to prevent gaps and double counting.
A regional retailer had risks listed under headings such as “IT”, “stores” and “finance”. Reports could not be compared, and some risks appeared in three places. The head of risk built a taxonomy with five top-level categories and about twenty sub-categories, tested it on eighty existing risks and refined the definitions.
After adoption, supplier disruption, previously split across three lists, appeared as one line with a clear owner. Board reports showed risk by category with trends, and appetite statements were set at category level. Confusion fell, and discussions moved from definitions to decisions.
Use the taxonomy as a prompt in workshops, so that participants consider every category rather than only the risks at the top of their minds. Ask, for each category, what could stop the unit from achieving its objectives. Tag every risk that comes out with its category and sub-category.
Then use the tags to spot patterns: categories with many high risks, categories with none, and risks that cross categories and need coordinated ownership. Emerging risks that do not fit the taxonomy are valuable signals and may justify new categories.
If you want a report and workbook that classify risks consistently, assign owners and summarise results by category, the Enterprise Risk Assessment Report and Workbook provides a structured layout for enterprise risk assessment. Whichever tool you use, a well-designed risk taxonomy gives the whole organization a common language for risk, which makes every other part of risk management easier.
A structured classification of risk types with clear names and definitions, used to describe, group and report risks consistently across the organization.
Two or three levels are usually enough. Level one broad categories, level two specific risk types, and level three only if scenarios need it.
No. The taxonomy classifies types of risk. The register records specific risks with ratings, owners and treatments, and uses the taxonomy to categorise them.
Usually the head of risk, with executive sponsorship and input from category owners.
At least annually, and after major changes such as acquisitions, new business lines or significant regulatory change.
September 30, 2026
