Enterprise Risk Identification and Interdependency Analysis

Introduction and Context

Enterprise risk management (ERM) begins before risk is measured, modelled, or treated. An organisation must first determine what can affect its objectives, how those events may arise, and how apparently separate risks may combine. Risk identification is therefore not a clerical exercise of listing hazards. It is an analytical process that connects strategy, business models, processes, people, technology, external conditions, and stakeholder expectations.

For a financial institution, an isolated view might identify credit risk, market risk, liquidity risk, operational risk, cyber risk, conduct risk, and regulatory risk as separate categories. In practice, these risks interact. A cyber incident may interrupt payments, trigger customer withdrawals, generate regulatory scrutiny, create reputational damage, and increase liquidity pressure. A decline in property prices may reduce collateral values, increase loan defaults, weaken capital, and constrain lending. Effective identification must reveal these causal chains and concentrations.

This chapter develops an applied methodology using interviews, workshops, process mapping, horizon scanning, bow-tie analysis, and systems thinking. It also considers data quality, governance, technology, judgement, and the limitations of each method.

Learning Objectives

By the end of this chapter, students should be able to:

1. Distinguish risk events, causes, consequences, controls, and objectives.
2. Design and conduct effective risk interviews and workshops.
3. Use process mapping to identify points of failure, control dependencies, and concentrations.
4. Apply horizon scanning to identify emerging and external risks.
5. Construct and interpret bow-tie analyses.
6. Use systems thinking to analyse feedback loops, common causes, and interconnected events.
7. Evaluate the quality, completeness, and bias of an enterprise risk register.
8. Translate interdependency analysis into governance, monitoring, and treatment decisions.

1. The Logic of Risk Identification

A useful risk statement links an uncertain event to an objective. A generic formulation is:

Because of [cause or condition], [event] may occur, leading to [consequence] for [objective].

For example: “Because privileged-access controls are inconsistently reviewed, unauthorised system access may occur, leading to payment disruption, financial loss, regulatory breach, and loss of customer trust.” This formulation is superior to “cyber risk” because it identifies a mechanism and consequences.

Several concepts must be separated:

• Objective: What the organisation seeks to achieve, such as maintaining solvency, processing payments, protecting customers, or complying with law.
• Cause or threat: A condition or source that could generate an event, such as weak access governance, inflation, fraud, or supplier dependency.
• Risk event: The occurrence that changes the organisation’s position, such as a system outage, borrower default, or data breach.
• Consequence: The effect on objectives, including financial, operational, legal, strategic, human, or reputational effects.
• Control: A measure that prevents an event, detects it, limits its effects, or supports recovery.
• Risk owner: The manager accountable for understanding and managing the risk, although ownership does not mean the person caused it.

A risk register should therefore record more than a risk category. At minimum, it should identify the objective affected, event, causes, consequences, existing controls, control owners, indicators, inherent exposure, residual exposure, and interdependencies.

Risk taxonomy and its proper use

A taxonomy provides a common language. Typical categories include strategic, financial, operational, technology, cyber, legal and regulatory, conduct, people, third-party, climate, and reputational risk. Taxonomies support reporting and accountability, but they can also create artificial boundaries. A single event may belong to several categories. For example, a supplier cloud outage is simultaneously a third-party, operational, technology, resilience, customer, and potentially regulatory risk.

The taxonomy should therefore be treated as an indexing system rather than a representation of reality. Causal analysis must take priority over classification.

2. Evidence, Scope, and Preparation

Risk identification is shaped by its scope. A board-level exercise may focus on objectives, strategic assumptions, and severe plausible scenarios. A business-process exercise may examine tasks, systems, handoffs, and controls. Before collecting evidence, the facilitator should define:

1. organisational units and legal entities included;
2. objectives and time horizon;
3. risk criteria and materiality thresholds;
4. relevant internal and external information;
5. participants and decision rights; and
6. expected outputs and escalation routes.

