The Risk Statement is a sentence, clearly representing the risk assessment process. The risk statement should be framed as conditional events and should show a causal relation between the cause, the event, and the impact.t is structured as follows:

The description can start with a Cause: ‘As a result of [cause]…, there is a risk that/potential for/possibility that [event] may happen …., which will result in [impact] …’

Or

The description can start with the Event: ‘There is a possibility that [event] …. may happen, which can be caused by [cause]…., and this will result in [impact] …’

To the extent possible, the risk statement should be specific, and refer to specific elements of the project (scope/ budget/ timeline/ quality) that can be impacted by an identified risk cause. The different components of the risk statement should follow these guidelines:

• Event – should be stated in a conditional format and should display uncertainties or express events that might happen (e.g. use of words such as might / could / may / would / potential for, etc.).
• Cause – should be within the purview of the project and should not duplicate or overlap with the risk event.
• Impact – should articulate specific project objectives, outputs, or results which would be directly impacted should the event of the risk occur.
• Treatment – should be related to the identified cause or event and should be within the framework of the project. It should refer to concrete actions that the “owner” will ensure are in place to manage the risk effectively. An observer should be able to objectively evaluate if the actions have been done or not. Changes in treatment plans or measures may be required if there is a major change in internal and external context.
• Risk and treatment owners – should mention the name and title of the person, avoiding mentioning multiple institutions or individuals.

The below are a couple of examples of complete and specific risk statements to help design effective treatment actions.

Quality considerations:

Risk statements and risk treatments don’t have to be long or complicated sentences, but it is useful to ensure that these include a few key quality considerations:

• Completeness – all information on the cause, event, impact, treatment, risk owner, etc. are available in the risk statement and risk treatment and are up to date.
• Uncertainty – the risk statement refers to a potential uncertainty that has not happened yet, not those that have already happened (i.e. issues).
• SMART – risk statement and risk treatment are Specific, Measurable, Attainable, Relevant, Time-bound.
• Specific – The risk event and impact clearly relate to one (not many) cause identified. The risk treatment is a specific action that can be attributed to the cause/threat identified. If a risk event has several causes, these are reflected as different risk entries, with related risk treatment action and Treatment Owner. The impact should refer to a particular element of the project objective (e.g. scope, cost, schedule, or quantity) that would be affected by the risk event and cause.
• Measurable – The risk statement is measurable with precise metrics to assess the impact on the project objectives. It should be possible for an objective observer to determine if the cause, event, and impact occurred or did not occur.
• Attributable – the risk statement should specify an element of the project (e.g. contracts, construction, etc.) where the risk will materialize. It would help to indicate which project element based on the planned project activities will be affected by the risk.
• Realistic – The risk statement should refer to causes that can be managed within the framework of the project or UNDP. The risk event should be within the management capacity of the project (i.e. issues such as wars, natural disasters, political revolutions, etc. are not within the project framework to manage).
• Time-bound – the risk statement and treatment action have a clear dimension of time as when they are estimated to occur (e.g. by the third quarter of the fiscal year, three months before the elections, etc.)
• Accountability – the risk owner and risk treatment owner are clearly mentioned with one name and/or job title (not an organisation) and are aware of their responsibility.

For UNDP-implemented Global Fund projects, risk reporting is included in the Pulse Checks, Progress Update and Disbursement Request (PUDR). See the reporting section of the Manual for details. Risk and performance reporting is also included in the UNDP corporate annual reporting system, ROAR, led by the UNDP Country Office (CO).

Identified risk mitigation measures and their status are also regularly reported to the Project Board. It is the responsibility of the UNDP’s Global Fund Programme/Project Manager to inform the Project Board on a timely manner regarding new risks, changes to existing risks, or escalation of risks. Should the risk register change in between CCM meetings, the CCM can be informed through a communication from the Project Manager.

Practice Pointer

The risk register is an ongoing tool, to be updated at least once a year, or more frequently for significant and high risks , through real-time monitoring. New risks can be added as they emerge, and treated risks can be closed.

All risks identified across the UNDP’s Enterprise Risk Management (ERM) categories and UNDP key risk management tools (see a mapping here) are reflected in the project risk register.

Significant project-level risks which are relevant for the CO programme and the broader CPD, should be discussed with the CO Project Assurance / Programme Team and included in the CO’s IWP Risk Register.