Risk Monitoring And Reporting practice questions

Risks that have already been resolved

Why it fails: Resolved risks are closed, not on a watchlist.

Critical path risks

Why it fails: Critical risks require active management, not just a watchlist.

Review the risk register to ensure all risks have been assigned an owner and that response plans are in place.

Why it fails: Ensuring risk owners and response plans are in place is part of risk management, but it does not directly address the need to provide an updated risk exposure figure. The scenario already indicates that probability and impact values have been updated; the missing piece is the recalculated contingency reserve. Checking owners and response plans, while good practice, is not the immediate action required to answer the program manager's request for current risk exposure.

Report the updated probability and impact values to the program manager and ask for guidance on how to proceed.

Why it fails: While communication with the program manager is important, the risk manager is expected to take ownership of the risk management process. Asking for guidance without first attempting to recalculate the reserve would be a passive approach. The program manager asked for the current risk exposure; the risk manager should be able to provide it by updating the reserve. This option does not move the process forward and may delay decision-making.

Perform a Monte Carlo simulation using the updated probability and impact data to determine the range of possible outcomes.

Why it fails: Monte Carlo simulation is a powerful technique for quantitative risk analysis, but it is not the first step here. The scenario states that probability and impact values are updated but the contingency reserve has not been recalculated. Before running simulations, you should ensure the reserve reflects the current risk profile, as the simulation itself does not automatically adjust the reserve. The immediate need is to update the reserve based on the revised risk data, not to run a simulation.

Discard the report to avoid negative visibility

Why it fails: Discarding findings destroys the assurance value the audit exists to provide and breaches governance expectations around record retention. It tempts when findings are unflattering to the project team, but the audit's purpose is to surface weaknesses so that corrective action can be planned and tracked.

Request a project budget increase immediately

Why it fails: A budget increase is a change request, not the immediate use of audit findings; the audit's purpose is to improve risk process effectiveness, so responses are logged and assigned. It tempts because audits can reveal underfunded risk responses, but funding follows the change control process after analysis.

Send the report to external regulatory bodies

Why it fails: External regulators receive reports only where regulation mandates disclosure; a risk audit is an internal assurance activity, so findings feed the project's risk management plan. It tempts because audits produce formal documentation, yet distribution is governed by the communications plan, not automatic external submission.

Delete the risks identified during the audit

Why it fails: Deleting identified risks removes them from the risk register without any response or closure rationale, corrupting the risk baseline. It tempts as a tidy-up after review, but risks are closed only through documented response or re-evaluation, not by erasing audit evidence.

Update the risk yourself and hide the lack of participation

Why it fails: Falsifying risk register entries conceals the governance breach and leaves the exposure unmanaged, so the response owner's non-reporting persists undetected. Escalating through the risk management plan is required. Updating records is legitimate only when a designated owner genuinely provides status, not to mask silence.

Assign a new owner without informing the original owner

Why it fails: Replacing an unresponsive owner unilaterally bypasses the governance route, leaving accountability and reporting lines undefined. It is tempting because it appears to restore momentum quickly, yet the correct action is escalating through the risk register and governance board so the change is authorised and recorded.

Remove the risk from the register

Why it fails: Deleting the risk discards the documented exposure and its response plan, so the threat remains unmanaged while governance loses visibility. Risks are closed only when they no longer apply or responses are complete. Removing an entry is valid solely after formal closure criteria in the risk management plan are met.

Schedule an immediate Steering Committee meeting

Why it fails: Escalation to the Steering Committee is a governance response, not the reporting workflow's next step; the reassessment must first update the risk register and notify the risk owner. Convening the committee suits major funding or scope decisions requiring executive authority, not a routine probability change.

Close the risk and add it to the Issues Log

Why it fails: A probability increase means the risk is materialising, so closing it and logging an issue discards the response planning still needed. Issue logs record realised problems; this risk remains uncertain, so it stays open with a revised response. Issue logging fits risks that have actually occurred.

Immediately activate the contingency reserve