Evidence may include strategic plans, budgets, incident records, audit findings, loss data, near misses, complaints, regulatory communications, business-continuity plans, outsourcing contracts, system inventories, stress tests, and prior risk assessments. Historical loss data is valuable but insufficient: it records what has happened, not everything that could happen. Low-frequency, high-impact risks and emerging risks require structured judgement.

A disciplined identification process should distinguish known risks, developing risks, and unknown or poorly understood risks. The last category cannot be eliminated, but weak signals, scenario analysis, and diversity of perspectives can reduce blind spots.

3. Interviews and Workshops

Interviews

Interviews provide depth, especially where information is sensitive or distributed across specialist roles. A semi-structured interview combines consistent core questions with follow-up exploration. Useful questions include:

• What objectives are most difficult to achieve reliably?
• What could cause a significant failure in your area?
• Which assumptions must remain true for the process to work?
• Where are the major handoffs, delays, or single points of failure?
• Which controls are manual, judgement-dependent, or difficult to evidence?
• What events have nearly occurred but were prevented or contained?
• Which external developments could change the risk profile?
• Which other functions, suppliers, or systems would be affected by a disruption here?

The interviewer should ask for examples rather than accept broad labels. “Operational risk” should lead to questions about the event, causes, affected process, and consequences. Interviews should be confidential where necessary, but the resulting risk statements must be validated with relevant managers.

Common interview biases include overconfidence, availability bias, normalisation of deviance, and self-protective reporting. Employees may understate weaknesses if they believe findings will be used for blame. Psychological safety and a clear distinction between accountability and punishment improve the quality of evidence.

Workshops

Workshops are useful for surfacing cross-functional dependencies. A typical sequence is:

1. clarify objectives, scope, and terminology;
2. map critical activities and dependencies;
3. identify causes, events, and consequences;
4. review existing controls and control failures;
5. examine common causes and cascading effects;
6. rank or prioritise risks using agreed criteria; and
7. assign owners, evidence requirements, and follow-up actions.

A strong workshop includes operational staff, process owners, technology specialists, compliance or legal advisers, finance, risk professionals, and—when relevant—customer or supplier representatives. Seniority should not suppress operational knowledge. The facilitator should separate fact, assumption, and speculation, record dissenting views, and prevent the group from converging too quickly on a familiar list.

Workshops are not votes. Consensus is useful, but a minority view may identify a critical weakness. A “red team” or challenge role can deliberately test assumptions and ask what would invalidate the group’s conclusion.

4. Process Mapping as a Risk Identification Method

Process mapping represents how work actually flows. It can be performed at several levels:

• Value-chain level: major activities from customer need to delivered outcome.
• Process level: inputs, activities, decisions, outputs, and responsible roles.
• Task level: detailed steps, systems, data, controls, and exceptions.

For each activity, the analyst should ask:

• What input is required, and who provides it?
• What could make the input inaccurate, late, unavailable, or unauthorised?
• What decision is made, and what information supports it?
• What happens if the activity fails or is performed incorrectly?
• Is there a manual workaround?
• Which system, person, supplier, or location is indispensable?
• Does the next activity depend on timely completion?

Process mapping reveals control points and concentration points. A concentration exists when many products, customers, processes, or legal entities depend on the same resource. Examples include one payment processor, one cloud platform, one model-development team, one data feed, or one senior decision-maker.

The map should distinguish normal flow from exception flow. Risks often emerge in exceptions, such as rejected transactions, incomplete documentation, system reconciliation breaks, unusual customer behaviour, or emergency overrides. A process that appears resilient in normal conditions may fail when volume rises or several exceptions occur simultaneously.

Worked process example

Suppose a bank’s mortgage-origination process has five stages: application, credit assessment, approval, documentation, and funding. The same property-valuation vendor supplies information for assessment and collateral monitoring. A process map may reveal that:

