Standards, Frameworks, and Risk Management Planning

Introduction and Context

Project risk management is not merely the maintenance of a risk register. It is a governance system through which uncertainty is identified, interpreted, allocated, treated, monitored, and communicated. Standards and frameworks provide common language and minimum expectations, but they do not remove the need for professional judgement. A project manager must translate broad principles into a risk methodology suited to the project’s objectives, contractual environment, technology, stakeholders, organizational culture, and regulatory obligations.

This chapter examines four important sources of guidance: ISO 31000, the Project Management Institute’s PMBOK framework, COSO Enterprise Risk Management (ERM), and sector-specific frameworks. It then develops the practical components of a project risk management plan: roles, risk appetite, thresholds, categories, the risk breakdown structure (RBS), escalation rules, reporting, and integration with project controls.

A central distinction is useful. A standard generally states principles or requirements that can guide consistent practice. A framework provides a structure for organizing governance, processes, and decision rights. A methodology translates principles and frameworks into procedures, tools, templates, timing, and accountabilities for a particular organization or project.

Learning Objectives

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

1. Explain the purposes and differences of ISO 31000, PMBOK, COSO ERM, and sector frameworks.
2. Design a proportionate risk management methodology for a project.
3. Define roles, responsibilities, risk appetite, tolerance, thresholds, and escalation rules.
4. Construct and use a risk breakdown structure.
5. Integrate risk reporting with governance, schedule, cost, quality, procurement, and change control.
6. Critically evaluate the limitations of standards and the risks of mechanical compliance.

1. The Architecture of Risk Governance

Risk governance connects strategic intent with operational decisions. At the highest level, the sponsor or governing board determines what outcomes matter, what levels of exposure are acceptable, and which decisions require escalation. The project manager and risk owners then implement responses within delegated authority.

A useful hierarchy is:

• Principles: values such as integration, inclusiveness, continual improvement, and evidence-informed decision-making.
• Governance: authority, accountability, oversight, and escalation.
• Framework: the organizational arrangement for managing risk.
• Methodology: the project-specific process and tools.
• Records: the risk register, assumptions log, issue log, decision log, reports, and lessons learned.
• Controls: actions that prevent, detect, reduce, transfer, or accept exposure.

Risk management should be integrated with project management rather than operated as a parallel administrative exercise. A risk may originate in a design assumption, appear as a procurement concern, become a schedule threat, and finally emerge as a cost overrun or safety incident. Separate registers can obscure this causal chain.

2. ISO 31000: Principles, Framework, and Process

ISO 31000 presents risk management as a set of principles, a framework, and a process. It is generic and can be applied across industries and organizational levels. Its central definition treats risk as the effect of uncertainty on objectives. This definition is important because uncertainty can generate both adverse and beneficial effects; therefore, opportunity is not excluded from risk management.

2.1 Principles

ISO 31000 emphasizes that risk management should be integrated, structured and comprehensive, customized, inclusive, dynamic, based on the best available information, and attentive to human and cultural factors. It also emphasizes continual improvement and the creation and protection of value.

These principles have managerial consequences. “Customized” means that a small internal project should not be burdened with the same approval architecture as a major infrastructure programme. “Inclusive” means that affected stakeholders and people with relevant knowledge should participate. “Dynamic” means that a risk assessment made at authorization is not sufficient for a project exposed to changing regulation or technology.

2.2 Framework

The ISO framework is concerned with leadership and commitment, integration, design, implementation, evaluation, and improvement. Senior management is expected to establish accountability and ensure that risk management is embedded in governance and decision-making.

2.3 Process

The process commonly includes communication and consultation, scope-context-criteria, risk assessment, risk treatment, monitoring and review, and recording and reporting. Risk assessment consists of identification, analysis, and evaluation.

The framework does not prescribe one universal risk matrix, scoring scale, reporting frequency, or software tool. This flexibility is a strength because it permits adaptation, but it also creates a design responsibility: the organization must make its criteria explicit and consistent.

3. PMBOK and Project Risk Management

The PMBOK body of knowledge organizes project management around principles, performance domains, and processes that have evolved across editions. In risk management, recurring practices include planning risk management, identifying risks, performing qualitative and quantitative analysis where appropriate, planning responses, implementing responses, and monitoring risks.

