PMP Risk Register: Template, Examples & Best Practices

I have managed projects where the risk register was the most useful artefact on the project, and projects where it was a forgotten spreadsheet that nobody updated after week three. The difference between the two was rarely the quality of the initial risks. It was the cadence and discipline of how the register was used. On the best project I ever worked on, we reviewed the register every Friday for fifteen minutes and updated it in real time during steering committee. On the worst, we filled it in for the PMO submission and never opened it again.

For the PMP exam and for real practice, the risk register is the spine of the risk management knowledge area. It is created in Process 11.2 Identify Risks, refined through 11.3 Qualitative Risk Analysis and 11.4 Quantitative Risk Analysis, populated with responses in 11.5 Plan Risk Responses, actioned in 11.6 Implement Risk Responses, and tracked in 11.7 Monitor Risks. In this article I will walk through the columns every risk register should contain, two complete worked examples with ten risks each (one IT, one construction), the difference between qualitative and quantitative analysis, a Monte Carlo primer, and the maintenance cadence that separates living registers from dead ones.

The risk register is the central document that records all identified project risks, their analysis, and their planned responses. It is created in Process 11.2 Identify Risks and is updated by every subsequent risk process. In the PMBOK Guide Sixth Edition it is one of the most cross-referenced documents in the entire framework.

A risk is an uncertain event or condition that, if it occurs, has an effect on at least one project objective. PMI explicitly recognises that risks can be positive (opportunities) as well as negative (threats), so a good register tracks both. A threat is something you want to prevent. An opportunity is something you want to encourage.

 "A risk register is not a list of bad things that might happen. It is a structured conversation with your future self about uncertainty."

The register lives alongside the assumption log and the issue log. Assumptions become risks when they are not validated. Risks become issues when they occur. Issues become lessons when they are resolved. Each artefact has its place, and confusing them is one of the most common mistakes I see in audits.

A risk register can be as simple as a spreadsheet or as sophisticated as a module in a project management system. Regardless of format, certain columns are essential. The set I use in every register I create is below.

Some teams add columns for cost impact, schedule impact, secondary risks, and lessons. The above sixteen are the minimum for a register I would sign off on.

A Risk Breakdown Structure (RBS) is a hierarchical decomposition of risk categories. It helps the team identify risks systematically rather than relying on free recall. A common high-level RBS contains four branches:

• Technical (technology, complexity, performance, quality)
• External (regulatory, market, vendor, environmental)
• Organisational (resources, funding, prioritisation, dependencies)
• Project management (estimation, planning, control, communication)

Each branch is further decomposed. Under Technical you might have hardware, software, integration, and security. Under External you might have supplier, customer, regulatory, and weather.

Using an RBS during a risk identification workshop dramatically improves coverage. I run workshops where I project the RBS on screen and we work through each branch in turn. The team finds two to three times more risks than in unstructured brainstorming. Once identified, each risk is tagged with its RBS category in the register, which later helps with reporting and trend analysis.

PMI does not prescribe a fixed scale. The two most common approaches are a 3-point scale (Low, Medium, High) and a 5-point scale (Very Low to Very High). I prefer 5-point for substantial projects because it produces a finer-grained heat map.

A typical 5-point probability scale:
 

A 5-point impact scale should be calibrated to the project's tolerance. Example for a large IT project:

Calibrating the impact scale to the project size is essential. A 25k impact is catastrophic on a 50k project and trivial on a 50m project. Generic scales produce meaningless scores.

Risk score is typically calculated as probability multiplied by impact. With a 5-point scale, scores range from 1 to 25. The resulting heat map is usually divided into three or four bands.

The heat map is a powerful communication tool because it allows non-specialists to grasp the risk profile at a glance. I include a heat map in every steering committee deck, with the count of risks in each band and a comparison to the previous period.

"A heat map that does not change over time is a sign that nobody is doing risk management. The map should breathe."

PMI defines four strategies for threats and four for opportunities, plus an additional escalate strategy for both. Knowing these by heart is exam-essential.

For threats:

• Avoid: Eliminate the threat by removing its cause. Example: change the technology choice so a vendor risk no longer applies.
• Transfer: Shift the impact to a third party. Example: buy insurance, sign a fixed-price contract.
• Mitigate: Reduce probability or impact. Example: build a buffer, add a backup supplier, run additional testing.
• Accept: Acknowledge and take no action (active acceptance adds a contingency reserve; passive acceptance does not).

For opportunities:

• Exploit: Make it certain. Example: assign the best resources to a phase that could finish early.
• Share: Partner with a third party who can capture the upside. Example: a joint venture.
• Enhance: Increase probability or impact. Example: add training to accelerate productivity gains.
• Accept: Acknowledge and take no specific action.

Escalate is used when the risk is outside the project's authority and needs to be owned at a programme or organisational level. The risk is then moved off the project register and into a higher-level register.

Below is a worked risk register for a fictional cloud migration project. I use a 5-point scale.

This register has eight threats and two opportunities, which is roughly the ratio I aim for. Pure threat registers miss the upside; pure opportunity registers are wishful thinking.

