Risk Assessment Plan Template: How to Write One

Quick answer: A risk assessment plan is the document that says how your organisation will identify, score, and prioritise risks — who does it, on what scale, and how often. It is not the assessment itself. Write the methodology and scoring scale first, because everything else depends on them.

One distinction to get right before you start, because most guides on this topic blur it: a risk assessment is something you do. A risk assessment plan is the document that governs how you do it. This guide is about the second one.

What Is a Risk Assessment Plan?

A risk assessment plan is a written document that defines how your organisation will identify, analyse, evaluate, and prioritise risks.

It answers five questions before anyone assesses anything:

Question	What the plan defines
What are we assessing?	Scope and boundaries
How will we score it?	Probability and impact scales, with anchors
Who does what?	Roles, owners, and sign-off
What method?	Qualitative, quantitative, or semi-quantitative
How often?	Review cadence and the triggers for an off-cycle assessment

Why it matters more than it sounds. Without a plan, two people assessing the same risk will score it differently, and neither will be wrong — because nobody defined what a “7” means. A plan makes assessments comparable across teams and over time. That being able to compare them is the entire point.

Risk assessment plan vs risk assessment vs risk management plan

These three get used interchangeably and they are not the same.

Document	What it covers
Risk assessment plan	How you will assess risks — methodology, scales, roles, cadence
Risk assessment	The output — the actual list of risks, scored and ranked
Risk management plan	The whole programme, including assessment and what you do about the risks
Risk register	The living log where assessed risks are recorded and tracked

The plan comes first. The assessment follows the plan. The register holds the results.

What Is a Comprehensive Risk Assessment Plan?

A comprehensive risk assessment plan covers scope, methodology, scoring, roles, techniques, documentation, review cadence, and the handoff to risk treatment — with nothing left to personal opinion.

The test for “comprehensive” is simple: could a new person run an assessment from this document alone and produce results comparable to yours? If they’d have to ask you what a 7 means, or who signs off, or how often to review, the plan isn’t finished.

Ten sections make a plan comprehensive. They’re below, and then the whole thing as a template you can copy.

What Goes in a Risk Assessment Plan? The 10 Sections

1. Purpose and scope

What this plan covers and — just as important — what it doesn’t. Name the business units, systems, projects, or processes in scope. Name the exclusions explicitly, because assessments drift most often when scope is left vague.

2. Definitions

Define risk, impact, probability, inherent risk, residual risk, risk appetite, and risk tolerance. This section feels like filler and isn’t. Most disagreements in a risk review are really arguments about words.

3. Methodology

Which approach you’re using — qualitative, quantitative, or semi-quantitative — and why. Name the standard you’re aligning to, if any.

4. Scoring scales

Your probability and impact scales with written anchors for every level. This is the most important section in the document. More on it below.

5. Risk matrix and thresholds

The grid that turns two scores into a priority, plus the threshold that decides which risks get a formal response.

6. Risk identification methods

How risks get onto the list: workshops, interviews, checklists, incident history, audit findings, supplier reviews. Say which ones you’ll actually use.

7. Roles and responsibilities

Who identifies, who scores, who challenges, who approves. A RACI table is the clearest format.

8. Documentation and the register

What gets recorded, in which fields, and where it lives. Define the register structure here so it’s consistent.

9. Review cadence and triggers

How often you reassess on schedule, plus the events that force an off-cycle assessment.

10. Handoff to risk treatment

What happens once a risk is scored and ranked. This section connects the plan to action — otherwise you’ve built a very tidy list that changes nothing.

Risk Assessment Plan Template (Copy This)

Copy this into a document and fill it in. Nothing here is gated.

RISK ASSESSMENT PLAN
Organisation:        ________________
Plan owner:          ________________
Version:             ____   Date: ________
Approved by:         ________________  Date: ________
Next review:         ________

1. PURPOSE AND SCOPE
Purpose:             ________________________________
In scope:            ________________________________
Out of scope:        ________________________________
Assessment period:   ________________