• the vendor is a single source for 70% of valuations;
• approval staff cannot independently verify unusual valuations;
• documentation is manually re-entered into the funding system;
• a failed interface delays funding and creates customer complaints; and
• collateral data is also used in regulatory reporting.

The risk is not merely “vendor risk.” It includes valuation concentration, data integrity risk, conduct risk, operational delay, credit risk, and reporting risk. The shared vendor and shared data create interdependencies that would be missed by reviewing each risk category separately.

5. Horizon Scanning and Emerging Risks

Horizon scanning is the systematic search for developments that may alter the organisation’s risk profile. It examines political, economic, social, technological, environmental, legal, and industry trends. Sources include regulatory consultations, scientific and technical publications, patent activity, threat-intelligence reports, macroeconomic indicators, competitor actions, customer behaviour, supplier news, and internal near misses.

A useful scanning process has four stages:

1. Scan: collect signals without prematurely judging their importance.
2. Filter: assess relevance, plausibility, speed of development, and potential impact.
3. Interpret: construct scenarios and identify affected objectives and dependencies.
4. Act: assign monitoring indicators, trigger points, owners, and preparatory actions.

An emerging risk is not necessarily a newly invented hazard. It may be a familiar risk whose probability, velocity, scale, or interdependency is changing. Artificial intelligence, for example, may alter fraud, model risk, privacy, conduct, employment, intellectual-property, and third-party risk simultaneously.

The distinction between a signal and a risk event is important. A signal is an observation suggesting change; an event is an occurrence; a scenario is a structured description of how events could develop. Horizon scanning should avoid treating every trend as material. Assessment should consider the quality of evidence, plausible pathways, time to impact, reversibility, and management preparedness.

A practical emerging-risk record can include: signal, source, affected objective, plausible event, time horizon, transmission channels, uncertainty, indicators, current preparedness, and next review date.

6. Bow-Tie Analysis

Bow-tie analysis displays the relationship between causes, a central event, consequences, and controls. The left side contains threats and preventive controls; the centre contains the “top event”; and the right side contains consequences and mitigative or recovery controls.

For example, for a payment-system outage:

• Threats: software defect, cyberattack, power failure, supplier outage.
• Preventive controls: secure development, access management, redundancy, testing, supplier oversight.
• Top event: payment service unavailable or materially degraded.
• Consequences: failed transactions, customer harm, liquidity disruption, regulatory breach, reputational damage.
• Mitigative controls: incident response, manual processing, customer communication, recovery site, post-incident review.

The top event must be precise. “Cyber risk” is too broad; “unauthorised alteration of payment instructions is detected after release” may be sufficiently specific for analysis.

Bow-ties support questions that ordinary registers often omit:

• Which threats share the same preventive control?
• Which consequences depend on one recovery capability?
• Are controls preventive, detective, corrective, or recovery-oriented?
• What degradation factors could make a control ineffective?
• Are control assumptions tested under stress?

A bow-tie is qualitative unless supported by evidence. It does not automatically produce a probability or loss estimate. It can, however, identify where a single control failure would allow multiple threats through or where several consequences depend on the same response capability.

7. Systems Thinking and Interdependency Analysis

Systems thinking treats the enterprise as a network of interacting elements rather than a collection of independent risks. It asks how structure, incentives, delays, feedback, and adaptation create outcomes over time.

Types of interdependency

1. Causal dependency: one event directly increases the likelihood of another.
2. Resource dependency: several processes rely on the same people, capital, technology, data, or supplier.
3. Temporal dependency: the effect of one event changes the timing or severity of another.
4. Control dependency: multiple risks rely on the same control or assurance process.
5. Information dependency: decisions depend on the same data source or model.
6. Behavioural dependency: responses by customers, employees, markets, or regulators amplify or reduce effects.

A useful qualitative network represents risks as nodes and relationships as directed edges. Edges may be annotated as reinforcing, weakening, or conditional. For example, a rise in fraud may increase investigation workload; increased workload may delay reviews; delayed reviews may increase fraud losses. This is a reinforcing loop.

