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.

PMP Risk Register: Template, Examples & Best Practices

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.

What a Risk Register Is

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.

Required Columns Every Register Needs

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.

Risk Categorisation and Breakdown Structures

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.

Probability and Impact Scales

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 Scoring and Heat Maps

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."

Response Strategies for Threats and Opportunities

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.

Worked Example: IT Project Risk Register (10 Entries)

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.

Worked Example: Construction Project Risk Register (10 Entries)

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 vs Quantitative Risk Analysis

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 Primer

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.

Residual and Secondary Risks

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.

Risk Register Maintenance Cadence

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."

Common Risk Register Failures

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.

Integrating the Risk Register With Other Artefacts

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.

Author

Shashank Shastri

Coach & Mentor/317 articles

Shashank Shastri is a PMP trainer with over 14 years of experience and co-founder of Oven Story. He is an inspiring product leader who is a master in product strategies and digital innovation. Shashank has guided many aspirants preparing for the PMP examination thereby assisting them to achieve their PMP certification. For leisure, he writes short stories and is currently working on a feature-film script, Migraine.

Questions people ask

01

When is the risk register created?

During Identify Risks (Process 11.2), which is part of the Planning Process Group. It is then updated by every subsequent risk process and most other planning, executing, and monitoring processes.

02

Who owns the risk register?

The project manager owns the register. Individual risks have their own owners (the person accountable for monitoring and responding).

03

How many risks should a register contain?

Typically 30 to 80 for a substantial project. Below 15 to 20 suggests insufficient identification; above 100 suggests poor prioritisation or closure.

04

What is the difference between a risk and an issue?

A risk is a future, uncertain event. An issue is a present, certain event. When a risk occurs, it becomes an issue.

05

What is the difference between a risk and an assumption?

An assumption is something accepted as true without proof. If an assumption proves false, it becomes a risk (or an issue).

06

Do I need both qualitative and quantitative analysis?

Qualitative is required for every project. Quantitative is optional and used on larger or more sensitive projects.

07

How often should the register be updated?

Daily for active risks, weekly for full team review, monthly for steering committee, quarterly for re-baselining. The exact cadence depends on project size and pace.

08

Can opportunities be in the same register as threats?

Yes. PMI explicitly recommends a single register containing both. Separating them creates an artificial divide.

09

What is escalation as a response strategy?

When a risk falls outside the project's authority, it is escalated to a higher level (programme or organisation) and is owned there. The risk is removed from the project register.

10

What is a risk trigger?

The observable event that signals the risk is occurring or about to occur. Triggers allow timely response.

11

What is risk appetite?

The level of risk the organisation is willing to accept in pursuit of its objectives. It is set at organisational level and informs project-level tolerance.

12

What is the difference between risk tolerance and risk threshold?

Tolerance is the broad acceptable level. Threshold is the specific quantitative limit at which response is triggered.

13

Should I use a spreadsheet or a dedicated tool?

Either is fine if the discipline is in place. Spreadsheets work for projects up to roughly 50 risks. Dedicated tools (or PM platforms with risk modules) are better above that.

14

How does Monte Carlo differ from Expected Monetary Value?

EMV is a single calculation (probability times impact in money terms). Monte Carlo is a simulation that produces a distribution of outcomes. EMV is simpler; Monte Carlo is more informative.

15

What is contingency reserve?

The budget or schedule buffer set aside for identified risks. It is part of the cost or schedule baseline.

16

What is management reserve?

Budget or schedule buffer for unidentified risks. It is held outside the baseline by management.

17

Can I retire a risk?

Yes. A risk is retired (status closed) when it no longer applies (the trigger window has passed, the cause has been removed, or the project phase has ended).

18

Should closed risks be deleted?

No. They should be retained with status "closed" for audit and lessons-learned purposes.

Published 7 Jul 2026