2. DEFINITIONS
Risk:                A potential event that could affect our objectives
Probability:         How likely the event is within the assessment period
Impact:              The effect if it occurs
Inherent risk:       Score before controls
Residual risk:       Score after controls
Risk appetite:       The level of risk we will accept in pursuit of objectives
Risk tolerance:      The maximum deviation from appetite we will accept

3. METHODOLOGY
Approach:            [ ] Qualitative  [ ] Quantitative  [ ] Semi-quantitative
Standard alignment:  [ ] ISO 31000  [ ] NIST SP 800-30  [ ] COSO ERM  [ ] None
Rationale:           ________________________________

4. SCORING SCALES
PROBABILITY
5 Almost certain  — expected in most circumstances / >80% in period
4 Likely          — will probably occur / 50–80%
3 Possible        — might occur / 20–50%
2 Unlikely        — could occur but not expected / 5–20%
1 Rare            — only in exceptional circumstances / <5%

IMPACT  (define per category — adjust the figures to your organisation)
5 Severe    — financial >£____ | outage >____ hrs | regulatory action
4 Major     — financial £____  | outage ____ hrs  | reportable breach
3 Moderate  — financial £____  | outage ____ hrs  | internal escalation
2 Minor     — financial £____  | outage ____ hrs  | absorbed locally
1 Negligible— financial <£____ | no outage        | no external effect

5. RISK MATRIX AND THRESHOLDS
Score = Probability × Impact  (1–25)
17–25  Critical  — response required, exec sign-off, weekly review
10–16  High      — response required, owner assigned, monthly review
5–9    Medium    — response optional, documented decision, quarterly review
1–4    Low       — log and monitor only, annual review
Response threshold: any risk scoring ____ or above

6. RISK IDENTIFICATION METHODS
[ ] Facilitated workshops     [ ] Structured interviews
[ ] Checklists                [ ] Incident and near-miss history
[ ] Audit and inspection findings
[ ] Supplier and third-party reviews
[ ] Horizon scanning / regulatory monitoring

7. ROLES AND RESPONSIBILITIES
Activity              | Responsible | Accountable | Consulted | Informed
Risk identification   |             |             |           |
Scoring               |             |             |           |
Challenge / review    |             |             |           |
Plan approval         |             |             |           |
Register maintenance  |             |             |           |

8. DOCUMENTATION — REGISTER FIELDS
ID | Description | Category | Probability | Impact | Inherent score |
Existing controls | Residual score | Owner | Response strategy |
Trigger | Review date | Status

9. REVIEW CADENCE AND TRIGGERS
Scheduled review:    ________________
Off-cycle triggers:
[ ] New system or major technology change
[ ] Security incident or breach
[ ] Merger, acquisition, or restructure
[ ] New product or service launch
[ ] Regulatory change
[ ] Significant supplier change
[ ] Any risk materialising

10. HANDOFF TO RISK TREATMENT
Risks scoring above threshold proceed to response planning.
Strategy selected from: avoid, transfer, mitigate, accept, escalate.
Response plans recorded against each risk with owner and date.

Two notes on using it. Fill in section 4 before anything else — every other number in the document depends on your scales. And keep the version number and approval date live; an unapproved plan is a draft, not a plan.

Risk Assessment Plan Sample: A Worked Example

Here’s the same structure filled in for a 40-person SaaS company assessing its platform and data risks. This is a risk assessment plan example you can adapt rather than an abstract illustration.

Scope: production platform, customer data, and third-party processors. Excludes physical office security and HR matters, covered separately.

Approach: semi-quantitative — 1–5 scales with financial anchors, aligned to ISO 31000.

Response threshold: 10.

Sample register entries:

ID	Description	P	I	Inherent	Existing controls	Residual	Owner	Strategy
R-01	Single cloud region outage takes platform offline	2	5	10	Daily backups; no failover region	10	CTO	Mitigate
R-02	Departing engineer retains production access	3	4	12	Manual offboarding checklist	8	Head of Eng	Mitigate
R-03	Key payment processor fails or terminates contract	2	4	8	Contract notice period 90 days	8	CFO	Transfer
R-04	Misdirected email exposes customer personal data	4	3	12	Annual training only	12	DPO	Mitigate
R-05	New data-protection regulation changes our obligations	3	3	9	None	9	Legal	Escalate
R-06	Laptop lost or stolen	3	2	6	Full-disk encryption, MDM	3	IT	Accept

What to notice, because this is where most plans go wrong:

R-04 has the same inherent and residual score. “Annual training only” is not a control that meaningfully reduces probability. Showing that honestly is the point — a plan that quietly credits weak controls produces comfortable numbers and real exposure.

R-01’s residual equals its inherent score too, because backups don’t prevent an outage, they recover from one. Controls that address impact-after-the-fact don’t reduce probability.

R-06 scores 3 residual, below the threshold of 10. It’s accepted and logged, not responded to. That’s a correct decision, not a gap.

Every row has one named owner. Not a team.

Once risks are scored and ranked, you pick a strategy for each — that’s a separate decision with its own reasoning, covered in our guide to risk response strategies.

How Do You Set a Scoring Scale That Works?

This is the section that decides whether your plan works, and the one most plans do badly.

The problem with unanchored scales. If your impact scale just says 1 to 5 with labels like “low” and “high,” two assessors will score the same risk differently and both will defend their number. The scale has to say what each level means in words someone can check.

Anchor every level to something observable:

Level	Bad anchor	Good anchor
5	“Catastrophic”	Loss over £500k, or outage over 24 hours, or regulatory enforcement
3	“Moderate”	Loss £10k–50k, or outage 2–8 hours, or internal escalation required
1	“Minimal”	Loss under £1k, no outage, absorbed by the team

Use categories for impact. One risk might be financially minor but reputationally severe. Define impact across three or four categories — financial, operational, regulatory, reputational — and score the highest applicable. Otherwise everything collapses into money.

Five levels, not ten. Ten-point scales invite false precision and endless argument about whether something is a 6 or a 7. Five is enough to rank and quick enough to apply.

Define probability against the assessment period. “Likely” means nothing without a timeframe. “Probably occurs within 12 months” means something.

Score inherent first, then residual. Inherent is the score with no controls; residual is after existing controls. Scoring inherent feels artificial — you already have controls — but it’s what tells you how much work your controls are carrying. If a risk drops from 20 to 4 because of one control, that control is load-bearing and needs monitoring.

What Does a Risk Matrix Look Like?

Most guides describe a risk matrix. Here it is.

	1 Negligible	2 Minor	3 Moderate	4 Major	5 Severe
5 Almost certain	5 — Medium	10 — High	15 — High	20 — Critical	25 — Critical
4 Likely	4 — Low	8 — Medium	12 — High	16 — High	20 — Critical
3 Possible	3 — Low	6 — Medium	9 — Medium	12 — High	15 — High
2 Unlikely	2 — Low	4 — Low	6 — Medium	8 — Medium	10 — High
1 Rare	1 — Low	2 — Low	3 — Low	4 — Low	5 — Medium

The band boundaries are a policy choice, not a mathematical one. Where you draw the line between “high” and “critical” reflects your risk appetite. A hospital and a startup facing identical scores will legitimately set different thresholds, and both can be right. Put your chosen boundaries in section 5 of the plan and apply them consistently.

One trap worth knowing: multiplication treats a 5×1 and a 1×5 identically, both scoring 5. But a rare catastrophic event and a near-certain trivial one need very different handling. That’s why the plan includes an override — anything with an impact of 5 gets reviewed regardless of its total score.

Qualitative, Quantitative, or Semi-Quantitative?

Three approaches, and the choice belongs in your methodology section.

