Free Risk Management Plan Templates

A risk management plan sets out how an organization or project will deal with things that might go wrong: how risks get identified, how they’re scored, who owns them, what happens when one gets worse, and how often the whole thing is reviewed. At its centre sits the risk register — the working list of what could go wrong and what’s being done about it. The free templates below are editable MS Word files, and beneath them you’ll find a worked register, the scoring method behind it, and the two rules that separate a useful register from a list nobody reads.

A Risk Is Not an Issue

This is the distinction that decides whether a risk register is worth keeping.

A risk hasn’t happened yet. It’s something that might occur, with a likelihood you can estimate and an impact you can plan for. A issue has already happened — it’s a current problem, and what it needs is a fix, not a probability score.

Most poorly-run registers fill up with issues. “Supplier is late,” “budget is overspent,” “two staff have resigned” — all real, all already true, and none of them a risk. When that happens the register stops being a forward-looking tool and becomes a second, worse copy of the issues log, which is why people quietly stop updating it.

Keep them in separate lists. If it’s happening now, it belongs on the issues log and needs an action. If it might happen, it belongs on the risk register and needs a response strategy.

Write the Risk Properly: Cause, Event, Effect

“Staff shortage” isn’t a risk — it’s a topic. You can’t score it, mitigate it, or tell when it has passed.

Written properly, a risk has three parts:

If the lead engineer leaves before handover is complete (cause), then the remaining team may be unable to complete integration testing on schedule (event), resulting in a six-week delay and contractual penalties of around 40,000 (effect).

That version tells you what to do. The cause points at the mitigation — a documented handover, a retention conversation, a second engineer briefed in parallel. The effect gives you the impact score. And the event tells you what you’d actually be watching for.

It takes a minute longer to write and it’s the difference between a register that drives action and one that lists worries.

Scoring: Likelihood × Impact

Each risk gets two scores from 1 to 5, and multiplying them gives a number you can rank by:

RISK SCORING MATRIX  |  Score = Likelihood × Impact
		IMPACT ?
		1 Minor	2 Low	3 Mod	4 Major	5 Severe
L I K E L Y ?	5 Almost certain	5	10	15	20	25
	4 Likely	4	8	12	16	20
	3 Possible	3	6	9	12	15
	2 Unlikely	2	4	6	8	10
	1 Rare	1	2	3	4	5
1–4 monitor  ·  5–9 manage at team level  ·  10–15 escalate to sponsor  ·  16–25 immediate senior attention

The scale matters less than using it consistently. What makes it work is the escalation bands at the foot — deciding in advance that a risk scoring 16 goes to a sponsor automatically means nobody has to judge, in the moment, whether something is serious enough to raise.

The Four Responses

Every risk on the register should carry one of four strategies — often called the four Ts:

• Treat — reduce the likelihood, the impact, or both. The most common response, and the one that generates mitigation actions.
• Transfer — move the financial consequence elsewhere: insurance, a contract clause, a warranty, or outsourcing the activity. Note that you can transfer cost but rarely reputation.
• Tolerate — accept it and monitor. Legitimate where the cost of mitigation exceeds the exposure, but it should be a stated decision, not a default.
• Terminate — don’t do the thing that creates the risk. The response people forget exists, and occasionally the right one.

“Keep an eye on it” is not a strategy. If a risk has no response assigned, it’s either tolerated (say so) or nobody has decided yet (say that too, with a date by which someone will).

Risk Register Example

RISK REGISTER  |  Warehouse System Rollout  |  Reviewed 22 September 2026  |  Owner: K. Osei
ID	Risk (cause ? event ? effect)	L	I	Score	Response	Mitigation	Owner	Residual
R01	If the sole trainer is unavailable, staff training may not complete before go-live, delaying launch by 4–6 weeks	4	4	16	Treat	Backfill trainer contracted; session materials documented so any trainer can deliver	M. Chen	6
R02	If IT cannot schedule the Site B network upgrade, go-live at that site may slip past the contract deadline	3	5	15	Treat	Date escalated to IT Director; fallback of phased go-live agreed	R. Silva	8
R03	If migrated stock data contains errors, picking accuracy may fall post-launch, causing customer order failures	2	4	8	Treat	Full-copy test migration completed (99.4% match); exceptions cleared manually	M. Chen	3
R04	If the supplier ceases trading during the support period, we would lose vendor support for the platform	1	5	5	Transfer	Source-code escrow agreement signed at contract stage	K. Osei	2