A balancing loop may also occur: rising losses trigger tighter controls, which reduce future losses, although excessive controls may slow service and encourage workarounds. Systems analysis must therefore consider second-order effects.

Concentration and common-cause failure

A concentration is an accumulation of exposure to a common driver. It may be visible, such as lending to one sector, or hidden, such as different products depending on the same cloud provider. Common-cause failure occurs when one cause disables several supposedly independent controls or processes.

Examples include:

• a shared identity platform failing across all business units;
• a flawed economic assumption embedded in several valuation models;
• a regional disaster affecting offices, staff, suppliers, and telecommunications;
• a common data error contaminating risk, finance, and regulatory reports.

Independence should never be assumed merely because exposures have different names or owners. Analysts should ask: “What would fail together?” and “Which assumption is common to these risks?”

Quantitative measures of interdependence

Quantitative analysis can support, but not replace, qualitative reasoning. If two loss variables X and Y have standard deviations σ_X and σ_Y, their correlation is:

Here, Cov(X,Y) is covariance and ρ_XY ranges from −1 to +1 when the standard deviations are positive. Correlation measures linear association; it does not prove causation and may be unstable during stress. It can also understate dependence in the tails.

For a portfolio loss L = L₁ + L₂ + … + L_n, variance is:

The first sum captures individual variances; the second captures pairwise covariance. This identity shows why aggregation based only on standalone risk estimates can understate total exposure. It assumes the losses are defined on a common basis and have finite variances. For severe operational or cyber losses, distributions may be skewed or heavy-tailed, making variance an incomplete measure.

#### Simple worked example

Suppose two exposures have standard deviations of 4 and 3 monetary units, with correlation 0.5. Their covariance is:

Cov(X,Y) = 0.5 × 4 × 3 = 6.

The variance of the combined exposure is:

Var(X+Y) = 4² + 3² + 2(6) = 49.

Thus the combined standard deviation is √49 = 7 monetary units. If the exposures had been incorrectly treated as independent, the variance would be 25 and the standard deviation 5. The difference illustrates the effect of interdependence. This is an illustrative calculation, not a complete capital or economic-loss model.

Correlation matrices, copulas, scenario analysis, Bayesian networks, fault trees, system-dynamics models, and network centrality measures may be used in advanced applications. Each requires assumptions about data, dependence structure, and model stability. Stress scenarios are especially important because relationships often strengthen during crises.

8. Integrating Methods into an ERM Workflow

The methods are complementary rather than interchangeable. Interviews reveal tacit knowledge; workshops expose cross-functional relationships; process maps locate dependencies; horizon scanning identifies change; bow-ties structure causal pathways; and systems thinking examines feedback and aggregation.

A practical workflow is:

1. establish objectives, scope, criteria, and governance;
2. review documents, incidents, indicators, and external intelligence;
3. conduct interviews across levels and functions;
4. map critical processes and dependencies;
5. hold cross-functional workshops;
6. develop bow-ties for material scenarios;
7. conduct interdependency and concentration analysis;
8. challenge assumptions through scenarios or red-team review;
9. document risks, controls, owners, indicators, and uncertainty; and
10. validate findings with decision-makers and integrate them into risk appetite, resilience, and planning.

Prioritisation should consider more than likelihood and impact. Relevant dimensions include velocity, persistence, detectability, control effectiveness, concentration, reversibility, stakeholder harm, regulatory significance, and uncertainty. A rare event with rapid onset and weak recovery capability may deserve priority over a more frequent but easily contained event.

9. Illustrative Case: The Interconnected Failure at Meridian Bank

Background

Meridian Bank is a fictional mid-sized commercial bank. It has expanded digital payments and outsourced cloud infrastructure, customer authentication, and several data services. Its risk register separately records cyber risk, third-party risk, liquidity risk, operational risk, conduct risk, and regulatory reporting risk.