The PMBOK perspective is distinctly project-oriented. It connects risk with scope, schedule, cost, quality, resources, procurement, stakeholders, and project outcomes. It also distinguishes individual project risks from overall project risk. An individual risk is a condition or event that may affect one or more objectives. Overall project risk is the effect of uncertainty on the project as a whole, including interactions among individual risks and the effect of ambiguity or variability.

PMBOK guidance is generally descriptive rather than prescriptive. It provides practices and concepts, not a mandatory single process. A project manager should therefore avoid claiming that “the PMBOK requires” a particular matrix or meeting unless an organizational procedure has adopted it.

Important project risk artifacts include:

• risk management plan;
• risk register;
• risk report;
• assumptions and constraints log;
• issue log;
• decision log;
• lessons learned register;
• contingency and management reserve records; and
• change requests resulting from risk responses.

4. COSO ERM: Risk, Strategy, and Performance

COSO ERM is primarily an enterprise governance and performance framework. It connects risk with mission, strategy, objective-setting, performance, review, and communication. Its value in projects is greatest where the project is a major investment, transformation, regulated activity, or component of a portfolio.

COSO’s modern ERM perspective emphasizes five broad components: governance and culture; strategy and objective-setting; performance; review and revision; and information, communication, and reporting. The framework asks whether risk is considered when strategy is selected, objectives are set, performance is evaluated, and decisions are revised.

For project managers, COSO contributes three important ideas:

1. Risk ownership belongs to management. A risk function may facilitate and challenge, but it should not become the owner of every operational risk.
2. Risk is connected to performance. A project that meets cost and schedule targets but creates unacceptable safety, compliance, or reputational exposure has not necessarily performed well.
3. Portfolio context matters. A risk that is tolerable for one project may be unacceptable when combined with similar exposures across the organization.

5. Comparing the Frameworks

The frameworks are complementary rather than competing. ISO 31000 can provide the generic architecture; PMBOK can shape project processes; COSO can connect the project to enterprise governance; and sector frameworks can supply specialized criteria and controls.

6. Sector-Specific Frameworks

Generic risk guidance is insufficient where technical hazards, public safety, privacy, financial integrity, or environmental impacts are material. Examples include:

• Information security and privacy: ISO/IEC 27001, ISO/IEC 27005, NIST Cybersecurity Framework, and privacy regulations.
• Safety and major hazards: ISO 45001, IEC 61508, process-safety regimes, and national construction or occupational safety law.
• Financial services: Basel requirements, operational-risk guidance, model-risk policies, and anti-money-laundering controls.
• Medical devices and health technology: ISO 14971 and applicable clinical, quality, and regulatory requirements.
• Construction and infrastructure: environmental impact assessment, building codes, contract standards, resilience requirements, and public procurement rules.
• Aerospace, defence, and critical infrastructure: configuration management, system safety, reliability, cybersecurity, and national security controls.

A sector framework may use specialized terminology. For example, safety engineering commonly distinguishes hazards, initiating events, barriers, consequences, and residual risk. A project risk register should preserve this technical meaning rather than flattening every concern into a generic red-amber-green score.

Compliance is not equivalent to risk control. A project may satisfy documentation requirements while retaining an unacceptable exposure. Conversely, a control may be valuable even when no regulation explicitly requires it.

7. Designing a Project Risk Management Methodology

A project risk methodology should be proportionate, repeatable, auditable, and useful for decisions. The risk management plan normally specifies the following.

7.1 Purpose and scope

State which project phases, contracts, work packages, interfaces, suppliers, sites, and benefits are covered. Clarify whether the plan includes opportunities, health and safety, security, fraud, environmental risk, and post-implementation benefits.

7.2 Method and tools

Specify the identification methods to be used, such as workshops, interviews, document analysis, prompt lists, assumption analysis, interface reviews, lessons learned, expert judgement, and scenario analysis. Define the risk register fields and the procedure for updating them.

7.3 Timing and cadence

Risk work should occur at authorization, stage gates, baseline approval, major design changes, procurement events, testing, deployment, and closure. Routine review frequency may be weekly for active delivery risks and monthly for strategic exposures, but cadence should be adjusted to volatility and consequence.

7.4 Assessment scales

A qualitative matrix may combine probability and impact. If probability is represented by P and impact by I, a simple priority score may be written as:

Here, S is a prioritization score, P is the selected probability rating, and I is the selected impact rating. This is an ordinal screening device, not a probability theorem. It assumes that the scales are defined consistently and that multiplication is being used only to rank or categorize risks. It should not be interpreted as a monetary loss estimate.

