Risk Register and Risk Report
The risk register is the document in which the project team records each individual risk: its identifier, its wording as cause, event and consequence, its owner, the planned response and its status. The risk report is a second document that the team builds from the register and from the project's other sources of uncertainty. It gives the sponsor the overall project risk, its sources and a summary of the individual risks. The PMBOK Guide lists both among the outputs of the Identify Risks process. The analysis, response and monitoring processes complete them until closure.
Goal
The register tells the team what can happen and who deals with it. The report tells the sponsor how exposed the whole project is and what drives that exposure most.
The PMBOK Guide defines risk as an uncertain event or condition that would have a positive or negative effect on one or more objectives if it occurred. The register therefore carries threats and opportunities in the same columns. Opportunity analysis treats the favourable side in detail and enters its results in the register.
With the register, the team chooses a response for each risk and names the person who carries it. With the report, the sponsor decides whether to continue the project, redirect it or stop it.
Risk analysis and management describes the process that fills the register: identify, analyse, evaluate, treat. It also sets the probability and impact scales that the register uses.
Usage
When to use it
- Sponsor or steering committee: at each meeting the report gives them the overall exposure and the decisions expected.
- End of a phase or release: HERMES assesses the risks before releasing the next phase or release.
- Several risk owners: each row names who watches the trigger and who acts.
- Team spread over several sites: a shared register keeps the list current without an on-site workshop.
- Independent review expected: a register with a change history shows when a risk was seen and what was decided.
- Project closure: the closed register feeds the lessons learned for the next project.
When not to use it
- Event that has already happened: it is an issue and goes into the issue log that item tracking keeps.
- Short assignment with low stakes: the register costs more than the protection it gives. The list of open points in the minutes is enough.
Description
The register and the report
The PMBOK Guide defines the risk register as the document in which the team records the outputs of the risk management processes. It lists the project's individual risks. These processes feed it from the start of the project to the end: identify risks, analyse them, plan responses, implement responses and monitor risks. The size and complexity of the project determine its volume. The risk management plan sets its format.
The risk report presents the sources of overall project risk and a summary of the individual risks. The team builds it step by step: each process adds its results. Overall project risk is the effect of uncertainty on the project as a whole. The individual risks are part of it. A fragile effort estimate or a technology new to the team can contribute to it without taking up a row in the register.
Adding up the rows of the register therefore accounts only for the individual risks. The PMBOK Guide defines risk exposure as an aggregate measure of the potential impact of all risks at a given point in time. The report names what drives the project's exposure and compares it with the sponsor's threshold. The PMBOK Guide defines risk appetite as the degree of uncertainty an organisation accepts in anticipation of a reward. The risk threshold puts a number on it: a tolerated variance of ±5% around the budget reflects a lower appetite than a variance of ±10%.
What goes into the register
From identification onwards, the PMBOK Guide asks the team to separate risks from non-risks: concerns and issues. An issue has already occurred or is still occurring. It goes into the issue log. A risk is an issue that may arise later. When a risk occurs, its row moves to the status "occurred" and an issue opens in the log. A concern expresses a worry without saying what might happen. It enters the register once it is rewritten as an event.
A planning assumption goes into the assumption log. Assumption and constraint analysis derives a risk from it when the assumption proves fragile: "the supplier delivers in March" becomes "the supplier may deliver after March".
Writing a risk: cause, event, consequence
The PMBOK Guide suggests describing a risk by its cause, its event and its consequence. This wording separates the risk from its causes and its effects. It fits in one sentence: because of <cause>, <uncertain event> may occur, which would lead to <consequence for an objective>.
The cause is a fact that is certain today: a decision taken, a constraint, a situation. The event is uncertain. The consequence says which objective it affects: schedule, cost, scope, quality. Each part serves a decision. A preventive response acts on the cause. The trigger signals that the event is drawing near. The consequence names the objective at risk and therefore the person to inform.
| Row as written | Defect | Row rewritten |
|---|---|---|
| "Lack of resources" | A cause with no event or consequence | Because two analysts are assigned to a second project, that project may get priority in spring, which would delay the specification of the checks by six weeks. |
| "Go-live delay" | A consequence with no cause or event | Because the municipalities use three different software packages, the interface with one of them may fail integration testing, which would delay go-live in twelve municipalities. |
| "The supplier delivered lot 1 late" | An issue: the event has happened | To the issue log. The register takes the risk it exposes: lot 2 may suffer the same delay. |
| "The municipalities are not ready" | A concern with no event | Because the municipal offices carry a heavy workload at year end, user training may slip past go-live, which would double support calls in the first month. |
A single cause often produces several events. Each event gets its own row, because each has its own trigger and its own response. The common cause then shows in the cause column. The report takes it up as a source of overall project risk.
The fields of a row
The PMBOK Guide sets the content of the register at identification. Each risk gets a unique identifier and a description precise enough to be read only one way. The team notes the potential responses and the potential risk owner when it is known. Analysis confirms the owner and response planning confirms the responses.
The PMBOK Guide lists further fields. The risk management plan keeps those the project needs.
| Field | Content | Use |
|---|---|---|
| Short title | A few words that name the risk | Cite it in meetings and in the report |
| Category | Technology, organisation, regulation, suppliers… | Count the risks by category in the report |
| Status | For example open, watched, occurred, closed | Filter the rows that call for action |
| Causes | One or more | Spot causes shared by several rows |
| Effects on objectives | One or more: schedule, cost, scope, quality | Identify the people to inform |
| Triggers | The events or conditions that signal the risk is about to occur | Start the response in time |
| WBS reference | The activities affected in the project's work breakdown structure | Link the risk to the schedule |
| Timing information | Date identified, period in which the risk may occur, date it stops being relevant, action deadline | Keep to the deadlines and close expired rows |
The results of the later processes are added on the right: estimated probability and impact, priority, chosen response and progress of the actions. The rating scales and the probability and impact matrix belong to analysis. The choice of response belongs to risk response strategies.
Nobody watches a row without a named owner: "the project team" watches for no trigger. A register that only grows buries the open risks among expired rows. The team therefore closes any row whose relevance date has passed.
The risk report
After identification, the report names the sources of overall project risk and shows which of them drive the project's exposure most. It also summarises the individual risks: the number of threats and opportunities, their spread by category, indicators and their trend.
The later processes add to the report. For example, quantitative analysis adds the probability of meeting the go-live date. Monte Carlo simulation calculates it. Sensitivity analysis ranks the risks by their effect on the go-live date or on the final cost. Response planning adds the responses to overall project risk, then monitoring adds their effect.
The PMBOK Guide applies the response families for individual risks to the project as a whole. To avoid overall risk, the team removes the riskiest elements from scope. To mitigate it, the team replans or changes how resources are allocated. To accept it, the sponsor sets a contingency reserve for the whole project. Reserve analysis sizes it. To exploit favourable overall risk, the team adds high-value elements to scope. If no response brings the project back within the threshold, the organisation may stop it. The report ends with the decisions it asks of the sponsor. Each one points to the register row or the source behind it.
Neither the PMBOK Guide nor HM Treasury's Orange Book sets the layout of the report. The PMBOK Guide refers to the reporting requirements in the risk management plan. The Orange Book asks the board to specify the nature, source, format and frequency of the information it requires. For each principal risk, it recommends summarising its position against appetite, the outcome of the actions, the warning indicators and the trend.
The common pitfall is the report that copies the top ten rows of the register. It does not say whether the whole project exceeds the threshold or which source pushes it there. The second pitfall is the report that counts only threats. It overstates the exposure.
Keeping both documents current
The PMBOK Guide notes that initial identification remains incomplete, since some risks only appear during the project. At regular intervals until closure, the team updates the register: it adds new risks, reassesses existing ones and adjusts the responses. For agile development, the PMBOK Guide gives the example of a team that reviews risks at the start of each sprint. The team goes over them again with the stakeholders at the end of each iteration.
The report accompanies each steering committee meeting and each phase end. Its trend compares today's review with the previous one: new risks, closed risks, risks that occurred. At closure, the full register goes to the lessons learned. The responses that worked and the risks nobody had seen serve the next project.
In HERMES
In HERMES 2022, the project manager carries out the task Manage risks. The project manager identifies the risks, groups them, analyses them and assesses them. For each one the project manager defines a strategy (avoid, reduce, transfer, accept) and the measures to take. HERMES defines no "risk register" outcome. In the traditional approach, the detailed planning of the next phase does include updating the risk list and the measures (7.4.5.3). The project manager records the risks in the project status report, then the actual risks in the phase or release report. In the traditional approach, the risk assessment at each phase end prepares the decision to release the next phase. In the agile approach, it takes place at the end of each release.
HERMES also has a QA and risk report. The quality and risk manager prepares it at the sponsor's request. It gives an independent view of the project. It covers mandate and scope, method, overall assessment with project status, quality assessment, risk assessment and recommendations. The risk report of the PMBOK Guide is a project document that the team produces itself.
| PMBOK Guide | HERMES 2022 | Written by | Read by |
|---|---|---|---|
| Risk register | No dedicated outcome. Risk list updated when each phase is planned. The risks appear in the project status report | Project manager | Project team, sponsor |
| Risk report | "Risks" item of the project status report; actual risks in the phase or release report | Project manager | Sponsor, steering committee |
| No equivalent | QA and risk report | Quality and risk manager at the sponsor's request | Sponsor |
AI considerations
A language model rewrites a concern as cause, event and consequence. It spots rows that describe an issue or a cause alone. It suggests a category, detects duplicates and flags rows without a named owner or a trigger. From a register export, it counts threats and opportunities by category and drafts the trend from one review to the next. The PMBOK Guide lists generative AI and data analysis among the techniques for identifying and analysing risks.
The model knows nothing of the project's real causes. It produces plausible generic risks that inflate the register. A suggested row enters the register when an owner acknowledges it and accepts the work. The sponsor judges the overall exposure and the threshold. The register names people, suppliers and contractual weaknesses. It goes to an external AI service only if the organisation allows it. In a Swiss public administration, the applicable data protection law and the hosting location decide.
Examples
A French-speaking canton is moving building permit applications online. The project follows HERMES and is finishing its Concept phase. The register holds 14 open risks. The extract shows five, including two opportunities. The extract leaves out the analysis columns.
| Risk | Cause | Event | Consequence | Owner | Response | Trigger | Status |
|---|---|---|---|---|---|---|---|
| R-03 Threat · technology | The municipalities use three case management software packages | The interface with software C fails integration testing | Twelve municipalities stay on paper files at go-live | Solution architect | Interface mock-up tested with the vendor before integration testing | The vendor has not delivered its interface specification by 30 September | Open |
| R-05 Threat · regulation | The cantonal spatial planning act is under revision | The Grand Council changes the list of documents required for an application before go-live | Forms and checks redone at a cost of about CHF 90'000 | Lawyer in the planning department | Configurable document list | The parliamentary committee adopts the bill | Open |
| R-07 Threat · organisation | Two of the three analysts also work on the land register overhaul | The land register overhaul gets priority in spring | The specification of the checks falls six weeks behind | Project manager | Escalation to the steering committee to settle the priority | The land register brings its go-live date forward | Open |
| R-08 Opportunity · technology | The neighbouring canton runs a plan-checking module on the same platform | The neighbouring canton agrees to share its module | Eight weeks of development saved | Project manager | Propose a sharing agreement | The neighbouring canton's answer to the request of 15 October | Open |
| R-09 Opportunity · organisation | Nine municipalities already receive plans as PDF files | These municipalities agree to open the service three months before the others | Support cost calculated on the workload measured before general go-live | Rollout manager | Propose a pilot rollout | Agreement of the nine municipal offices | Open |
The report presented to the steering committee groups these rows by source of overall project risk. It also carries a source that has no row in the register. The team estimates the effort to migrate the pending cases to within ±30%. This uncertainty adds to the exposure in the same way as the individual risks.
Visualisations
The register is a table: one row per risk, one column per field. The report fits on one page. It shows the exposure against the threshold, the spread by category and the trend from one review to the next. The probability and impact matrix places the analysed risks by their two factors. One diagram links the rows of the register to the sections of the report. A second follows both documents through the five risk management processes.
Cost
| Phase | Level | Justification |
|---|---|---|
| Preparation | Medium | Set the register fields, the categories, the sponsor's threshold and the content of the report in the risk management plan. |
| Execution | Medium | An identification workshop at the start, then a short review of the register at each progress meeting or each sprint. |
| Documentation | High | Keep each row current until it closes and produce the report before each steering committee meeting. |
Tooling
A spreadsheet is enough for a register of a few dozen rows: drop-down lists for category and status, a filter on deadlines. A tracking tool such as Jira or Azure DevOps handles risks as tickets of a dedicated type. It records every status change and notifies the owner. Risk management software and governance, risk and compliance (GRC) modules consolidate several projects and keep an audit trail. The team writes the report in a word processor or on a slide. A dashboard tool such as Power BI draws it from a register export. For a Swiss public administration, the hosting location of the data guides the choice once the register names suppliers or people.
Sources
- Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK Guide), 8th ed., PMI: risk, issue, overall project risk, appetite, threshold and exposure (§2.7.1); iterative identification and the separation of risks from non-risks (§2.7.2.2); the agile example and generative AI (§2.7.3); the content of the risk register and the risk report (Section 4, entries Risk register and Risk report); the strategies for overall project risk (Section 5).
- Federal Chancellery, HERMES 2022, Project Management Reference Manual: the task Manage risks (5.4.3.41); the detailed planning of the next phase (7.4.5.3); the outcomes Phase report (4.4.1.29), Project status report (4.4.1.36) and QA and risk report (4.4.1.42).
- HM Treasury, The Orange Book: Management of Risk, May 2023, section D "Risk reporting": the information the board specifies and its summary presentation for each principal risk.