Risk Management Plan: Template, Steps and a Worked Example

What goes into a risk management plan, and what does not

Three documents get mixed up. The risk assessment is the act of scoring risks. The risk register is the living list of risks with their scores, owners and status. The plan is the rulebook above both: the method, the scales, the roles and how often you review.

That split matters when you present. Directors approve the plan once. They do not need to approve every new line in the register. Once the rules are signed, the team can add and close risks without a new meeting each time. The same logic separates a roadmap from a detailed schedule.

A complete plan covers these sections:

• Method: the steps you follow, usually set risk appetite, identify, assess, respond, monitor.
• Roles: plan owner, risk owners, sponsor and who can approve the reserve.
• Categories: a short list, or a risk breakdown structure (RBS) for large projects.
• Scales: what each probability and impact score means.
• Matrix and bands: how scores turn into low, medium, high or critical.
• Escalation thresholds: who hears about which band, and how fast.
• Reserve: the time and money held back for risk responses, and the rule for using it.
• Review rhythm and reporting: when the register is updated and where it is reported.

Risk management plan template you can copy

Paste this into a document and fill in each line. Keep it to one page. The register goes in an attachment.

• Project and sponsor: name, sponsor, plan owner, date approved.
• Objectives: the two or three results the project must deliver.
• Risk appetite: one sentence on what the sponsor will and will not accept.
• Method: identify at kickoff and at each phase gate, score from 1 to 5, respond to anything scored 5 or more, review weekly.
• Categories: technical, schedule, supplier, people, compliance, budget, external.
• Probability scale: 1 very unlikely, 2 unlikely, 3 possible, 4 likely, 5 very likely.
• Impact scale: 1 negligible, 2 minor, 3 moderate, 4 major, 5 severe. Define each in your own terms, for example in days of delay or share of budget.
• Bands: 1 to 4 low, 5 to 9 medium, 10 to 16 high, 20 to 25 critical.
• Escalation: one line per band, as written in the next section.
• Reserve: amount held, who can release it, and how use is reported.
• Reviews: weekly by owners, at each phase gate in full, monthly summary to the sponsor.

How to score risks and when to escalate

Use a 1 to 5 scale for probability and another for impact. The labels above are a starting point to adapt, not a standard. Some teams attach a percentage to each probability level. If you do, agree the ranges with your sponsor and write them in the plan, so two people scoring the same risk get the same number.

Impact has no universal scale, so define it for your project. On a fixed deadline launch, a 4 might mean "more than two weeks of delay". On a regulated project, it might mean "a finding from an auditor".

Multiply the two to get a score from 1 to 25. Only some numbers can come out of a 5 by 5 grid: 1, 2, 3, 4, 5, 6, 8, 9, 10, 12, 15, 16, 20 and 25. No product falls between 17 and 19, which is why the high band ends at 16 and the critical band starts at 20. Every possible score lands in exactly one band.

A sponsor will ask what happens at each band, so write it down:

• Low (1 to 4): the owner watches it. It stays in the register, no response required.
• Medium (5 to 9): needs a response and a trigger. The project manager reviews it weekly.
• High (10 to 16): response, trigger and fallback plan. Listed in every status report.
• Critical (20 to 25): the sponsor is told within one working day, and a decision is requested.

The four risk responses, with an example each

Every risk scored 5 or more gets one of four responses.

Accepting is a valid response. It must be a recorded decision with an owner and a trigger, not a risk nobody looked at.

• Avoid: change the plan so the risk cannot happen. Example: drop a feature that depends on an untested third party API.
• Transfer or share: move the impact to someone better placed to carry it. Example: a fixed price contract with a vendor, or insurance for event cancellation.
• Mitigate: lower the probability or the impact. Example: run a pilot with one region before the full rollout.
• Accept: do nothing now, but set a trigger, keep watching and hold some reserve. Example: a small chance of a short delay on a non critical deliverable.

A worked example: CRM migration risk register

Here is a filled register for a team moving 40 users from spreadsheets to a new CRM over 12 weeks. The scores are this team's own judgement, shown so you can see how the method works. Each line follows the plan: score, band, response, trigger, owner.

R01, R02 and R04 are high, so they also need a fallback plan. For R04, the fallback is to import those contacts later, once consent is confirmed. R05 is medium, and accepting it with a trigger and a buffer is a full response under the plan.

• R01, technical (4 x 4 = 16, high): customer records have duplicates, so imported data is wrong. Response: mitigate by cleaning data in week 3 and testing an import of 500 records. Trigger: more than a handful of errors in the test import. Owner: data lead.
• R02, people (3 x 4 = 12, high): sales reps keep using spreadsheets after go live. Response: mitigate by switching off the old files and training before launch. Trigger: spreadsheet edits seen after go live. Owner: sales manager.
• R03, supplier (2 x 4 = 8, medium): the integration partner's team is assigned elsewhere. Response: transfer by writing named staff into the contract. Trigger: a new name appears on the partner's status call. Owner: project manager.
• R04, compliance (2 x 5 = 10, high): contact consent fields do not map across. Response: avoid by not importing contacts without a consent value. Trigger: consent field empty in the import file. Owner: legal contact.
• R05, schedule (3 x 2 = 6, medium): go live clashes with quarter end. Response: accept, hold a one week buffer and take no other action now. Trigger: go live date moves into the last two weeks of the quarter. Owner: project manager.

Project risk management plan examples by team

The method stays the same. The risks change with the work.

• IT or product project: typical risks are dependencies on other teams, data quality, security review delays and vendor lock in. Phase gates line up with design, build, test and release, so a full register review sits naturally at each one.
• Marketing or launch plan: risks gather around fixed dates, such as late creative approval, a competitor launching first, ad account issues, or a product not ready on launch day. Set triggers tied to dates, such as "assets not approved 10 days before launch".
• Operations or HR rollout: think of a new shift system or an HRIS rollout. The biggest risks are people: low adoption, union or works council consultation, payroll errors and key staff leaving mid project. Owners here are often line managers, so keep the register language plain.

Review rhythm and who owns what

A plan fails when nobody updates it. Fix the rhythm in the plan itself. Risk owners update status, score and trigger before the weekly team meeting. The project manager reviews medium, high and critical risks in that meeting and adds new ones. The full register is reviewed at each phase gate, and the sponsor gets a monthly summary of the top risks and the reserve used.

Each risk has one owner, a person rather than a team. The owner watches the trigger and carries out the response. The sponsor owns the decision on critical risks and on releasing reserve.