For quantitative expected monetary value, if mutually exclusive scenarios have probabilities p_i and monetary consequences x_i, then:

where ∑ p_i = 1, n is the number of scenarios, and x_i is signed so that threats may be negative and opportunities positive. EMV is an average over repeated or comparable situations; it does not predict the exact outcome of one project. Probabilities should be defensible, and double-counting between risks must be avoided.

For a risk with probability 0.30 and a potential cost of $200,000, using a threat cost as a positive exposure amount for planning purposes:

EMV = 0.30 × 200,000 = $60,000.

This figure supports reserve analysis; it does not mean that the project will necessarily lose $60,000.

7.5 Risk criteria

Criteria should define impact dimensions, rating descriptions, time horizons, and aggregation rules. Impact may include cost, schedule, scope, quality, safety, legal compliance, security, environment, reputation, benefits, and stakeholder trust. A “major” safety consequence may trigger escalation regardless of its numerical score.

8. Risk Appetite, Tolerance, Capacity, and Thresholds

These terms must not be used interchangeably.

• Risk capacity is the maximum exposure the organization can withstand before its viability, legal position, or essential objectives are threatened.
• Risk appetite is the amount and type of risk an organization is willing to pursue or retain in achieving objectives.
• Risk tolerance is the acceptable range of variation around an objective.
• Threshold is a defined point at which a specified action, approval, notification, or escalation is required.
• Trigger is an observable condition indicating that a risk is becoming more likely, more severe, or imminent.

Appetite should be expressed by category. An organization may have moderate appetite for schedule experimentation, low appetite for regulatory noncompliance, and zero tolerance for intentional falsification of safety data. “Zero tolerance” should be used carefully: it generally means no acceptance of the behavior or condition, not that the probability of every adverse event can literally be zero.

Thresholds should be operational. For example:

Thresholds should reflect materiality, not only percentages. A 5% variance on a small activity may be less significant than a $10,000 variance on a legally critical control.

9. Roles and Accountability

Risk governance fails when accountability is vague. A practical allocation is:

• Sponsor: owns strategic authorization, appetite, major decisions, and escalation acceptance.
• Project manager: integrates risk management with planning, controls, decisions, and reporting.
• Risk manager or risk coordinator: facilitates the process, maintains quality of records, challenges assessments, and produces consolidated analysis.
• Risk owner: accountable for monitoring a particular risk and ensuring that agreed responses are implemented.
• Action owner: performs a specific response action; this may differ from the risk owner.
• Work-package manager: identifies and manages risks within delegated scope.
• Subject-matter expert: provides technical analysis and evidence.
• Project controls lead: links risk to schedule, cost, estimates, forecasting, and change control.
• Assurance or internal audit: independently evaluates governance and control effectiveness.
• Steering committee: resolves cross-functional or above-threshold exposures.
• Supplier or contractor: manages risks allocated by contract while reporting interface and residual risks.

The RACI model can clarify who is Responsible, Accountable, Consulted, and Informed. However, RACI does not replace a risk owner’s substantive duty to make decisions and monitor exposure.

10. Risk Breakdown Structure

A risk breakdown structure is a hierarchical classification of risk sources. It supports systematic identification, ownership, reporting, and trend analysis. A generic RBS may include:

1. External risks

• regulation and politics
• market and economic conditions
• natural hazards
• social and community factors

1. Organizational risks

• governance and decision-making
• funding and priorities
• capability and resource availability
• culture and change readiness

1. Technical risks

• requirements and design
• integration and interfaces
• technology maturity
• performance and reliability

1. Project-management risks

• estimation and planning
• schedule and dependencies
• cost and reserves
• quality and configuration control

1. Commercial and supply-chain risks

• procurement
• supplier capacity
• contract terms
• logistics and lead times

1. Compliance and responsibility risks

• safety and health
• security and privacy
• environmental impacts
• ethics and reputation

The RBS is not the same as a work breakdown structure. A WBS organizes deliverables and work; an RBS organizes uncertainty sources. Linking the two helps identify which deliverables are exposed and which managers can act.

11. Risk Responses and Escalation

For threats, common responses are avoid, mitigate, transfer or share, and accept. For opportunities, responses include exploit, enhance, share, and accept. A response should identify the action, owner, due date, required resources, expected effect, and residual risk.

