A risk assessment is a decision document disguised as an analysis. Its job is not to list everything that could go wrong — that list is infinite and useless — but to give an organization a defensible order of worry: which threats, against which critical processes, with what likelihood and consequence, deserve money and attention first. This guide is the working method: how a professional risk assessment is scoped, built, scored, and kept alive, and where the amateur versions go wrong.
Step one: scope it before you assess anything
Every failed assessment failed here. Define the boundary — the whole enterprise, one site, one service line — and the purpose: continuity planning, insurance placement, a compliance examination, an acquisition. Then establish the context the scores will be judged against: the organization’s critical processes (from its business impact analysis), its obligations, and the downtime and loss it can actually absorb. An assessment without a stated scope drifts toward whichever hazard the loudest person in the room fears most.
Step two: identify hazards by family, not by headline
Work the all-hazards families in order. Natural: flood, wind, seismic, wildfire, severe weather — priced from the site’s actual geography, not the national news. Technological: power loss, connectivity loss, system failure, and the dependency failures that arrive through vendors and platforms. Human: error, insider acts, workplace violence, and the malicious external actors behind ransomware and fraud. Supply-side: the single-source supplier, the sole logistics route, the one plant that makes the component. For each family, name events in operational language — “river flooding closes the only access road for three days,” not “flood risk.” Events you can picture are events you can score; abstractions produce abstract registers that nobody funds.
Step three: find the vulnerabilities that turn hazards into losses
A hazard harms you only through a vulnerability. The same storm is a nuisance to the facility on high ground with a generator and a catastrophe to the one in the flood plain with a basement data room. For each hazard-event, ask what in your estate converts it into damage: single points of failure, undocumented workarounds, the one employee who knows the process, the backup that has never been restored, the contract with no continuity terms. This is where site knowledge earns its keep — walk the building, read the incident history, interview the people who run the night shift. The deep method for this analysis lives in this hub’s guide to risk assessment and threat analysis; the register you are building is its destination.
Step four: score likelihood and impact — and say what the numbers mean
Use scales with definitions, or do not use numbers at all. A five-point likelihood scale should anchor each point to a frequency (“expected at least once in five years”), and impact should be scored on the consequence the organization cares about — downtime against recovery objectives, financial loss, harm to people, regulatory and reputational damage — with the worst credible case stated, not the average one. Plot the results on the risk matrix, rank them, and then do the step most assessments skip: write, next to each score, the evidence or judgment it rests on. An undefended score is an opinion wearing a uniform; an examiner, an insurer, or a board will treat it accordingly.
Step five: decide, assign, date
The assessment ends in treatments, not in a heat map. Each material risk leaves the room with one of four decisions — avoid, reduce, transfer, or retain — plus a named owner and a date. Retained risks are recorded as retained, with the accepting authority’s name attached; the difference between a risk register and a wish list is that a register’s “accept” entries are signed. The frameworks that govern this discipline at enterprise level — ISO 31000, COSO ERM, and the NIST family — are compared in this hub’s guide to enterprise risk assessment frameworks; whichever one your organization names, this five-step method is the work it is asking for.
Keeping it alive
An assessment is a perishable good. Refresh it on a cycle (annually is the convention), and out of cycle whenever the world changes: a new facility, a new critical vendor, a merger, a near-miss, a loss. Feed it the incident record continuously — the risks that actually materialized last year are the best calibration your likelihood scales will ever get. And retire risks that no longer exist; a register that only grows teaches its readers to stop believing it.
Frequently asked questions
What is a risk assessment in business continuity?
The structured process of identifying the hazards that can disrupt an organization, analyzing the vulnerabilities that would turn them into losses, scoring likelihood and impact, and deciding — with owners and dates — what to do about each. It pairs with the business impact analysis: the BIA says what matters most; the risk assessment says what threatens it.
How often should a risk assessment be updated?
At least annually, and whenever something material changes: new sites or vendors, reorganizations, incidents and near-misses, or shifts in the threat landscape. Each refresh should re-score against the incident record, not just re-date the document.
What is the difference between a risk assessment and a BIA?
The BIA works inward-out: it ranks processes by the damage their loss would cause and sets recovery objectives. The risk assessment works outward-in: it catalogs the events that could cause those losses and how likely and severe they are. Continuity plans are built where the two meet.
What makes a risk assessment fail?
Vague scope, hazards named as abstractions, scales without definitions, scores with no stated evidence, and no treatment decisions at the end. The fix is procedural, not analytical: define the boundary, name events operationally, anchor the scales, cite the evidence, and leave the room with owners and dates.