Why it fails: Contingency reserves are drawn only after a risk occurs and a response is executed, so activating them pre-emptively misallocates funds before any trigger. It is tempting because reserves exist to fund responses, and activation would be correct once the risk materialises and the planned contingency plan is invoked.

Owner assignment frequency

Why it fails: Owner assignment frequency records how often risks change hands, which does not measure exposure reduction over time. Risk burn-down tracks cumulative risk exposure remaining against a baseline, so it is tempting as a governance metric but supplies no time-series of outstanding risk.

Total number of risks identified

Why it fails: Total risks identified is a cumulative count that only rises, so it cannot trend downward. It is tempting as a headline risk metric, yet burn-down requires the outstanding exposure or open-risk count over time, which decreases as risks are addressed or closed.

Number of risk responses completed

Why it fails: Counting completed responses measures activity volume, not the residual risk exposure the burn-down plots. Completed responses are tempting because they appear to reduce risk, but a response can close while exposure remains, so the trend requires remaining exposure values instead.

To automate the closure of the risk entry

Why it fails: The threshold records the value at which a trigger activates; it does not close the risk entry. Automatic closure is tempting because software can act on thresholds, but closure follows risk-response and review, whereas the threshold only signals that the trigger condition has been met.

To define the escalation path for the project manager

Why it fails: A threshold field holds the measurable value that signals a trigger has occurred, not the reporting chain. It is tempting because escalation paths are configured alongside risk settings, but escalation is a separate workflow attribute; the threshold defines when the trigger fires.

To notify the finance department of budget changes

Why it fails: The threshold defines the measurable condition indicating a trigger has occurred, not a distribution list. Notifying finance is tempting because budget variance often acts as a trigger, but the field stores the value itself; notification routing is configured separately.

Archive the risk to maintain the dashboard clarity

Why it fails: Archiving removes the risk from active reporting, so the manifested risk stays invisible and the dashboard misrepresents current exposure. Archiving suits risks formally closed and no longer relevant, not one that has just occurred and requires active tracking.

Create a new risk entry in the Risk Register

Why it fails: Creating a new entry duplicates the original closed risk rather than reopening it, so the register no longer reflects that this risk was previously assessed and closed. New entries suit genuinely new risks, not the re-emergence of a documented one.

Update the Lessons Learned repository only

Why it fails: Lessons learned capture knowledge for future projects but do not update the current project's risk status, leaving the register and reports inaccurate. It is tempting because documenting the event feels productive, yet it is the correct action only at project closure or retrospective.

Number of audit findings related to risk

Why it fails: Audit findings measure control compliance and detection, not whether the specific mitigation reduced the risk's probability or impact. It is tempting because findings are objective and quantifiable, and the metric would be correct when evaluating control assurance or audit readiness rather than mitigation effectiveness.

Total number of risks managed

Why it fails: Counting managed risks measures activity, not whether mitigation reduced probability or impact; a rising count can even signal better identification. It is tempting because a risk register is tangible, and the metric would suit reporting workload or register completeness rather than mitigation effectiveness.

The frequency of steering committee meetings

Why it fails: Meeting frequency reflects governance cadence, not risk exposure; teams can meet weekly while residual risk stays unchanged. It is tempting because regular steering committee meetings suggest active oversight, and the metric would be correct when assessing governance engagement rather than whether a mitigation actually lowered risk.

Individual Risk Response Plan

Why it fails: An Individual Risk Response Plan documents mitigation actions, owners and contingencies for one risk; it carries no portfolio-level aggregation against appetite. It is the right artefact when executing a specific agreed response, not for summarising overall exposure for senior management.

Project Schedule Variance Report

Why it fails: A schedule variance report measures earned value against planned dates, so it cannot express risk exposure relative to appetite thresholds. It is tempting because variance reporting does surface performance drift, and it would be the right choice when stakeholders need to see whether delivery milestones are slipping against the baseline.

Risk Register Detail Report

Why it fails: The Risk Register Detail Report lists every risk with granular attributes, burying the appetite comparison in operational detail rather than presenting a high-level status view. It suits working-level risk reviews, where practitioners need full individual risk data.

