Risk Register Template
A risk register template with a filled worked example, covering what a register is actually for, the fields that matter, how to score without false precision, the four response options, and how to keep it maintained.
The template below is deliberately simple, because complexity is the main reason registers stop being maintained.
Quick answer: A risk register lists what could go wrong, how likely and severe it would be, who owns it, and what you are doing about it. Its purpose is not prediction — it is making uncertainty discussable before it becomes a crisis. Most registers are created during project setup and never reopened, which wastes the effort entirely.
What a Risk Register Is For
Registers exist to surface uncertainty early, and they only work if they distinguish risks from issues and get reviewed.
Making uncertainty discussable
Naming a risk converts a private worry into a shared, documented concern with an owner.
This changes what happens when it materialises. An unnamed risk that occurs is a surprise and a failure. A named risk that occurs is an anticipated event with a prepared response, and the conversation with your sponsor is entirely different.
Risks are not issues
A risk might happen. An issue has happened. They need separate handling and frequently separate logs.
When they are mixed, the register fills with current problems and the forward-looking function disappears. If something has already occurred, it is an issue to be managed, not a risk to be monitored — move it.
Why registers get abandoned
Two reasons. They are too complex — twenty fields, five-point scales, quantified impact nobody can estimate honestly. Or they are never reviewed, so entries go stale and the document becomes obviously fictional.
Simplicity and a review cadence solve both. Neither is difficult; both are routinely skipped.
The Risk Register Template
Nine fields, which is enough for almost any project.
Field Purpose Example ID Reference in discussion R-04 Risk description The cause, event and effect "If the vendor's API changes before integration, rework could delay launch by 2–3 weeks"
Category Grouping Technical, resource, external, commercial, compliance Probability How likely Low / Medium / High Impact How bad if it happens Low / Medium / High Score Sorting only Probability × impact Owner One named person Not a team Response What we are doing Avoid / transfer / mitigate / accept Mitigation actions Specific steps, with dates Actual tasks with owners Status Current state Open / monitoring / closed / became an issue
A Filled Example
Five risks on a software delivery project, sorted by score.
ID Risk Prob Impact Owner Response Mitigation R-01 If the payment vendor's sandbox remains unstable, integration testing cannot complete, delaying launch High High S. Thapa Mitigate Build against recorded
The Four Responses
as fallback (by 12 Sep).
Escalate to vendor account manager (done 2 Sep).
R-02 If the lead developer is pulled to production support, the build slows by an estimated 30% High Medium A. Rai Mitigate Agree protected capacity with head of engineering (by 8 Sep).
Second developer briefed on the codebase (by 15 Sep).
R-03 If legal review of terms takes longer than 2 weeks, launch date slips Medium High Legal lead Mitigate Draft submitted 4 weeks ahead rather than 2 (done).
Weekly check-in scheduled.
R-04 If fewer than 10 pilot customers respond, we launch without validation Medium Medium P. Karki Accept Accepted — proceed with fewer if necessary.
Contingenc y: extend pilot by one week.
R-05 If GDPR requirement s change before launch, consent flow needs rework Low High Legal lead Monitor Watching regulatory updates.
No action unless triggered.
Note the "if X then Y" structure — it forces a cause and a consequence rather than a vague worry.
Scoring Without Pretending to Be Precise
Three levels are enough, impact needs a stated dimension, and the score exists to sort risks rather than to report them.
Three levels, not five
Low, medium and high for both probability and impact. Five-point scales imply a precision nobody has, and produce lengthy arguments about whether something is a three or a four.
Three levels get you the same ordering with a fraction of the debate.
Impact on what, exactly
"High impact" is meaningless without a dimension. Impact on the timeline, the budget, quality, reputation or compliance?
State which. A risk with high schedule impact and low cost impact needs a different response from the reverse, and a single undifferentiated score hides that.
The score is for sorting, not for reporting
Probability multiplied by impact gives you an ordering so you can focus on the top few. That is its only job.
Reporting risk scores to executives invites false precision — "our risk score is 47" means nothing. Report the top three risks, their owners and what is being done about them.
What are the four risk responses?
Every open risk should have one of four responses chosen deliberately.
Response What it means Use when Example Avoid Change the plan so the risk cannot occur The risk is severe and the plan is flexible Drop the dependency on the unstable vendor entirely Transfer Move the consequence to another party The risk is financial or contractual Insurance, or a contractual penalty on the vendor Mitigate Reduce probability or impact Most risks, most of the time Build a fallback so a vendor failure costs days not weeks Accept Acknowledge and proceed Cost of response exceeds the exposure Accept a smaller pilot group and note the contingency
Accept is a legitimate choice, made explicitly. It is different from ignoring a risk, which is what happens by default.
Keeping the Register Alive
Review on a fixed cadence, close risks that have passed, and escalate what the owner cannot control.
Review at a fixed cadence
Fortnightly for most projects, weekly for high-risk ones. Fifteen minutes.
Three questions per risk: has the probability changed, has the mitigation happened, is it still relevant? A register reviewed on a schedule stays credible; one reviewed when someone remembers does not.
Close risks that have passed
When the risky phase is over, close it. When it materialises, close it and open an issue.
Registers that only grow become unusable. Closing entries is what keeps the list short enough to actually read.
Escalate what you cannot own
Some risks are genuinely outside the project's control — organisational resourcing decisions, external regulatory change, a vendor relationship owned elsewhere.
Assign the owner as the person who can actually act, even outside the project, and escalate explicitly to your sponsor. Where mitigation actions live as real tasks with owners and dates alongside the rest of the work, they get done rather than sitting in a document nobody opens.
Frequently asked
What is a risk register?
A document listing what could go wrong on a project, how likely and severe each would be, who owns it, and what is being done about it. Its purpose is surfacing uncertainty early rather than predicting outcomes.
What should a risk register include?
An ID, a description structured as cause and effect, category, probability, impact, score, one named owner, a chosen response, specific mitigation actions with dates, and status.
What is the difference between a risk and an issue?
A risk might happen; an issue has happened. Mixing them fills the register with current problems and destroys its forward-looking function.
How do you score risk?
Low, medium or high for probability and impact, with the impact dimension stated — schedule, cost, quality or reputation. Three levels avoid arguments that five-point scales generate without improving accuracy.
What are the four risk responses?
Avoid (change the plan so it cannot occur), transfer (move the consequence elsewhere), mitigate (reduce probability or impact), accept (acknowledge and proceed deliberately).
How often should a risk register be reviewed?
Fortnightly for most projects, weekly for high-risk ones. Fifteen minutes, checking whether probability has changed, mitigations happened, and entries are still relevant.
Who owns a risk?
One named person who can actually influence it — sometimes outside the project team. Team ownership means nobody owns it, and unowned risks are not managed.
Sanju Shrestha is a SaaS content writer at Taskzin who explores smarter ways to manage work, organize priorities, and improve team performance. Her content covers productivity strategies, digital workflows, collaboration, and task management, with a focus on helping modern teams work more efficiently and stay aligned.
All posts by Sanju Shrestha
Comments