Approach	How it works	Best when	Weakness
Qualitative	Descriptive scales — high, medium, low	Data is scarce; you need speed	Subjective; hard to compare across teams
Quantitative	Real numbers — expected loss, probability distributions, simulations	Data is abundant and decisions are expensive	Slow, costly, and false precision if the data is thin
Semi-quantitative	Numbered scales with defined anchors	Most organisations, most of the time	Still judgement, but consistently applied judgement

Semi-quantitative is the practical default, and it’s what the template above uses. You get numbers you can rank and compare without pretending to more precision than your data supports.

When quantitative is genuinely worth it: large capital projects, insurance decisions, and anything where you need a defensible expected-loss figure. Monte Carlo simulation and similar methods belong here.

Don’t mix approaches within one register. A qualitative 4 and a quantitative £80,000 aren’t comparable, and putting them side by side produces a ranking that means nothing.

Which Assessment Technique Should You Use?

Your plan should name which techniques you’ll use. Here’s what each is actually for.

Technique	What it does	Use it when
Risk matrix	Ranks risks by probability and impact	Always — it’s the baseline
Checklists	Ensures consistent coverage	Recurring assessments, audits, compliance reviews
Structured workshops	Surfaces risks nobody logged	Project kickoff, new systems, annual review
What-if analysis	Explores scenarios systematically	Safety-critical work, new processes
Bowtie analysis	Maps causes, consequences, and barriers around one event	A small number of high-impact risks
Fault tree analysis	Works backwards from a failure to its root causes	Engineering and system failures
FMEA	Scores failure modes by severity, occurrence, and detection	Manufacturing, product design, process risk
Monte Carlo simulation	Models ranges of outcomes under uncertainty	Quantitative work on large projects

Pick two or three, not eight. A plan listing every technique in the textbook is a sign nobody has decided. Name the ones you’ll actually run, and say when each applies.

The technique most organisations underuse is incident history. Your own past incidents and near-misses are the highest-quality risk data you have, and they’re free. Put them in section 6.

Which Standard Should Your Plan Align To?

Naming a standard in your methodology section does two things: it gives your plan credibility with auditors, and it saves you designing a process from scratch.

ISO 31000:2018 is the general risk management standard. It treats risk assessment as three sub-steps: risk identification, risk analysis, and risk evaluation. Its risk treatment options include modifying likelihood, modifying consequence, sharing, retaining, avoiding, and taking risk in order to pursue an opportunity. Use it for enterprise and general business risk.

NIST SP 800-30 is the US guide for conducting risk assessments, focused on information security. Its process runs prepare, conduct, communicate results, and maintain. Use it for information security and IT risk, especially if you work with US federal agencies or their suppliers.

COSO ERM is the enterprise risk management framework most used in financial reporting and internal control contexts, and it’s the common reference point for SOX work.

Two others worth knowing: ISO/IEC 27005 for information security risk specifically, and the NIST AI Risk Management Framework, published January 2023, which uses a govern, map, measure, manage structure for AI systems.

Be honest in your plan about how closely you align. “Aligned to ISO 31000” and “certified to ISO 31000” are different claims, and only one of them is usually true. Standards are updated from time to time, so cite the edition and check it’s current — “ISO 31000:2018” rather than just “ISO 31000.”

Who Should Sign Off a Risk Assessment Plan?

A risk assessment plan with no named approver is a suggestion.

The RACI in section 7 needs four distinct roles:

Responsible — the person who does the work. One name per activity.

Accountable — the person answerable for the outcome. Also one name. This is usually the plan owner.

Consulted — people whose input is required before scoring is final. Typically subject matter experts and control owners.

Informed — people who need the results but don’t shape them. Usually the board or an audit committee.

The most common failure is a missing challenge step. If the same person identifies and scores a risk with nobody questioning it, scores drift toward whatever feels comfortable. Build in a reviewer who is explicitly expected to push back.

How Often Should You Review the Plan?

Scheduled review depends on how fast your environment changes. Annual is the minimum for most organisations; quarterly for regulated or fast-moving contexts; continuous for safety-critical operations.