Dashboards provide full historical logs of all changes

Why it fails: Dashboards present current risk status visually; they do not maintain full historical change logs, which the Risk Register or audit trail holds. It is tempting because dashboards show trends over time, which suits status reporting to stakeholders rather than recording every register amendment.

Dashboards replace the need for the Risk Register

Why it fails: A dashboard is a visualisation layer drawing data from the Risk Register; it does not replace that register, which remains the authoritative record of risks, owners and responses. It is tempting because dashboards summarise register content, which suits executive reporting while the register persists as the source.

Dashboards store raw data for quantitative analysis

Why it fails: Dashboards display aggregated, summarised metrics; raw quantitative data and detailed analysis reside in the Risk Register and supporting models. It is tempting because dashboards visualise quantitative outputs, which suits communicating Monte Carlo or sensitivity results rather than storing underlying data.

The project manager forgot to save the update

Why it fails: A forgotten save would lose the mitigation update entirely, not leave impact unchanged; the register would still show the original rating. It is tempting because unsaved edits are a common administrative slip, and this would be the answer if the mitigation details themselves were missing from the register.

The risk is a secondary risk

Why it fails: A secondary risk arises from the mitigation itself, so it explains a new risk appearing, not an unchanged impact on the original. It is tempting because mitigation plans genuinely generate secondary risks, making this a plausible-sounding cause when the real issue is that the response addressed probability rather than impact.

The risk register is corrupted

Why it fails: Corruption would produce missing or garbled entries, not a coherent risk whose impact simply remains at its pre-mitigation value. It is tempting because register integrity failures do occur, and this would be correct if the risk data were unreadable or inconsistent rather than logically unchanged.

Risk Owner

Why it fails: Risk Owner identifies the person accountable for managing the risk, but ownership alone does not record when reassessment should occur. It is tempting because owners are responsible for monitoring and updating their risks, which suits assigning accountability and escalation paths rather than tracking reassessment frequency.

Risk ID

Why it fails: Risk ID is merely a unique identifier for cross-referencing entries; it carries no scheduling information, so it cannot indicate when reassessment is due. It is tempting because IDs are essential for traceability and linking risks across registers, which suits audit and reporting scenarios rather than tracking reassessment frequency.

Contingency Budget

Why it fails: Contingency Budget records the funds reserved to cover risk responses; it says nothing about when a risk should be reassessed. It is tempting because budget figures inform response planning and reserve analysis, which suits cost-management and funding-approval scenarios rather than scheduling reassessment intervals.

The risk is now fully accepted

Why it fails: Acceptance is a deliberate response choice, not something implied by residual exceeding inherent risk. It is tempting because accepted risks remain on the register, but acceptance does not explain the numerical inversion. The comparison indicates mitigation added exposure or the inherent estimate was revised, not that the risk was accepted.

The mitigation was highly successful

Why it fails: Residual risk exceeding inherent risk indicates the mitigation introduced new exposure or the assessment changed, not success. It is tempting because mitigation normally lowers residual risk, so a decrease signals effectiveness; an increase signals the opposite. The figures suggest the treatment was ineffective or the risk was reassessed upward.

The project is complete

Why it fails: Project completion has no bearing on the relationship between residual and inherent risk values. It is tempting because closure removes risks from active tracking, but the question concerns the arithmetic inversion itself. Residual exceeding inherent points to ineffective treatment or a changed assessment, not project status.

The Communications Management Plan

Why it fails: The Communications Management Plan covers who receives which information and in what format, not the formal risk reporting requirements. It is tempting because risk reporting is a communication activity, and this plan would be correct when the question asks how risk status is distributed to stakeholders.

The Project Charter

Why it fails: The Project Charter authorises the project and names the project manager; it does not define risk reporting formats, frequencies or recipients. Those sit in the Communications Management Plan. The Charter tempts because it is a foundational, formally approved document, but its content covers objectives, scope and authority rather than reporting requirements.

The Scope Statement

