How to Maintain a Project Risk Register: A Practical Guide
A risk register is a running list of everything that could go wrong on your project, what you will do about it, and who is watching each one. It sounds pessimistic, but it is one of the most practical documents a team can keep. Most project disasters were predictable, they just were not written down with an owner and a plan.
When to Use This
Create the risk register during project planning, right after the plan is drafted. Add to it whenever a new threat appears, a key supplier goes quiet, a team member resigns, a deadline shifts. It is essential for projects with tight deadlines, external dependencies, or new technology. Even a small project benefits: a five-person team launching a new product line faces real risks (a supplier missing a delivery, a key person falling ill) that deserve ten minutes of thought, not a panicked meeting later.
How to Fill It Out
Section 1: Risk description. Describe each risk as a cause-and-effect pair: “Because we rely on a single supplier for the custom cabinets (cause), a delivery delay could push the refit back by three weeks (effect).” Write it plainly enough that someone new to the project understands the threat. A risk that only makes sense to the person who wrote it will never get managed properly.
Section 2: Likelihood and impact. Score each risk on likelihood (how probable is it: low, medium, or high) and impact (how bad if it happens: low, medium, or high). Combine them into a priority. A risk that is high-likelihood and high-impact, “our only developer leaves mid-project”, gets attention first. A low-low risk, “the office printer breaks”, goes on the list but gets no action. Be honest in scoring; everything marked “high” means nothing is marked high.
Section 3: Owner. Assign one named person to each risk. The owner watches for warning signs and triggers the response if the risk materialises. “Owner: Sarah Lowe, watching supplier delivery dates weekly.” A risk with no owner is a risk nobody manages. The owner does not have to fix it alone, but they must be the one who raises the alarm.
Section 4: Response plan. For each significant risk, write what you will do to reduce it (prevention) and what you will do if it happens anyway (contingency). Example: “Prevention: order cabinets eight weeks early with a 20% buffer. Contingency: if delivery slips past 1 June, switch to the standard-range supplier (adds £2,400, saves two weeks).” Prevention is cheaper than contingency, spending £500 now to avoid a £5,000 problem is the whole point of the register.
Section 5: Status and review date. Track each risk as open, monitored, mitigated, or closed. Give each open risk a review date, weekly for high risks, monthly for the rest. When a risk passes without happening (the supplier delivered on time), mark it closed and move on. When a risk turns into a real problem, move it to the issue log and activate the contingency plan.
Section 6: New and retired risks. Keep a simple log at the bottom: risks added this month, risks closed, and any risk that escalated into an actual issue. This history shows the register is alive and helps future projects, the risks you faced this year are the risks to plan for next year.
Common Mistakes
1. Listing risks nobody will act on. Registers full of vague entries like “things might go wrong” or risks the team cannot influence (“the economy”) are useless. Every risk should be specific, and every significant risk should have an owner and at least a contingency. If there is nothing you can do about it, it is a fact to note, not a risk to manage.
2. Scoring everything high to look thorough. When every risk is high-likelihood and high-impact, the team learns to ignore the register. Score honestly and keep the high-priority list short, three to five risks. A register the team actually reads beats an exhaustive one nobody opens.
3. Writing it once and never reviewing it. A risk register created in January and untouched since is worse than useless, it gives a false sense of security. Risks change: the supplier that was reliable in March may be struggling in June. Review high-priority risks weekly and the full register monthly, and add new risks the moment they appear.
4. Hiding the register from stakeholders. Some project managers keep risks private to avoid worrying the sponsor. This backfires: when the risk happens, the sponsor asks why they were not told. Share the top risks in every status report. Stakeholders who know the risks can help manage them, a sponsor might approve the backup supplier cost or reassign a staff member.
Who Needs to Sign Off
The project manager owns the register and keeps it current. The sponsor reviews the top risks monthly and approves any contingency spending. Risk owners, the people named against each risk, confirm they accept the responsibility. No formal signature cycle is needed for routine updates, but a significant new risk (one that could move the end date or budget) should be flagged to the sponsor immediately.
How Often to Review and Update
Review high-priority risks weekly, a five-minute check in the team meeting is enough. Review the full register monthly, retiring old risks and adding new ones. Update immediately when a risk escalates, a new threat appears, or a mitigation is completed. The register should always reflect the project’s real risk picture as of this week, not last month.
Download the free Project Risk Register.