Why the Classification Dimension Matters
A risk description can contain several different kinds of information: what gives rise to the risk, what might happen, what the result could be, and what the organization is trying to achieve. A taxonomy can organize risks using any of these dimensions, but the dimension needs to be clear. Otherwise, a list of categories can put a cause beside an event beside an impact, as if they answered the same question.
For example, a hypothetical insurer might face a risk that a system weakness allows unauthorized access, leading to a service outage and delayed claims payments. A source-based taxonomy could classify the system weakness. An event-based taxonomy could classify unauthorized access or the outage. A consequence-based taxonomy could classify delayed claims payments. An objective-based taxonomy could organize the risk under continuity of claims service. The risk has not changed; the organizing question has.
Four Dimensions, Four Questions
A practical way to distinguish the dimensions is to ask one question at a time. The same scenario can provide an answer to all four, but each answer belongs to a different part of the risk description.
| Dimension | Organizing question | Illustrative category | Typical use |
|---|---|---|---|
| Source | What origin or condition gives rise to the risk? | Technology vulnerability | Understanding drivers and directing preventive attention |
| Event | What might happen? | Unauthorized system access | Grouping incidents or plausible occurrences |
| Consequence | What effect could follow? | Delayed claims payments | Understanding potential business effects |
| Business objective | Which intended result could be affected? | Continuity of claims service | Connecting risk discussion to priorities and decisions |
These categories are not interchangeable labels. A source is not an event simply because it is described in a sentence about a possible event. A consequence is an effect, not the objective the organization intended to achieve. For example, “claims payments are delayed” describes a consequence; “pay valid claims promptly” describes an objective. An objective-based taxonomy asks which objective is at stake, not what the adverse outcome is called.
The useful dimension depends on the purpose of the classification. A team responsible for reducing vulnerabilities may need a source-based view. A group reviewing reported incidents may prefer an event-based view. Leaders considering the range of effects on the business may need a consequence-based view. A discussion organized around strategic or operational priorities may use objectives. A single dimension is not best for every task.
Selecting a Dimension and Keeping It Consistent
Before assigning a category, state what the taxonomy is intended to help people do. Then select the dimension that answers the question most directly. At a given level, categories should answer the same organizing question and be defined at a comparable level of detail. A hierarchy can have multiple levels, but each level should still have a clear organizing principle.
Identify the decision or activity the taxonomy should support, such as reviewing incidents, directing preventive attention, or discussing risks to business objectives.
Use “what gives rise to it?” for sources, “what might happen?” for events, “what effect could follow?” for consequences, or “which objective is affected?” for objectives.
Place each risk according to the selected question, using category definitions that are sufficiently clear to support consistent assignments.
If a label answers a different question from the other labels at that level, revise the structure or make the separate dimension explicit rather than treating unlike labels as peers.
This process has an important practical justification. When categories at the same level answer one common question, a reader can interpret comparisons consistently. If one category names a source and another names a consequence, the categories are not comparable in meaning: one risk may fit both, and two risks that share a category may share only a cause or only an effect. A consistent dimension makes a taxonomy more useful for the purpose it was chosen to serve.
This does not mean that a complete risk description should contain only one element. A risk statement can still explain a source, an event, and an impact. The discipline applies to the classification: decide which element is being used for the category assignment. The other elements can remain in the description without being mixed into that category level.
Worked Example: Choosing a Dimension for Control Planning
A hypothetical insurer records this risk: “An outdated access-control process could allow an unauthorized person to change claim records, causing rework and delays in claim handling.” A manager wants a taxonomy to help teams identify where preventive controls should be strengthened. Choose the most suitable primary dimension and classify the risk. Name the method and identify the mistake it avoids.
Method. Match the taxonomy to the stated use, then classify using the element that answers that taxonomy’s organizing question.
Step 1: State the purpose. The taxonomy is intended to help direct preventive control attention. That points toward understanding the conditions that give rise to risks, rather than grouping resulting effects.
Step 2: Select the dimension. A source-based dimension answers, “What origin or condition gives rise to the risk?” Here, the relevant source is the outdated access-control process.
Step 3: Assign the category. Classify the risk under a source category such as access-control weakness. The possible unauthorized change is the event; rework and delays are consequences. They remain useful details in the risk statement, but they are not the selected category dimension.
Check. The category names a condition that preventive controls could address, which matches the stated purpose.
Common mistake avoided. Classifying this under “claims delays” would label a consequence rather than a source. That could be appropriate for a consequence-based view, but it does not answer the control-planning question as directly.
Worked Example: Choosing a Dimension for an Incident Review
A hypothetical insurer is designing a register for a monthly review of operational incidents. It wants reviewers to group records by the kind of occurrence that took place. One record states: “A faulty software update interrupted the policy administration system for two hours, preventing staff from issuing some policy documents.” Choose the appropriate dimension and provide a consistent classification. Explain the trap in using another element of the sentence.
Method. Identify the review’s organizing question, then distinguish what happened from its origin and its effects.
Step 1: Interpret the stated use. The register is for grouping incidents by the kind of occurrence. That is an event-based purpose: it asks what happened.
Step 2: Separate the elements. The faulty software update is the source. The system interruption is the event. The inability to issue some policy documents is a consequence.
Step 3: Classify the record. Assign it to an event category such as system interruption. The category describes the occurrence recorded in the incident register.
Check. Other records assigned to that category should also describe a system interruption, not merely a software weakness or an adverse business effect.
Common mistake avoided. Using “faulty update” as the category would group the record by source, even though the register is designed to group incidents by occurrence. Using “policy-document delays” would instead classify it by consequence. Either could serve a different stated purpose, but neither answers this register’s question.
Worked Example: Choosing a Dimension for an Objective Review
A hypothetical insurer’s leadership team reviews risks against its objective of maintaining adequate financial resources to meet obligations. A scenario states: “A sharp decline in the value of a concentrated investment portfolio could reduce available capital below the insurer’s internal target.” The team wants its discussion grouped by the objective at stake. Select the dimension and classification, and explain why the outcome is not the objective.
Method. Use the business objective as the organizing question, and distinguish the intended result from the possible adverse outcome.
Step 1: Identify the requested question. Leadership wants to group risks by the objective that could be affected. Therefore, the selected dimension is business objective.
Step 2: Identify the objective. The stated objective is maintaining adequate financial resources to meet obligations. This is what the organization intends to achieve.
Step 3: Classify the risk. Place it in the objective category maintain financial capacity to meet obligations. The portfolio-value decline is a possible event, and available capital falling below the internal target is a possible consequence.
Check. The category names the objective, not the event or the outcome that could threaten it.
Common mistake avoided. Calling “capital below target” the objective reverses the relationship. It describes an adverse condition, whereas the objective is the intended condition of maintaining adequate resources.
Common Classification Traps
A frequent error is to create a list whose labels mix dimensions. For example, a level containing “cybersecurity,” “system outage,” and “financial loss” mixes a source area, an event, and a consequence. The labels may all relate to real risks, but they do not answer the same question. A reader cannot tell whether the list is intended to group risks by origin, occurrence, or effect.
Wrong classification: A taxonomy for grouping incidents lists “software vulnerability,” “unauthorized access,” and “customer disruption” as peer incident categories. The first is a source, the second an event, and the third a consequence.
Correction: If the purpose is to group incidents by occurrence, use event categories at that level, such as “unauthorized access” and “service interruption.” Keep sources and consequences in separate fields or use them in a separately identified classification view. The error is not that the other details are irrelevant; it is that they are being presented as if they were the same kind of category.
A second trap is choosing a dimension without considering use. An objective-based view can help leaders discuss priorities, but it may not be the most direct way to group incident records. A source-based view can help focus preventive attention, but it does not by itself describe what happened or the resulting effects. State the purpose before settling on the categories.
A classification is also not a complete description of a risk. Selecting one primary dimension means choosing one organizing basis for that taxonomy level; it does not mean the other elements of the risk statement should be discarded. Keeping those distinctions clear supports a more readable and useful enterprise view.
Check Your Understanding
For each scenario, identify the requested classification dimension and give the most suitable category. Keep the category focused on the dimension named by the purpose.
- A hypothetical insurer wants to direct preventive work. A weak reconciliation process could leave a premium amount incorrectly recorded. Which dimension and category best fit the purpose? (Answer: Source; reconciliation-process weakness.)
- A risk register is designed to group reported occurrences. A payment platform becomes unavailable for 45 minutes, and staff cannot process some transactions. Which dimension and category best fit? (Answer: Event; payment-platform outage or service interruption.)
- A leadership discussion groups risks by the intended result that could be threatened. A valuation error might cause reported liabilities to be misstated. If the objective is reliable financial reporting, what dimension and category should be used? (Answer: Business objective; reliable financial reporting.)
- A team groups potential effects to understand business disruption. A hypothetical storm damages an office and forces staff to work from another location. Which dimension and category best fit? (Answer: Consequence; office disruption or loss of normal workplace operations.)
- A taxonomy level for reviewing incidents contains “data-entry error,” “incorrect customer record,” and “customer complaint.” Identify the consistency problem and give one way to repair it if the intended purpose is incident grouping. (Answer: It mixes an event or error, a record condition, and a consequence; use event-based categories such as “data-entry error” consistently, while recording the other details separately.)