A risk register is a single list of the things that could damage your business, each one scored, assigned to a named owner, and given a review date. If you want to know how to build a risk register, the short version is this: list what could go wrong, rate how likely it is and how badly it would hurt, decide who owns it, write down what you are doing about it, and set a date to look again. One spreadsheet is enough to start.
The reason this document matters is that it is usually the first thing a customer, insurer or auditor asks to see. They are not checking whether you have eliminated risk. They are checking whether you can describe it.
What a risk register actually is
A risk register is a working document, not a report. It lives in a spreadsheet or a simple table and gets updated when something changes.
Each row describes one risk in plain language. Not "cyber" and not "staffing", but something specific enough to act on: "Our only bookkeeper has sole access to the payment approval queue." A risk you cannot picture happening is a risk nobody will manage.
The structure is standard across frameworks. NIST Special Publication 800-30, the US government guide to risk assessment, describes the same core logic of identifying a threat source, the event it causes, the likelihood, and the resulting impact. ISO 31000 uses similar language. You do not need to adopt either formally to use the shape they share.
How to build a risk register in seven steps
Work through these in order. The first pass should take a couple of hours, not a quarter.
- Set the scope. Decide whether you are registering risks for the whole business or one area, such as client data or service delivery. Write the scope at the top of the sheet so a reader knows what is deliberately excluded.
- List the risks. Pull from four sources: incidents you have already had, things that worry your team, dependencies you cannot replace, and obligations you have signed up to in contracts. Aim for fifteen to forty rows. Fewer than ten usually means you described categories rather than risks.
- Describe each one as cause and effect. Use the pattern "If X happens, then Y." This forces you to separate the event from the damage, which is what makes the row scoreable.
- Score likelihood and impact. A one-to-five scale on each axis is plenty. Multiply them for an inherent risk score between one and twenty-five. Write down what each number means before you start scoring, or the scores will drift between rows.
- Name an owner. One person, by name, for each row. Not a department. The owner is the person who reports on whether the response is working, which is a different job from doing the technical work.
- Record the response and the controls already in place. For each risk, pick one of four responses: reduce it, transfer it (usually insurance or a contract term), avoid it by stopping the activity, or accept it with a documented reason. Then list what you already do that lowers the score, such as offsite backups, approval thresholds, or multi-factor authentication.
- Set a review date and a residual score. The residual score is the likelihood and impact after your existing controls. The gap between inherent and residual is the visible value of the work you have already done.
Scoring without overthinking it
Define your scale once in a tab called "Definitions". For impact, anchor the numbers to things you can measure: hours of downtime, dollars, number of clients affected, or whether a regulator would have to be told. For likelihood, anchor to time: a five means you expect it this year, a one means you would be surprised to see it this decade.
Consistency beats precision. A register where every row was scored against the same written definitions is more useful than one with careful-looking numbers nobody can reproduce.
How to build a risk register your insurer and customers will accept
Buyers and underwriters look for four signals, and all four are structural rather than technical.
They look for ownership, meaning named people rather than job titles. They look for dates, meaning evidence the document has been touched more than once. They look for honest acceptance, meaning at least a few rows where you have written "accepted" with a reason, because a register with no accepted risks reads as incomplete. And they look for a link between the register and your decisions, such as a row that explains why you bought a particular control or changed a process.
What they do not look for is a long document. A tight twenty-row register that is clearly in use is stronger than a hundred-row document generated once and never revisited.
Common mistakes to avoid
Writing categories instead of risks. "Cybersecurity" is a topic. "A client list could be exported from our CRM by a departing employee because we do not remove access on the last day" is a risk.
Scoring everything as critical. If half your rows are red, the register has stopped prioritizing anything. Force yourself to spread the scores.
Letting it go stale. A register last updated eighteen months ago actively damages your credibility in a review, because it shows the process exists on paper only.
Keeping it secret. The owners need to see their own rows. A register only one person has read is a document, not a control.
Mixing risks with tasks. "Buy a password manager" is a task. It belongs in the response column of a risk, not in its own row.
Which risks small and mid-sized businesses miss most often
Most first drafts cover fire, flood and hacking, then stop. The rows that get missed tend to be the operational ones.
Single points of knowledge are the big one: the person who is the only one who knows how payroll runs, or how the quoting spreadsheet works. Vendor concentration is another, where one supplier or one platform underpins revenue with no tested alternative. Contractual exposure belongs there too, especially clauses you have signed about data handling, uptime or breach notification that nothing in your operation currently supports.
Access sprawl deserves its own row on almost every register. Accounts that were never removed, shared logins, and administrative rights that were granted for one project and never withdrawn. It is unglamorous and it is where a large share of real incidents begin.
Finally, add a row for the risk of the register itself being wrong, with a response of an annual review by someone who did not write it. Governance people call this challenge, and it is cheap.
Turning the register into a routine
Pick a cadence and hold it. A thirty-minute quarterly review where each owner confirms or changes their rows is enough for most businesses under a hundred people. Log the date of the review and what changed, even when the answer is nothing.
Once a year, do a longer pass: re-check the definitions, retire risks that no longer apply, and add anything new from the previous twelve months of incidents and near misses. Keep the old versions rather than overwriting, because the history is what proves the process is real.
The register also becomes your source material for everything downstream. Security questionnaires, insurance applications, written policies and incident planning all draw on the same list. Building it once saves the work later.
A risk register will not make your business safer by itself. It makes the next conversation possible, which is what moves work forward.
If you want a structured walk-through of scoring, ownership and review cadence applied to your own operation, start with the Risk Management capability page on this site.