Risk Identification, Taxonomy, and Risk Language
Core concepts
Risk identification must be systematic and complete enough to support aggregation. Candidates should know the common identification techniques: process mapping and walkthroughs, workshops with subject-matter experts, interviews, loss-event and near-miss analysis, scenario analysis, external loss databases, key risk indicator (KRI) thresholds, regulatory change review, and brainstorming. Each has strengths: process mapping finds operational failure points, scenario analysis surfaces low-frequency high-severity exposures, and loss data grounds frequency assumptions.
A risk taxonomy is a hierarchical classification (for example strategic, financial, operational, compliance, conduct, technology) with defined subcategories and a controlled risk library so that like risks are named consistently across units. A risk statement should follow a cause–event–consequence structure: "Because X (cause), Y may occur (event), resulting in Z (consequence)." Avoid control language inside the risk statement; controls belong in the control description. Distinguish inherent risk (before controls) from residual risk (after controls).
Traps
Frequently tested traps: writing risks as control failures ("we lack a policy") rather than as exposures; vague labels like "operational risk" that cannot be scored; duplicating the same risk under different names; and omitting emerging or conduct risks because they lack historical loss data. Another trap is treating the taxonomy as static; it needs periodic review and version control.
Worked example / rule of thumb
Rule of thumb: "Cause, event, consequence, and no controls in the sentence." Example: weak statement - "Inadequate vendor oversight." Better - "Because vendor performance is not monitored against service levels, a vendor may fail to deliver critical services, causing customer harm and regulatory breach." This version names a cause, an event, and consequences, and can be scored for likelihood and impact.