Problem

A workshop is initiated after a short payment disruption. The initial incident appears minor because service was restored within two hours. However, customers experienced duplicate transaction messages, the fraud-monitoring system operated with delayed data, and the treasury team received inconsistent intraday liquidity information.

Analysis

Interviews identify several assumptions:

• the authentication provider is treated as highly reliable because it has not previously failed;
• the cloud provider’s resilience testing does not include simultaneous failure of a dependent data service;
• fraud monitoring and liquidity reporting use a common event stream;
• manual workarounds exist but have not been tested at peak transaction volume; and
• customer communications are controlled by a separate platform with the same cloud region.

Process mapping shows that five critical processes depend on the same identity service and event stream. The bow-tie top event is defined as “material degradation of digital payment processing.” Threats include provider outage, cyberattack, data corruption, and failed software deployment. Consequences include payment delays, fraud exposure, customer complaints, liquidity uncertainty, and inaccurate regulatory information.

Systems thinking identifies a reinforcing loop: service disruption increases customer support contacts; increased contacts divert staff from payment reconciliation; delayed reconciliation increases uncertainty; uncertainty encourages precautionary liquidity actions and escalations; these actions increase operational workload and prolong recovery. A common-cause concentration is also identified: authentication, customer communication, and payment services share infrastructure in one region.

Approach and solution

Meridian adopts the following measures:

• tests the full chain of dependent services rather than each supplier in isolation;
• establishes independent fallback authentication for critical transactions;
• separates critical data feeds for fraud monitoring and liquidity reporting;
• tests manual processing under realistic peak volumes;
• defines escalation thresholds for data inconsistency, not only system downtime;
• adds supplier concentration and control dependency to board reporting; and
• introduces scenario indicators, including authentication latency, reconciliation breaks, and delayed event-stream messages.

The bank also revises its risk taxonomy so that one incident can be linked to multiple objectives without creating duplicate ownership.

Outcome

The analysis does not eliminate the possibility of disruption. It improves visibility of shared dependencies, shortens detection time, clarifies decision rights, and directs investment toward independent recovery capability. The most important finding is not that any single supplier was unacceptable, but that the bank had mistaken component-level resilience for end-to-end resilience.

Learning points

1. Separate risk categories can conceal common infrastructure.
2. A short outage may create prolonged secondary effects.
3. Recovery controls require testing at realistic scale.
4. Data dependencies can transmit operational events into financial and regulatory risk.
5. Risk ownership must follow causal pathways, not only organisational charts.

10. Governance, Ethics, and Technology

Risk identification involves ethical choices. Incomplete identification can harm customers, employees, investors, and communities. Analysts should consider privacy, discrimination, accessibility, customer vulnerability, and the distribution of harm. Data used for risk analysis must be collected lawfully, protected appropriately, and interpreted with awareness of bias.

Regulators increasingly expect firms to demonstrate operational resilience, effective third-party oversight, sound model governance, cyber preparedness, and credible scenario analysis. Requirements differ by jurisdiction, but a general principle is consistent: organisations should be able to explain how material risks are identified, challenged, owned, monitored, and escalated.

Technology can improve identification through process-mining tools, dependency inventories, graph databases, incident analytics, natural-language review, and automated control testing. Artificial intelligence may help classify incident narratives or detect weak signals, but it introduces risks of hallucination, opaque reasoning, privacy breaches, automation bias, and poor handling of rare events. AI-generated risk statements require human validation, traceable sources, access controls, and documented review.

11. Challenges and Limitations

No identification method provides a complete view. Important limitations include:

