How to create a risk assessment process
How to design a risk assessment process: agree the criteria and appetite before scoring, describe risks as cause, event and consequence, score inherent and residual separately, and approve acceptance.
A risk assessment process runs from a trigger to a treated, owned and reviewed risk: agree criteria first, identify and describe, score before and after controls, then choose a treatment.
The short version
- Criteria and appetite before identification: otherwise scores are not comparable.
- Write risks as cause, event and consequence, not as a noun.
- Score inherent and residual separately so the controls' contribution is visible.
- Acceptance is a treatment and needs an approver with the authority to carry it.
- Every entry ends with a named owner and a review date.
Agree the scales before anyone scores anything
Risk assessment goes wrong before the scoring, not during it. If the likelihood and impact scales are undefined and the appetite threshold is unstated, two assessors will score the same exposure differently and both will be defensible, which makes the register a collection of opinions that cannot be ranked. Agreeing the criteria first is unglamorous and it is the thing that makes everything downstream comparable.
The second failure is the risk statement. "Supplier failure" cannot be assessed, because it names neither what would cause it nor what would follow, and the assessment becomes an argument about what the phrase meant. Cause, event and consequence is the minimum structure that makes a risk assessable, and writing it forces the vague entries in most registers to become either specific or obviously duplicated.
The example below is a risk assessment flow across five lanes and five phases. It scores inherent risk before crediting controls, evaluates residual against appetite, and draws acceptance as an approval decision rather than as what happens when nobody acts.
Trigger to monitored register entry
A risk assessment process across five lanes. Watch inherent and residual risk get scored separately.
Criteria first
Scope and objectives, then the criteria and appetite. Doing this before identification is what makes two assessors' scores comparable, and it is the step most often skipped in favour of getting straight to a workshop.
Identify, then describe properly
Identification with the team, a register entry, a duplicate check that merges rather than double-counts, and a cause-event-consequence description. The description step exists because a register full of one-word risks cannot be assessed at all.
Score before and after controls
Likelihood and impact, an inherent score, an assessment of existing control design and effectiveness, then residual against appetite. Scoring only the residual position hides how much rests on a single control that nobody has tested.
Four treatments, and acceptance needs a signature
Reduce, transfer, avoid or accept, with acceptance routed through an approval at the right level. That approval is the difference between accepting a risk and ignoring one, and without it acceptance is simply the default.
Owner and review date, then monitor
Re-evaluation after treatment loops back if residual risk is still too high, then an owner and a review date before monitoring. A register entry without both is accurate on the day it was written and decays quietly afterwards.
How it works
Write the scales and the appetite down
Define the likelihood and impact levels in concrete terms (money, downtime, harm, regulatory consequence) and state the threshold above which a risk must be treated rather than accepted. Criteria kept in a policy document get approximated from memory, which is how two assessors reach different scores from identical facts.
Identify with the people who do the work
Run identification as a group activity with operational staff, supplemented by incident and audit history. Identification done alone at a desk misses the risks only practitioners can see, and no amount of careful scoring afterwards compensates for a risk that was never written down.
Force the cause-event-consequence format
Rewrite every entry as "X could cause Y, resulting in Z". Most registers shrink when you do this, because several entries turn out to be the same risk described from different angles, and the ones that survive become assessable.
Score inherent risk before crediting controls
Keep the two scores as separate steps. Then rate control design and operating effectiveness separately, because a well-designed control nobody performs is worth nothing and a register that assumes otherwise is optimistic in a way you cannot see.
Set the approval level for acceptance
Write down who may accept a risk in each score band and require the acceptance to be recorded against a name. This one rule is what stops a register filling with risks that were accepted by default because nobody had time to treat them.
Give every entry an owner and a review trigger
A named risk owner (not a department) and a review date on the entry, plus event triggers: an incident, a supplier change, a new system, an audit finding. A register reviewed only annually is a description of last year.
Mistakes to avoid
Scoring before agreeing the scales
The results cannot be ranked or compared, and the first serious challenge to a score collapses confidence in the whole register.
Risks written as nouns
"Cyber" and "supplier failure" are categories, not risks. They cannot be scored, treated or owned.
Residual-only scoring
The register looks reassuring and cannot tell you which controls are load-bearing, which is the question that matters when one of them changes.
Acceptance by default
A risk nobody treated and nobody signed for has been accepted without anyone deciding to. Make acceptance an approval.
Create your own risk assessment process
Open the risk assessment example as your own chart, write in your scales, and set the approval level for acceptance.
Related guides
Frequently asked questions
What are the steps in a risk assessment process?
Establish the scope and criteria, identify risks, describe each as cause, event and consequence, analyse likelihood and impact, evaluate the residual position against appetite, select a treatment, and assign an owner and a review date. ISO 31000 groups identification, analysis and evaluation as risk assessment, with treatment following. The order is what makes results comparable: criteria before scoring, description before analysis, evaluation before anyone proposes controls.
What is the difference between inherent and residual risk?
Inherent risk is the exposure before existing controls are credited; residual is what remains after them. Scoring both makes the controls visible: a risk with a high inherent and low residual score is being held down by something specific, and if that something is one manual check performed by one person, that is worth knowing before they leave. Registers recording only residual scores cannot answer which controls are load-bearing.
What are the four risk treatment options?
Reduce (add or strengthen controls), transfer (insurance, contract terms, outsourcing), avoid (stop or change the activity), and accept (carry it knowingly). Accept is a real option that needs an approver: the difference between accepting a risk and ignoring one is a named person with authority and a record that they decided. Transfer is the most overstated: insurance moves financial consequence and rarely operational or reputational consequence.
How often should risks be reviewed?
On a cadence set by the score plus event triggers. Annually is a reasonable baseline for lower-scored risks and quarterly for those near the appetite threshold, but the triggers matter more: a new supplier, a system change, an incident, a regulatory change or an audit finding should each pull the affected entries forward. Scheduled-only review means the register is accurate on the day it is written and drifts for the rest of the year.