A response is not automatically effective merely because it has been assigned. The project team should test whether it changes probability, impact, detectability, exposure, or decision readiness. Responses can also create secondary risks and should be assessed accordingly.

Escalation rules should answer five questions:

1. What condition requires escalation?
2. To whom is it escalated?
3. Within what time period?
4. What information and decision are required?
5. Who has authority to accept the residual exposure?

Escalation should be based on both score and nature. A low-probability event involving fatality, corruption, data breach, or statutory violation may require immediate escalation even if its matrix score is not high.

12. Reporting and Integration with Controls

A useful risk report is decision-oriented. It may contain:

• top threats and opportunities;
• changes since the previous report;
• risks approaching thresholds;
• overdue response actions;
• emerging risks and assumptions under stress;
• residual exposure after treatment;
• aggregate cost and schedule uncertainty;
• decisions required from governance bodies; and
• trends by category, owner, project phase, or supplier.

Risk reporting should be integrated with the schedule, cost forecast, change log, quality report, procurement dashboard, and benefits plan. For example, a supplier risk should have a corresponding procurement action, schedule dependency, cost implication, and contract decision where relevant.

Quantitative schedule or cost risk analysis can use simulation, sensitivity analysis, scenario analysis, or decision trees. Such techniques are valuable when uncertainty is material and data quality supports them. They should not create false precision. Model assumptions, distributions, correlations, confidence levels, and limitations must be documented.

A useful distinction is between contingency reserve and management reserve. Contingency is generally intended for known-unknown uncertainty within the approved scope and delegated control structure. Management reserve is held for unforeseen work or uncertainty under governance rules. Definitions vary by organization and standard; the project plan must state the adopted meaning and approval authority.

13. Illustrative Case: Riverside Digital Health Deployment

Background

The fictional Riverside Health Authority is implementing a digital patient-record platform across three hospitals. The project has a fixed regulatory deployment date, multiple suppliers, sensitive personal data, and significant clinical consequences if the system is unavailable or inaccurate.

Problem

At initiation, the project team proposed a simple probability-impact matrix and a monthly risk meeting. The sponsor’s review identified weaknesses: cybersecurity and clinical-safety risks were being scored like ordinary schedule risks; supplier interfaces lacked clear ownership; and the organization had not defined which exposures required clinical or executive escalation.

Analysis

The team adopted ISO 31000 principles for integration, stakeholder inclusion, dynamic review, and continual improvement. PMBOK-oriented project processes were used for identification, analysis, response planning, implementation, and monitoring. COSO ERM concepts connected the project to enterprise objectives, risk appetite, and board reporting. Health-sector privacy, clinical safety, and information-security controls were added as mandatory criteria.

The RBS was revised to include clinical safety, privacy and security, technical integration, supplier, regulatory, organizational change, and operational readiness branches. A clinical safety officer became accountable for clinical-harm risks; the information-security lead owned cyber risks; and supplier managers owned contract and interface risks.

The governance criteria included these rules:

• any credible risk of patient harm required clinical safety review;
• any confirmed personal-data breach required immediate incident escalation;
• a forecast delay beyond the regulatory date required sponsor and regulator engagement;
• residual risks above the agreed appetite required steering-committee acceptance.

Approach and solution

The team replaced the monthly-only process with weekly operational reviews, fortnightly integrated risk workshops during testing, and stage-gate reviews before deployment. It used scenario analysis for downtime, interface failure, data migration defects, and supplier insolvency. Response actions included parallel testing, validated rollback procedures, independent security testing, clinical simulation, supplier recovery plans, and a controlled pilot.

The risk report linked each major risk to a schedule activity, cost impact, acceptance criterion, and decision owner. A risk trigger for migration error rates caused the team to pause deployment and execute additional reconciliation rather than relying on a favourable average score.

Outcome

The pilot was delayed by two weeks but revealed a data-mapping defect that would probably have affected a full deployment. The project incurred additional testing cost, but avoided patient-safety exposure, emergency remediation, and regulatory breach. The steering committee accepted a revised date based on evidence rather than optimism.

Learning points

First, proportionality does not mean simplified treatment of high-consequence risks. Second, sector controls must be integrated into the project methodology. Third, risk ownership should follow decision authority and technical competence. Fourth, a delayed project can represent better risk performance than an on-time project that creates unacceptable residual exposure.

14. Challenges, Ethics, and Contemporary Practice

14.1 Common limitations