• Data scarcity: rare events provide few observations.
• Changing systems: organisational structures, technologies, and suppliers evolve.
• Boundary problems: risks cross legal entities and reporting lines.
• Measurement illusion: numerical precision may conceal uncertain assumptions.
• Groupthink: workshops may reproduce prevailing management narratives.
• Taxonomy bias: categories may encourage siloed ownership.
• Model risk: dependence models may fail under structural breaks.
• Control optimism: documented controls may not operate consistently.
• Strategic secrecy: sensitive threats may be withheld or underreported.

These limitations justify triangulation. Material findings should be supported by more than one method and challenged by people with different expertise and incentives. The quality of a risk assessment depends not only on the sophistication of its tools but also on the quality of questions, evidence, challenge, and follow-through.

Best-Practice Checklist

An effective identification programme should:

• begin with objectives and critical services;
• use specific event-based risk statements;
• combine top-down strategy analysis with bottom-up process analysis;
• include near misses and weak signals;
• map suppliers, data, systems, people, and locations;
• test common-cause and concentration assumptions;
• distinguish preventive, detective, corrective, and recovery controls;
• analyse second-order and cross-category consequences;
• record uncertainty and dissent;
• assign accountable owners and review dates; and
• connect findings to risk appetite, resilience investment, scenario testing, and board decisions.

Chapter Summary

Enterprise risk identification is the structured discovery of events, causes, consequences, controls, and dependencies that may affect organisational objectives. A useful risk statement is specific enough to show how a cause may produce an event and how that event may affect an objective. Taxonomies support communication but should not replace causal analysis.

Interviews reveal tacit knowledge, workshops expose cross-functional relationships, and process mapping identifies control points, exceptions, and concentrations. Horizon scanning extends attention beyond historical data to weak signals and changing conditions. Bow-tie analysis organises threats, preventive controls, a central event, consequences, and recovery controls. Systems thinking examines feedback loops, shared resources, common causes, and cascading effects.

Interdependency analysis may be qualitative or quantitative. Correlation and variance aggregation can illustrate dependence, but they do not establish causation and may be unreliable during stress. The strongest ERM processes triangulate methods, challenge assumptions, incorporate ethical and regulatory considerations, and connect findings to ownership, monitoring, resilience, and strategic decisions.

Key Terms

Risk identification: The systematic process of discovering events, causes, consequences, and controls relevant to objectives.

Risk event: An occurrence that may alter the achievement of an objective.

Risk cause: A condition or source that can contribute to a risk event.

Consequence: The effect of a risk event on objectives or stakeholders.

Risk taxonomy: A structured classification scheme for organising risks.

Risk owner: The person accountable for managing and reporting a risk.

Process mapping: Representation of activities, decisions, inputs, outputs, roles, and dependencies.

Control point: A location in a process where prevention, detection, correction, or recovery occurs.

Concentration: Accumulation of exposure to a shared driver or resource.

Common-cause failure: Failure of multiple processes or controls due to one underlying cause.

Horizon scanning: Systematic search for external and internal developments that may change risk.

Weak signal: An early, incomplete indication of a possible emerging development.

Bow-tie analysis: A framework linking threats and preventive controls to an event, consequences, and mitigative controls.

Top event: The central loss-of-control event in a bow-tie analysis.

Systems thinking: Analysis of relationships, feedback, delays, and behaviour within an interconnected system.

Interdependency: A relationship in which risks, processes, or controls influence or rely on one another.

Correlation: A measure of linear association between two variables.

Control dependency: Reliance by several risks or processes on the same control.

Operational resilience: The capability to continue important services through disruption and recover within acceptable limits.

Emerging risk: A developing or changing risk whose effects, probability, or pathways are not yet fully understood.

Review Questions

Short Answer Questions

1. Distinguish a risk cause, risk event, and consequence.
2. Why should a risk taxonomy not be treated as a complete representation of enterprise risk?
3. Identify two advantages of semi-structured interviews.
4. What is the purpose of the top event in a bow-tie analysis?
5. Define common-cause failure and provide one example.

Long Answer Questions