Triggers matter more than the schedule, because the things that change your risk picture don’t wait for your calendar. Put these in section 9:

• A new system, platform, or major technology change
• Any security incident or breach — including near-misses
• Merger, acquisition, or restructure
• A new product or service launch
• Regulatory change affecting your obligations
• A significant supplier change or supplier failure
• Any risk on the register actually materialising — that’s evidence your scoring was wrong somewhere

And review the plan itself, not just the risks. If your scales are producing scores nobody trusts, the fix is in the plan, not the register.

Step-by-Step Guide to Building a Risk Assessment Plan Using Cloud-Based Solutions

Cloud tools help most with the parts of risk management that fail for human reasons: visibility, ownership, and follow-through. Here’s a build sequence.

Step 1 — Write the plan document before choosing a tool. Use the template above. Tools change; your methodology shouldn’t have to be rebuilt each time. This is the step people skip, and it’s why so many risk tools end up half-populated.

Step 2 — Set your scales in the tool to match the document exactly. If the document says 1–5 with financial anchors, configure that. Don’t accept a tool’s defaults if they contradict your plan.

Step 3 — Build the register with your defined fields. ID, description, category, probability, impact, inherent score, controls, residual score, owner, strategy, trigger, review date, status.

Step 4 — Configure the threshold as an automatic rule. Anything scoring above your threshold should automatically require a response plan and an owner. Manual enforcement doesn’t survive a busy quarter.

Step 5 — Assign single named owners, with automated reminders. A monthly nudge to each owner does more than any dashboard.

Step 6 — Link risks to real tasks. This is the step that decides whether anything happens. A mitigation plan living only in a risk register is a document; the same plan as three dated tasks is work.

Step 7 — Set up trigger alerts where triggers are measurable — a date, a threshold, a milestone slip.

Step 8 — Build the roll-up path. Risks crossing a materiality threshold should become visible at portfolio or board level automatically.

Step 9 — Protect the review cadence. Put it in calendars with named attendees. A register nobody reviews decays within weeks.

Three cautions:

A populated dashboard is not managed risk. Track response completion, not risk count. A heat map full of neatly scored risks with no completed actions is the most common failure mode in cloud risk tooling.

Check what you’re uploading. Risk registers routinely contain sensitive business information — supplier problems, staffing issues, security gaps, contract exposure. Review your tool’s data handling and retention before putting that there, particularly for regulated work.

Beware alert fatigue. Alert on triggers and threshold breaches only. If everything notifies, nothing gets read.

What Are the Best Software Tools for Creating a Risk Assessment Plan?

Worth separating two different jobs, because most articles on this topic conflate them.

Job	What you need
Writing the plan document	A document tool or generator — the plan is prose, tables, and scales
Running assessments	A register with scoring, ownership, and workflow

You need both, and they’re rarely the same product.

For the plan document: a document generator or template-driven writing tool gets you a complete, consistently structured plan far faster than a blank page. This is the part where most of the time goes, because the plan is genuinely a writing task.

For running assessments:

Category	What it suits	Trade-off
Spreadsheets	Small organisations, first plan, under ~50 risks	No workflow, no reminders, version chaos as it grows
Project management tools with custom fields	Teams already using one; project-level risk	Not purpose-built; you’re constructing the register yourself
Dedicated risk / GRC platforms	Multiple business units, audit requirements, regulated industries	Cost and implementation time; often far more than you need
Compliance automation platforms	Certification-driven work (ISO 27001, SOC 2)	Scoped to the framework, not general business risk

Pricing note: vendor pricing in this category is frequently quote-only and changes often, and published figures in tool roundups go stale quickly. Check the vendor’s own page and ask directly rather than relying on any list, including this one.

And the test that matters: can the tool link a risk to an actual task with an owner and a date? If not, your responses will quietly not happen, whatever the dashboard shows.

Top-Rated Platforms for Automated Risk Assessment Plans for Small Businesses?

