How is the risk score calculated?

The risk score is probability multiplied by impact, each rated 1 to 5. This produces a score from 1 to 25, which the tool maps to bands: 1-4 Low, 5-9 Medium, 10-14 High, 15-25 Critical.

What is the difference between probability and impact?

Probability is how likely the risk is to occur, while impact is how severe the consequences would be if it did. A rare but catastrophic risk and a common but minor one can have the same score, so both dimensions matter.

Who should own a risk?

The risk owner is the single person accountable for monitoring the risk and triggering the mitigation plan. It is usually the team member with the most control over the risk area, not necessarily the project manager.

Do I need to mitigate every risk?

No. Common responses are avoid, transfer, mitigate, or accept. Low-score risks are often simply accepted and monitored, while high and critical risks always need an active mitigation strategy.

Is my data saved anywhere?

No. The entire register is built in your browser and nothing is sent to a server. Closing the tab clears it, so copy the Markdown export to keep your work.

What is the Risk Register Builder?

Creates a risk register table with risk description, category, probability score, impact score, risk rating, mitigation strategy, and owner per risk. Export as a Markdown table for any project. It runs free in your browser on Gera Tools, with nothing uploaded.

Risk Register Builder

Name: Risk Register Builder
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

Get one useful tool a week

Like this tool? Enter your email and we'll send you one genuinely useful Gera tool a week — plus a link to come back to this one. No spam, one-click unsubscribe any time.

A risk register is the backbone of project risk management: a living list of everything that could go wrong, scored so the team knows where to focus. This builder lets you capture each risk, score it, plan a response, and export a clean table you can paste into a project plan, wiki, or report.

How it works

Each risk is scored on two independent five-point scales. Probability answers “how likely is this to happen?” and impact answers “how bad would it be if it did?” The two are multiplied to give a risk score between 1 and 25. The score is then mapped to a rating band so the most dangerous risks rise to the top:

score = probability (1-5) × impact (1-5)

1-4   → Low
5-9   → Medium
10-14 → High
15-25 → Critical

This probability-times-impact model is the standard approach used in PMBOK, PRINCE2, and most ISO 31000-aligned frameworks. Multiplying the two scales means a risk only reaches Critical when it is both reasonably likely and seriously damaging — a highly likely low-impact risk and a rare catastrophic one both deserve attention, but for completely different reasons.

Worked example

Imagine a software launch with three risks:

Risk	Probability	Impact	Score	Rating
Payment gateway downtime at launch	3	5	15	Critical
Key developer off sick during final sprint	2	4	8	Medium
Minor UI bug in non-critical flow	4	1	4	Low

The Critical risk (payment outage) sits first and demands an active mitigation: pre-warm a fallback payment provider, agree a manual-override plan, and set the owner as the CTO. The Medium risk gets a mitigation but not a war-room. The Low risk might be accepted and monitored.

Writing effective risks

A well-formed risk reads as a cause-and-effect statement. Instead of writing “server problems,” write “the payment provider may rate-limit us during a launch spike, blocking checkouts.” That precision makes the mitigation obvious and avoids multiple team members interpreting the same vague label differently.

The four response strategies

Risk responses in PMBOK/PRINCE2 fall into four categories:

Avoid — change the plan so the risk cannot occur (e.g. drop the feature that requires the fragile third-party API)
Transfer — shift the financial impact to another party (e.g. buy insurance, use a vendor SLA with penalties)
Mitigate — reduce probability or impact (e.g. pre-warm capacity, add automated alerts)
Accept — acknowledge the risk and act only if it fires, often paired with a contingency plan

Low-score risks are typically accepted and monitored; Critical risks always need active mitigation with an assigned owner.

Keeping the register alive

Five well-managed risks beat forty stale ones. Review scores at each milestone, retire risks that have passed, and add new ones as the project evolves. Assign every risk an owner — the single person accountable for monitoring and triggering the mitigation plan — so accountability never falls through the cracks. The Markdown export makes it easy to embed the register in a project plan, Confluence page, or GitHub wiki and update it in place.