1. Explain how interviews, workshops, and process mapping complement one another in an ERM identification programme.
2. Describe the stages of horizon scanning and explain how an organisation should distinguish a signal from a material emerging risk.
3. Explain how bow-tie analysis can reveal weaknesses in both preventive and recovery controls.
4. Discuss why risk categories may conceal interdependencies and concentrations.
5. Evaluate the benefits and limitations of using correlation and variance aggregation in enterprise risk analysis.

Analytical / Application Questions

1. A financial institution relies on one cloud provider for authentication, payments, customer communications, and fraud monitoring. Construct a qualitative interdependency analysis identifying common causes, cascading consequences, and possible controls.
2. Using a process of your choice, develop a bow-tie analysis with at least three threats, two preventive controls, three consequences, and two mitigative controls. Explain which controls are most dependent on one another.
3. A workshop team reports that a risk is “unlikely” because no loss has occurred in ten years. Critically assess this conclusion using process evidence, horizon scanning, scenario analysis, and systems-thinking concepts.

Multiple Choice Questions with Answers

Question 1

Which statement best represents a well-formed risk statement?

A. Cyber risk

B. Operational risk is important

C. Weak access reviews may permit unauthorised payment changes, causing financial loss and service disruption

D. Technology risk exists in the organisation

Correct Answer: C. Weak access reviews may permit unauthorised payment changes, causing financial loss and service disruption

Question 2

What is the primary purpose of process mapping in risk identification?

A. To eliminate all manual work

B. To identify activities, handoffs, dependencies, exceptions, and control points

C. To calculate the exact probability of every risk

D. To replace the organisation’s risk taxonomy

Correct Answer: B. To identify activities, handoffs, dependencies, exceptions, and control points

Question 3

In a bow-tie analysis, preventive controls are located:

A. Before the top event, on the threat side

B. After all consequences occur

C. Only within the recovery plan

D. Outside the causal pathway

Correct Answer: A. Before the top event, on the threat side

Question 4

Which example best illustrates a common-cause failure?

A. Two unrelated borrowers defaulting independently

B. A single identity-platform outage disabling several critical processes

C. A manager completing a control early

D. A supplier reducing its price

Correct Answer: B. A single identity-platform outage disabling several critical processes

Question 5

What is a weak signal in horizon scanning?

A. A confirmed loss event with a known cause

B. An early and incomplete indication of a possible developing risk

C. A formally approved control

D. A historical financial statement

Correct Answer: B. An early and incomplete indication of a possible developing risk

Question 6

If two exposures have standard deviations of 4 and 3 and correlation 0.5, what is their covariance?

A. 1.5

B. 6

C. 7

D. 12

Correct Answer: B. 6

Question 7

Which statement about correlation is correct?

A. It proves that one risk causes another

B. It measures linear association and may be unstable during stress

C. It always captures extreme-tail dependence

D. It can only range from 0 to 1

Correct Answer: B. It measures linear association and may be unstable during stress

Question 8

Which activity most directly tests whether a documented recovery control is usable?

A. Renaming the control in the taxonomy

B. Testing it under realistic disruption and volume conditions

C. Assigning it to a more senior manager

D. Removing it from the risk register

Correct Answer: B. Testing it under realistic disruption and volume conditions

Question 9

Why can a short technology outage create prolonged enterprise consequences?

A. Because outages never affect customers directly

B. Because feedback loops, reconciliation delays, and secondary dependencies may prolong effects

C. Because all outages automatically become solvency events

D. Because preventive controls cannot exist

Correct Answer: B. Because feedback loops, reconciliation delays, and secondary dependencies may prolong effects

Question 10

Which approach best reduces blind spots in material risk identification?

A. Relying only on historical loss data

B. Using one workshop attended only by senior executives

C. Triangulating interviews, process evidence, external scanning, scenarios, and challenge

D. Classifying every issue under one risk category

Correct Answer: C. Triangulating interviews, process evidence, external scanning, scenarios, and challenge