Why it fails: The Scope Statement defines deliverables, boundaries and acceptance criteria; it says nothing about risk reporting formats, cadence or audience. Those requirements live in the Communications Management Plan. The Scope Statement tempts because it is a core project document, but its content addresses what is delivered, not how risk information is communicated.

Immediately initiate the contingency reserve

Why it fails: A secondary risk arises from a risk response, so it must be identified, analysed and planned for before any reserve is drawn. Releasing the contingency reserve is tempting because it is the standard response to a materialised risk, but that applies to the primary risk, not its by-product.

Ignore it if it is small

Why it fails: All risks must be evaluated for their impact on the project objectives.

Call the sponsor to discuss the project failure

Why it fails: Escalating to the sponsor presumes failure, whereas a secondary risk is simply a new risk requiring assessment and a response plan. It is tempting when the secondary risk threatens objectives severely, and would be correct if that risk exceeded the project manager's authority threshold.

Software language compatibility

Why it fails: Risk data quality concerns the accuracy, completeness and consistency of the information itself, not the file formats or application versions used to exchange it. Software language compatibility is tempting because global teams often run heterogeneous tooling, and it would be the correct concern when integrating incompatible risk registers across regions.

Email communication delays

Why it fails: Email delays slow the transmission of risk information but do not corrupt its accuracy, completeness or consistency, which is what data quality measures. It is tempting because asynchronous messaging across regions does cause lag, and it would be the correct choice if the question concerned communication latency rather than data quality.

Time zone differences for reporting meetings

Why it fails: Time zone differences affect when meetings occur and how quickly responses arrive, not the accuracy or completeness of the risk data reported. It is tempting because scheduling across regions is a genuine logistical burden, and it would be the correct answer if the question asked about coordination rather than data quality.

Suggest the sponsor look at the Issues Log instead

Why it fails: The Issues Log tracks problems that have already occurred, not the cost impact of a closed risk, so it cannot supply the missing figure. It would be the right reference when the sponsor asks about an issue currently affecting the project.

Blame the Risk Owner for the missing data

Why it fails: Assigning blame addresses no data gap and leaves the report inaccurate. Risk owners do supply impact estimates, but the risk manager is accountable for validating and updating closed-risk cost data before reporting, so escalation should target correcting the record.

Argue that cost updates are not required for closed risks

Why it fails: Closed risks still require their actual cost impact recorded, since the cost baseline and lessons-learned register must reflect realised expenditure; refusing the update leaves the report inaccurate. Arguing exemption is tempting because closure removes the risk from active tracking, but that applies to probability and response planning, not to capturing incurred cost.

The entire project team

Why it fails: Inviting the entire project team dilutes the session and pulls in members without risk ownership; the risk owner is the essential attendee because they are accountable for executing responses. A full-team meeting suits broad communication or kick-off sessions, not focused risk review.

All project stakeholders

Why it fails: Stakeholders are usually kept informed via reports, not necessarily active participants in every review.

The external auditor

Why it fails: An external auditor provides independent assurance and does not own or manage project risks, so they cannot drive response decisions. Auditors attend when compliance verification or an audit review is the objective, whereas risk reviews need the risk owners accountable for mitigation.

To make the project look better to stakeholders

Why it fails: Monte Carlo updates refine probability distributions and confidence ranges as actual data replaces estimates, supporting risk-informed decisions. Presenting favourably to stakeholders is a reporting bias, not a modelling purpose. Simulation updates are correct when new quantitative data must feed revised contingency and schedule forecasts.

To keep the simulation software updated

Why it fails: Updating the simulation refreshes probability distributions and risk data as the project progresses, not the software version. Patching the tool is routine IT maintenance, unrelated to risk monitoring. Software updates would be the right concern only when the vendor releases a security fix or compatibility patch.

To replace the need for qualitative risk assessments

Why it fails: Monte Carlo quantifies the combined effect of identified risks on schedule or cost; it consumes qualitative assessment outputs rather than replacing them. Qualitative analysis still ranks and prioritises risks by probability and impact. Replacing qualitative assessment would be the goal only if no numerical modelling were required at all.