Standards can encourage compliance rituals, excessive documentation, and false confidence. Risk matrices may produce different scores for similar risks because probability and impact descriptors are interpreted inconsistently. Aggregating ordinal scores can conceal important differences. Risk registers may also become stale, overpopulated, or disconnected from decisions.

Another limitation is optimism bias. Teams may understate probabilities to protect a business case or avoid escalation. Groupthink can suppress inconvenient information, while risk ownership can be assigned to people without authority or resources. A mature process therefore values challenge, psychological safety, evidence, and transparent uncertainty.

14.2 Ethical and regulatory considerations

Risk information should be accurate, timely, and appropriately protected. Deliberately downgrading a risk, hiding a near miss, manipulating a model, or presenting unsupported confidence can cause harm and may breach professional or legal duties. Personal, commercially sensitive, and security-related information requires controlled access and retention.

Decision-makers should consider affected communities, vulnerable users, workers, future generations, and unequal distribution of harm. A risk response that protects cost or schedule by transferring danger to contractors or the public may be legally or ethically unacceptable.

14.3 Technology and artificial intelligence

Risk platforms can automate reminders, link registers to schedules, detect overdue actions, and analyze recurring patterns. Artificial intelligence may assist with document review, risk prompts, scenario generation, and early-warning indicators. However, AI outputs are not evidence merely because they are statistically generated. Models may reproduce historical bias, omit rare events, expose confidential information, or generate plausible but unsupported risks.

Human accountability remains essential. AI-assisted risk analysis should document data sources, model purpose, validation, uncertainty, access controls, and approval responsibility. High-consequence decisions should retain qualified human review and an auditable rationale.

15. Best-Practice Design Principles

A strong integrated risk management plan should:

1. Begin with objectives and decision needs rather than a template.
2. Combine ISO principles, project practices, enterprise governance, and sector controls.
3. Define appetite, tolerance, thresholds, triggers, and authority in observable terms.
4. Assign risk ownership to people with authority and resources.
5. Separate individual risk analysis from overall project exposure.
6. Use the RBS to achieve coverage without creating needless categories.
7. Link risks to assumptions, requirements, work packages, schedule, cost, contracts, and benefits.
8. Treat opportunities as actively as threats where value can be created.
9. Escalate high-consequence risks regardless of a low numerical score.
10. Review the methodology itself and improve it through evidence and lessons learned.

Chapter Summary

ISO 31000 supplies adaptable principles, a management framework, and a risk process. PMBOK connects risk work with project planning, delivery, controls, and performance. COSO ERM places risk within governance, strategy, performance, and enterprise accountability. Sector frameworks add technical, legal, safety, privacy, environmental, and professional requirements.

An effective project risk management plan defines scope, methods, assessment criteria, roles, cadence, records, appetite, tolerances, thresholds, escalation, reporting, and reserve authority. A risk breakdown structure organizes sources of uncertainty, while integrated reporting connects risk to schedule, cost, quality, procurement, change, and benefits. Quantitative tools such as scoring and expected monetary value can support decisions when their assumptions and limitations are understood. Ultimately, standards are enablers of judgement, not substitutes for it; the quality of risk management is demonstrated by better decisions and outcomes.

Key Terms

Risk: Effect of uncertainty on objectives.

Risk management: Coordinated activities to direct and control an organization with regard to risk.

Risk governance: Allocation of authority, accountability, oversight, and escalation for risk decisions.

Risk appetite: Amount and type of risk an organization is willing to pursue or retain.

Risk tolerance: Acceptable variation around an objective.

Risk capacity: Maximum exposure an organization can withstand.

Threshold: Point requiring a defined action, approval, or escalation.

Trigger: Observable sign that a risk condition is changing or becoming imminent.

Risk owner: Person accountable for managing a specified risk.

Action owner: Person responsible for completing a response action.

Residual risk: Exposure remaining after responses are implemented.

Secondary risk: New risk created by a response.

Risk breakdown structure: Hierarchical classification of risk sources.

Risk register: Structured record of identified risks and their attributes.

Risk report: Consolidated analysis of risk exposure, trends, actions, and decisions.

Expected monetary value: Probability-weighted average consequence across defined scenarios.

Contingency reserve: Allocated provision for uncertainty within approved scope and authority.

Management reserve: Governed provision for unforeseen work or uncertainty, as defined by the organization.

Risk acceptance: Decision to retain an exposure within delegated authority.