Being straight with you: most small businesses do not need a risk platform, and buying one early is a common and expensive mistake.

Enterprise GRC platforms are built for organisations with multiple business units, internal audit functions, and regulatory examiners. Setting one up takes months. If you have 40 staff and 30 risks, all that will sit unused.

What actually works at small-business scale:

Under ~50 risks: a well-structured spreadsheet built on the template above, plus calendar reminders for owners. Genuinely sufficient, and it forces you to understand your own methodology rather than inheriting a tool’s.

Growing, or with a compliance driver: a project management tool you already pay for, with custom fields matching your register structure. You get ownership, dates, and reminders without a new subscription.

When a platform becomes worth it — four signals:

1. An auditor or customer is asking for evidence of a documented process
2. You have more than one business unit assessing risks separately
3. You’re pursuing a certification that requires a risk register as evidence
4. You’ve had a risk materialise that your process should have caught

Until one of those is true, spend the money on writing a good plan instead of automating a bad one. Automation applied to an unclear methodology just produces confident nonsense faster.

What to ask any vendor before buying:

• Can I configure my own scoring scales and anchors, or am I stuck with yours?
• Can a risk link to a task with an owner and a due date?
• What happens to my data if I leave?
• What does this cost at double my current headcount?

8 Mistakes That Undermine a Risk Assessment Plan

1. Unanchored scoring scales. If a “4” isn’t defined in terms you can check, your scores aren’t comparable.

2. No response threshold. Without one, teams either respond to everything or nothing.

3. Skipping inherent scoring. You never learn which controls are load-bearing.

4. Crediting weak controls. “Annual training” rarely moves a score. Honest residual scores are the whole value.

5. Assigning risks to teams. One named person, or nobody watches it.

6. No challenge step. Unchallenged scores drift toward comfortable.

7. Buying a platform before writing the methodology. Automating an unclear process makes it worse, faster.

8. Treating the plan as a one-off. An unreviewed plan is a historical document within a year.

Risk Assessment Plan Checklist

• [ ] Scope defined, including explicit exclusions
• [ ] Key terms defined, including appetite and tolerance
• [ ] Methodology named and justified
• [ ] Probability scale anchored to a timeframe
• [ ] Impact scale anchored across financial, operational, regulatory, reputational
• [ ] Five levels, not ten
• [ ] Risk matrix included with band boundaries stated
• [ ] Response threshold set numerically
• [ ] Identification methods listed and realistic
• [ ] RACI complete, with a distinct challenge role
• [ ] Register fields defined
• [ ] Inherent and residual both scored
• [ ] Review cadence set and triggers listed
• [ ] Handoff to risk treatment described
• [ ] Standard and edition cited accurately
• [ ] Version number and approval date recorded
• [ ] A new starter could run an assessment from this document alone

How Writegenic AI Fits In

The plan is a document, and writing it properly is where the time goes. The methodology decisions take an afternoon; turning them into a complete, consistently structured, auditor-ready document takes considerably longer.

Writegenic AI is an AI writing platform with 300+ templates and support for 120+ languages, including a set built for business and project documentation:

• AI for Project Management — drafting project and governance documents from structured inputs
• Project management tools — templates for the surrounding artefacts
• Requirements management plan generator — for the document risk assessments often reference
• AI Business Management — broader business documentation
• AI Prompt Generator — build one reusable prompt encoding your scales and register fields so every plan comes out consistent

Where the line sits, clearly. A writing tool turns your decisions into a complete document and keeps ten plans consistent with each other. It cannot decide your risk appetite, know that your supplier has failed before, judge whether annual training is a real control, or tell you which standard your auditor expects. Those are your calls, and they’re the part that determines whether the plan is any good.

Draft the document with the tool. Keep the judgement.

Start with Writegenic AI free.

Frequently Asked Questions

Related reading: Risk Response Strategies: How to Choose One · AI for Project Management · Requirements Management Plan · Project Management Tools