A worked register for an office refurbishment project.

Note how the construction register has more external risks than the IT register. The risk profile of a project tells you something about its character.

Qualitative risk analysis (Process 11.3) is the assessment of probability and impact using descriptive scales, producing a prioritised list. It is fast, inexpensive, and applied to every identified risk. The output is the prioritised list that drives focus in Plan Risk Responses.

Quantitative risk analysis (Process 11.4) is the numerical analysis of the combined effect of high-priority risks on overall project objectives. It is optional and is used on projects where the cost or schedule sensitivity justifies the effort. The output is typically a range of possible outcomes (e.g., "80% confidence in delivery between 14 and 17 months").

The difference matters for the exam because PMI specifies that Qualitative happens before Quantitative, and Quantitative is not always required. A common exam trap is to suggest jumping straight to Quantitative without first prioritising via Qualitative.

For real projects, I run Qualitative on every project. I run Quantitative only on projects above roughly 5 million GBP or where there is a fixed external deadline that cannot slip. The return on Quantitative for small projects is low.

Monte Carlo simulation is the most common quantitative technique. It runs thousands of simulated project executions, each time sampling from probability distributions for cost or duration, to produce a distribution of possible outcomes.

The mechanics in plain language:

1. For each activity (or work package), define a probability distribution (often triangular: optimistic, most likely, pessimistic).
2. For each simulation run, the software samples a value from each distribution and computes the total project duration and cost.
3. Repeat 5,000 to 10,000 times.
4. The result is a histogram of total outcomes, from which percentiles can be read.

The output that matters most is the percentile reading. "P50 schedule is 14 months; P80 is 17 months" tells the sponsor that there is a 50% chance of finishing within 14 months and an 80% chance of finishing within 17 months. The gap between P50 and P80 indicates the level of uncertainty.

I have run Monte Carlo on three projects in my career. In each case the most valuable output was not the number itself but the conversation it triggered about which activities had the widest distributions and why. Monte Carlo is a thinking tool more than a forecasting tool.

Two concepts that exam candidates often confuse.

A residual risk is the risk remaining after a response has been applied. If you mitigate "vendor delay" to a probability of 1 and impact of 3, the residual is what is left after mitigation. The register should track this, because residual risks may still need monitoring.

A secondary risk is a new risk created by the response itself. If you mitigate "vendor delay" by adding a backup vendor, the secondary risk is "the backup vendor introduces integration complexity." Secondary risks are added to the register as new entries.

Both should be considered for every active response. The discipline of asking "what is left, and what have I just created?" prevents naive response selection.

The cadence I have settled on after many projects:

• Daily (during execution): Update status of any risk whose trigger has been observed
• Weekly: 15-minute team review of top 10 risks; new identifications captured
• Fortnightly: Full PM and SME review of all open risks; close completed responses
• Monthly: Steering committee review of heat map and trend; sponsor escalations
• Quarterly: Re-baseline; refresh the RBS; run a fresh identification workshop

The single biggest predictor of project failure I have observed is the absence of a weekly risk review. Projects that hold the review almost never blow up in ways they have not foreseen. Projects that skip it are repeatedly surprised.

"Risk management is not a one-time event. It is a habit. The register is the place the habit is recorded."

The failures I see most often:

1. Risks written as events, not statements. "Vendor delay" is too vague. "If vendor X delays delivery beyond June, then go-live slips by 2 to 3 months" is testable.
2. No owner. Risks without an owner are not managed. PMI is explicit on this.
3. Stale scores. Probability and impact change as the project progresses. If your scores have not been reviewed in two months, the register is dead.
4. Threats only. A register without opportunities reflects a defensive mindset and misses upside.
5. No trigger. A trigger is the observable event that signals the risk is occurring. Without it, response is delayed.
6. Missing residual and secondary risks. Without these, the response analysis is incomplete.
7. Register isolated from other artefacts. Risks should feed schedule, cost, and quality decisions, not sit in isolation.
8. Too many risks. Above 80 to 100 active risks, the register becomes unmanageable. Aggressive prioritisation and closure are essential.
9. Too few risks. Below 15 to 20, you have probably missed categories. Use the RBS to widen identification.
10. Risks framed without context. A good risk statement specifies the event, the cause, and the effect.

The risk register does not stand alone. It feeds and is fed by:

• The schedule. High-impact schedule risks should inform schedule contingency.
• The cost baseline. Cost impact of risks should inform contingency reserves.
• The quality plan. Quality risks should inform inspection and test plans.
• The procurement plan. Vendor risks should inform contract clauses and bonds.
• The communications plan. Risk-driven stakeholder concerns should inform messaging.
• The change log. Risks that occur often trigger change requests.
• The issue log. When a risk occurs, it becomes an issue and is moved to the issue log (or marked "occurred" in the register).
• The lessons learned register. Closed risks contribute lessons.

In my experience, the test of a healthy risk register is whether it is referenced in other artefacts. If the schedule contingency is "10% because that is what we always do," the register is not influencing planning. If the contingency is "23 days, derived from Monte Carlo on the top 12 risks," the register is doing its job.