Assurance: Independent evaluation of governance, risk, and control effectiveness.

Review Questions

Short Answer Questions

1. Distinguish a standard, a framework, and a project risk methodology.
2. What are the three principal elements of risk assessment in ISO 31000?
3. Define risk appetite, risk tolerance, and risk threshold.
4. How does a risk breakdown structure differ from a work breakdown structure?
5. Why should a high-consequence risk sometimes be escalated despite a low matrix score?

Long Answer Questions

1. Compare ISO 31000, PMBOK, and COSO ERM in terms of purpose, scope, and contribution to project governance.
2. Design the contents of an integrated risk management plan for a major infrastructure project.
3. Explain how sector-specific frameworks should be incorporated without fragmenting the project risk process.
4. Critically evaluate the strengths and weaknesses of probability-impact matrices.
5. Discuss how risk appetite and escalation authority should be established between a project sponsor, project manager, and steering committee.

Analytical / Application Questions

1. A project has a 30% probability of incurring a $200,000 threat cost. Calculate the expected monetary value and explain why the result should not be interpreted as a guaranteed loss.
2. Develop an RBS and escalation scheme for a cloud migration involving cybersecurity, supplier dependency, data quality, service continuity, and regulatory compliance.
3. A project is on schedule and below budget, but independent assurance identifies a credible risk of patient harm. Recommend the governance response and justify it using the principles of appetite, threshold, ownership, and escalation.

Multiple Choice Questions with Answers

Question 1

Which framework is primarily designed to connect risk with strategy, governance, performance, and enterprise objectives?

A. COSO ERM

B. A work breakdown structure

C. A project schedule baseline

D. A procurement statement of work

Correct Answer: A. COSO ERM

Question 2

In the simple prioritization equation S = P × I, what do P and I represent?

A. Project cost and duration

B. Probability rating and impact rating

C. Performance and investment

D. Procurement and integration

Correct Answer: B. Probability rating and impact rating

Question 3

A risk has probability 0.30 and a potential threat cost of $200,000. What is its expected monetary value?

A. $6,000

B. $60,000

C. $140,000

D. $200,000

Correct Answer: B. $60,000

Question 4

Which statement best distinguishes a risk owner from an action owner?

A. The risk owner is always the sponsor, while the action owner is always the contractor.

B. The risk owner is accountable for the risk; the action owner completes a specified response action.

C. The action owner accepts residual risk, while the risk owner only records it.

D. There is no meaningful distinction between the two roles.

Correct Answer: B. The risk owner is accountable for the risk; the action owner completes a specified response action.

Question 5

What is the primary purpose of a risk breakdown structure?

A. To sequence project activities by duration

B. To classify sources of uncertainty systematically

C. To authorize project expenditure

D. To replace the project organization chart

Correct Answer: B. To classify sources of uncertainty systematically

Question 6

Which condition most clearly warrants immediate escalation regardless of a numerical risk score?

A. A minor administrative delay

B. A low-cost design preference

C. A credible risk of fatality or statutory breach

D. An opportunity to improve meeting frequency

Correct Answer: C. A credible risk of fatality or statutory breach

Question 7

Which term describes the maximum exposure an organization can withstand before its viability or essential objectives are threatened?

A. Risk appetite

B. Risk tolerance

C. Risk capacity

D. Risk trigger

Correct Answer: C. Risk capacity

Question 8

Why should sector-specific frameworks be integrated into project risk management?

A. They eliminate the need for project governance.

B. They provide specialized technical, legal, safety, or regulatory criteria.

C. They guarantee that all risks are quantitative.

D. They replace the need for risk owners.

Correct Answer: B. They provide specialized technical, legal, safety, or regulatory criteria.

Question 9

Which statement about a probability-impact matrix is most accurate?

A. It is a screening and prioritization tool, not necessarily a monetary loss model.

B. It produces exact probabilities for all project outcomes.

C. It removes the need for professional judgement.

D. Its scores are directly comparable across every organization.

Correct Answer: A. It is a screening and prioritization tool, not necessarily a monetary loss model.

Question 10

What is a central ethical concern when using artificial intelligence for risk analysis?

A. AI always produces too few risks.

B. AI outputs may contain bias, unsupported conclusions, or confidentiality risks.

C. AI prevents the use of historical data.

D. AI makes governance unnecessary.

Correct Answer: B. AI outputs may contain bias, unsupported conclusions, or confidentiality risks.