11.2 Risk Identification

11.2 Risk Identification

Risk identification is the systematic process of finding, recognizing, and describing risks that could affect objectives. Its purpose is completeness sufficient for decision making—not an endless list of every imaginable event. Identification starts with the objective, because a condition becomes relevant when it could alter an intended outcome.

Questions that expose risk

A structured review asks:

• What must happen for the objective to succeed?
• What could prevent, delay, degrade, or unexpectedly improve the result?
• What internal or external sources create uncertainty?
• What assumptions are being made, and how could they fail?
• Where are the dependencies, single points of failure, and concentrations?
• What changes in law, technology, markets, clients, competitors, or counterparties are emerging?
• Which controls could fail, be overridden, or become obsolete?
• What direct, indirect, delayed, or cumulative consequences could follow?

This approach avoids confusing a department with a risk. “Information technology” is an area; “unauthorized access changes customer account data, causing loss and regulatory breach” is a risk statement.

Identification techniques

No single method is complete. Common techniques include:

1. Interviews and workshops with process owners, control functions, technical specialists, and affected stakeholders.
2. Process mapping to identify handoffs, approvals, data inputs, reconciliations, and failure points.
3. Checklists and taxonomies based on regulation, industry experience, and prior assessments.
4. Incident, loss, complaint, and near-miss data showing how controls have failed.
5. Scenario analysis and stress exploration for rare, severe, or unprecedented events.
6. Document review of contracts, products, financial statements, audit findings, regulatory notices, and vendor arrangements.
7. Environmental scanning for legal, economic, technological, geopolitical, and social change.

Checklists improve consistency but can anchor the team to familiar risks. Workshops add judgment but can be dominated by senior voices. Incident data is concrete but backward-looking. Combining methods reduces blind spots.

Sources, events, and consequences

A strong description uses a cause-event-consequence form:

Because of source or cause, event may occur, leading to consequence for the objective.

For example: “Because customer cash reconciliations rely on a manual spreadsheet, an input error may remain undetected, causing an inaccurate balance, delayed settlement, client harm, and a books-and-records breach.” The statement makes it possible to test causes, controls, likelihood, and several consequences.

The same source can generate several events, and events can cascade. A vendor outage may halt order entry, delay confirmations, trigger complaints, and attract regulatory scrutiny. Dependencies should be explicit: the firm may appear diversified across systems while all use the same cloud region or telecommunications provider.

Emerging, aggregate, and systemic risk

An emerging risk is newly developing or changing in significance, often with limited data. Identification should not discard it merely because probability cannot yet be estimated precisely. Aggregate risk considers exposures that are modest individually but material together. Systemic risk concerns disruption that impairs broader market or financial-system functions through common exposures, interconnectedness, or loss of confidence.

The risk register

A useful register can record:

The register is an output, not the process itself. Copying last year's entries without challenging assumptions creates false confidence.

Completeness and stopping criteria

Identification is sufficiently complete when relevant perspectives and reliable sources have been used, major processes and dependencies have been examined, plausible severe scenarios have been considered, and additional effort is unlikely to change the decision materially. Unknowns and data gaps should be recorded rather than converted into unjustified certainty.

Exam method

Prefer a description that names cause, event, and consequence. Do not rely only on past losses. Look for hidden concentration, outsourcing dependencies, changes in conditions, and control failure. Assign an owner who can influence the risk—not merely the person who records it.

---

Completeness and Change Triggers

Identification should combine forward-looking and historical sources: process mapping, product approval, incident and near-miss data, complaints, audit findings, legal inventories, vendor dependencies, scenario workshops, market intelligence, and external loss events. The risk register is not static. New products, system migrations, acquisitions, regulatory changes, outsourced services, staffing changes, and unusual market conditions should trigger reassessment. A strong entry separates the underlying cause from the event and consequence, avoiding duplicates that describe the same exposure with different labels. It also identifies affected objectives and dependencies so later analysis does not overlook correlated or cascading failures.