The column that proves the plan is working is residual — the score after mitigation. R01 went from 16 to 6 because a backfill trainer was contracted and the materials were documented. A register showing only pre-mitigation scores records concern; one showing both records management.

Free Risk Management Plan Templates in MS Word

Each template below is editable in Word. Set your scoring scale and escalation thresholds once, then use the same definitions across every project — comparability between registers is most of the value.

Here’s another layout of the Risk Management Plan template to assist you in clarifying the project identifications, qualitative analysis, risk-response strategies, and also monitoring and controls.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

What the Plan Document Contains

The register is the working tool; the plan is the document that governs how it’s used. A complete one covers:

1. Scope — which project, programme, or part of the organization this plan applies to.
2. Roles and responsibilities — who owns the process, who can accept risk at what level, who reviews.
3. Identification method — how risks get raised: workshops, team meetings, an open channel anyone can use.
4. Scoring scales — what likelihood 3 means, what impact 4 means, defined in words and where possible in numbers (“major: cost impact over 25,000, or delay over one month”).
5. Escalation thresholds — which scores go to whom, automatically.
6. Response strategies and who authorizes each.
7. Reporting — what appears in the progress report, how often, and in what format.
8. Review cycle — when the register is revisited and by whom.
9. The register itself, attached as an appendix or linked.

Defining the scales matters more than it sounds. Without written definitions, one person’s “likely” is another’s “possible,” and two registers from the same organization become impossible to compare.

Keeping It Alive

• Review on a fixed cycle — monthly for most projects, weekly when things are moving fast. An unreviewed register is stale within a quarter and misleading within two.
• Re-score at each review. Likelihood changes as a project progresses; a risk that was likely in month one may be impossible by month six, and vice versa.
• Close risks explicitly, with a date and a reason, rather than deleting the row. The closed ones are the record of what you managed.
• Move realized risks to the issues log. When a risk happens, it stops being a risk — mark it realized, note where it went, and manage it as an issue.
• Check the mitigations are actually happening. A register full of well-written mitigations nobody has started is the most common failure, and the hardest to spot from the document alone.
• Keep it short enough to read. Forty risks means nobody looks at any of them. Report the top ten and keep the rest in the appendix.

Related documents: a risk analysis for the assessment exercise itself, a SWOT analysis where threats need identifying before they’re scored, an action plan for turning mitigations into dated tasks, and a business continuity plan for what happens if a severe risk is realized.

Frequently Asked Questions

What is a risk management plan?

The document setting out how risks will be identified, scored, owned, escalated, and reviewed for a project or organization — with the risk register attached as the working list of individual risks.

What is the difference between a risk and an issue?

A risk might happen; an issue already has. Risks get a likelihood, an impact score, and a response strategy. Issues get an action and an owner. Keeping them in separate lists is what stops a risk register becoming a duplicate issues log.

How do you write a risk statement?

As cause, event, and effect: “If [cause], then [event] may occur, resulting in [effect].” A topic like “staff shortage” can’t be scored or mitigated; the full statement tells you what to watch for and what to do about it.

How is a risk score calculated?

Likelihood multiplied by impact, each rated 1 to 5, giving a score between 1 and 25. Define what each level means in writing, and set escalation thresholds so a score above a stated figure automatically reaches a sponsor.

What are the four risk responses?

Treat (reduce likelihood or impact), Transfer (insurance or contract), Tolerate (accept and monitor), and Terminate (don’t do the activity). Every risk should carry one; “monitor it” on its own isn’t a strategy.

What is residual risk?

The score remaining after mitigation has been applied. Recording both the initial and residual scores is what demonstrates that your controls are doing something.

How often should a risk register be reviewed?

Monthly for most projects, weekly during intense delivery periods, and at every major milestone. Re-score at each review rather than simply confirming the list — likelihoods change as work progresses.