Cybersecurity risk register templates are easy to find and mostly useless to a forty-person business. They arrive as forty-column spreadsheets designed for a bank, full of fields like “risk appetite tolerance band” and “control effectiveness maturity index”, and they are abandoned within a fortnight. The document that replaces them is usually nothing at all, which is how a company ends up telling an auditor that it manages risk “informally”.
The version that works for a small or mid-sized firm is much smaller than the templates suggest and much harder to keep alive than anyone admits. It is not a compliance artefact you produce once and file. It is a running argument about where the next thousand pounds of security budget should go, written down so the argument does not have to be had from scratch every quarter.
This guide gives you the columns that earn their place, scoring scales your colleagues can actually apply, a worked example for a mid-sized firm, and the review routine that stops the cybersecurity risk register rotting. It is written for organisations without a full-time security team, where the person maintaining it also runs the helpdesk, the backups and half the cybersecurity workload.
Table of contents
- What a cybersecurity risk register actually is
- Why SMEs need a cybersecurity risk register
- The columns your cybersecurity risk register template needs
- Scoring your cybersecurity risk register without false precision
- A worked cybersecurity risk register example
- Choosing a treatment for every cybersecurity risk register row
- Building the cybersecurity risk register step by step
- Keeping the cybersecurity risk register alive
- Cybersecurity risk register tools: spreadsheet or platform
- Frequently asked questions
- References
What a cybersecurity risk register actually is
Three documents get conflated constantly, and the confusion is why so many registers are unusable. An asset inventory lists what you have. A risk assessment is the exercise you run to work out what could go wrong. A cybersecurity risk register is the durable record of what you decided to do about it, who owns each decision, and when you will revisit it.
A cybersecurity risk register is a decision log, not an inventory
The single most common failure is treating the register as a list of bad things that could happen. A list of threats is not a register; it is a worry diary. What makes a cybersecurity risk register useful is that every row ends in a decision — mitigate, transfer, avoid or accept — with a named owner and a date attached to it.
That framing changes what you write. “Ransomware” is not a cybersecurity risk register entry. “Ransomware encrypts the finance file share because backups are not immutable and restore has never been tested, owner: IT Manager, treatment: move to immutable storage by 31 March” is a register entry, because somebody can be held to it.
Where the cybersecurity risk register sits in governance
In a larger organisation this document feeds a risk committee. In an SME it usually feeds one monthly management meeting and one annual insurance renewal, and that is fine. The IT governance value comes from having a single place where security decisions are recorded rather than scattered across email threads and half-remembered conversations.
It also becomes the backbone of every assurance conversation you will have. Certification bodies, enterprise customers and insurers all ask a version of the same question: show me that you know what your risks are and that somebody is doing something about them. A maintained cybersecurity risk register answers that in one document.
Register, assessment and inventory compared
| Aspect | Asset inventory | Risk assessment | Risk register |
|---|---|---|---|
| Question it answers | What do we have? | What could go wrong? | What are we doing about it? |
| Nature | A list of things | An exercise, run periodically | A living decision log |
| Owner | IT or operations | Whoever facilitates it | One named risk owner per row |
| Update rhythm | On change | Annually or on trigger | Monthly or quarterly |
| Typical size for an SME | Hundreds of lines | A workshop and a report | 15 to 40 rows |
| What auditors ask for | Supporting evidence | Method and date | The document itself |
Why SMEs need a cybersecurity risk register
Smaller firms often assume this is enterprise paperwork. In practice three separate forces now push the same document onto companies with fewer than 250 staff, and they arrive from different directions at roughly the same time.
The compliance pull
If you are pursuing ISO 27001, a documented risk process is not optional — the standard is built around it, and the cybersecurity risk register is the artefact that proves the process ran. Our ISO 27001 readiness assessment checklist covers where this sits in a certification timeline. Even Cyber Essentials, which is a controls scheme rather than a risk-based one, tends to surface the same gaps a first register pass would.
The commercial pull
The bigger driver for most SMEs is not regulation but customers. Enterprise procurement teams now send security questionnaires to suppliers of any size, and a surprising number of them ask directly whether a cybersecurity risk register exists and when it was last reviewed. A blank answer costs deals. Insurers have moved the same way, and a proposal form that asks about risk assessment frequency is asking about this document.
The practical pull
Underneath the paperwork there is a genuine operational problem. An SME has perhaps three to fifteen thousand pounds a year of discretionary security spend and roughly forty things it could sensibly do with it. Without a register the money goes to whatever was most recently frightening — usually whatever a vendor demonstrated last. With a cybersecurity risk register, it goes to the highest-rated untreated risk, which is a materially better allocation even when the scoring is crude.
Doing it before somebody makes you
Building the cybersecurity risk register under deadline pressure — a week before an audit, or during a questionnaire response — produces the forty-row fiction that everybody recognises and nobody trusts. Built calmly over two afternoons, the same document is genuinely useful and takes less total effort. The supplier cyber-risk assessment checklist is a good companion exercise, because third-party exposure is where most SME registers are thinnest.
The columns your cybersecurity risk register template needs
Here is the part most templates get wrong. Every additional column looks harmless when you design the sheet and becomes a reason not to update it six months later. The working set is eleven fields, and a cybersecurity risk register with more than fifteen is usually a register that has stopped being maintained.
The eleven fields that earn their place
An identifier, so risks can be referenced in minutes and emails. A short title. A description written as cause, event and consequence rather than a single noun. The asset or process affected. Inherent likelihood and inherent impact. The controls that already exist. Residual likelihood and residual impact. The treatment decision. A named owner. A review date.
That is enough to run a real programme. Everything else — risk appetite bands, control maturity scores, threat actor attribution, mapped framework references — is optional decoration that only pays for itself once you have a dedicated security function.
Fields that sound useful and are not
Probability expressed as a percentage is the most seductive mistake. Nobody in a fifty-person company can honestly distinguish a 12% annual likelihood from a 20% one, and writing the number down manufactures a confidence the underlying evidence cannot support. Ordinal bands are less impressive, more honest, and far easier to defend when somebody challenges a cybersecurity risk register entry.
Monetary expected loss has the same problem in a smaller way. Annualised loss expectancy is a fine idea in a large enterprise with claims history behind it. In an SME it becomes two invented numbers multiplied together, and the product inherits both errors.
Optional fields for regulated firms
If you operate under financial services rules, handle special-category personal data, or supply into critical national infrastructure, three extra columns pay their way: the regulatory obligation the risk touches, the notification clock that would start if it materialised, and evidence references. These matter because a regulator asks different questions than a customer does, and the compliance mapping is easier to maintain continuously than to reconstruct.
| Column | What goes in it | Worked example |
|---|---|---|
| ID | Stable reference, never reused | R-014 |
| Title | Six words or fewer | Unrestored backups of finance share |
| Description | Cause, event, consequence | Backups are not immutable, so ransomware encrypts them alongside live data, halting invoicing |
| Asset or process | What is exposed | Finance file share, Sage |
| Inherent likelihood | 1-5 before controls | 4 |
| Inherent impact | 1-5 before controls | 5 |
| Existing controls | What is already true | Nightly backup, 30-day retention, no immutability, untested restore |
| Residual score | Likelihood x impact after controls | 3 x 5 = 15 |
| Treatment | Mitigate, transfer, avoid, accept | Mitigate |
| Owner | A person, never a department | R. Chandra, IT Manager |
| Review date | Next scheduled challenge | 2026-11-30 |
Scoring your cybersecurity risk register without false precision
Scoring is where most first attempts collapse, usually because the scales were never defined and everybody quietly used their own. The fix is dull and effective: write the definitions into the template itself, so nobody has to remember what a 3 means.
Likelihood scales people can apply
Use five bands anchored to time, not to adjectives. Rare means you would not expect it in ten years. Unlikely means once in five to ten years. Possible means once in two to five years. Likely means roughly annually. Almost certain means several times a year, or it is happening now and you have not looked.
The time anchoring matters enormously. “Medium likelihood” invites argument; “we would expect this about once every three years” produces a real conversation about whether that is true, which is the conversation you wanted.
Impact scales anchored to money and time
Impact needs the same treatment, expressed in terms your finance director recognises. Band 1 is an inconvenience absorbed within a day. Band 3 is a few days of disruption, four to five figures of cost, some customer irritation. Band 5 is existential: multi-week outage, regulatory notification, contract loss, or a cash-flow event the business might not survive.
Set the money thresholds against your own turnover rather than copying someone else’s. A £50,000 loss is a rounding error for one firm and a redundancy round for another, and a cybersecurity risk register scored on somebody else’s thresholds ranks your risks in somebody else’s order.
Turning two numbers into a rating
| Likelihood \ Impact | 1 Minimal | 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 Critical | 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 |
Multiplying the two bands gives a number between 1 and 25, and banding that number gives you the sorting order the cybersecurity risk register exists to produce. Do not over-interpret it. A 15 and a 16 are the same risk in practice; a 4 and a 20 are not, and that is all the resolution you need.
Why inherent and residual both matter
Recording only the residual score hides your dependency on controls. If a risk sits at residual 6 purely because one backup job runs nightly, that fragility should be visible — the inherent 20 next to it tells the reader how far the fall is if that single control lapses. It also makes control failures legible during an incident review.
Some teams skip inherent scoring to save time, and for a first pass that is a defensible trade. Add inherent scoring to the cybersecurity risk register at the second review, when the entries have settled and the argument has moved from “what are our risks” to “what are we relying on”.
A worked cybersecurity risk register example
Abstract advice about columns is much less useful than seeing the rows. What follows is a realistic opening set for a sixty-person professional services firm running Microsoft 365, a couple of line-of-business applications and one small on-premises server.
The risks nearly every SME shares
Most first passes surface the same cluster. Business email compromise through a stolen credential. Ransomware reaching backups. A departing employee retaining access. A single administrator with no documented handover. An unpatched internet-facing appliance. Over-shared cloud storage. A supplier with access to your data and no security terms in the contract.
If your first cybersecurity risk register looks broadly like that list, you have not been unimaginative — you have described the actual threat landscape for a company of your size, which is far more uniform than vendors suggest.
How the entries read in practice
| ID | Risk | Existing controls | Residual | Treatment | Owner |
|---|---|---|---|---|---|
| R-001 | Credential phishing leads to mailbox takeover and invoice fraud | MFA on all accounts, mail filtering | 8 Medium | Mitigate: phishing-resistant MFA for finance | IT Manager |
| R-002 | Ransomware encrypts file server and its backups | Nightly backup, no immutability, restore untested | 15 High | Mitigate: immutable copy, quarterly restore test | IT Manager |
| R-003 | Leaver keeps access to cloud apps outside single sign-on | HR notifies IT, no app inventory | 12 High | Mitigate: offboarding checklist, app register | Operations Director |
| R-004 | Sole administrator unavailable during an incident | Break-glass account exists, undocumented | 9 Medium | Mitigate: documented runbook, second admin | Managing Director |
| R-005 | Unpatched VPN appliance exploited from the internet | Vendor alerts monitored ad hoc | 16 Critical | Mitigate: patch SLA, monthly external scan | IT Manager |
| R-006 | Client data over-shared via open SharePoint links | Default tenant settings, no review | 9 Medium | Mitigate: link policy, quarterly access review | Operations Director |
| R-007 | Payroll bureau breach exposes staff data | Contract silent on security and notification | 12 High | Transfer and mitigate: contract terms, assurance | Finance Director |
| R-008 | Legacy application cannot support modern authentication | Network restriction only | 10 High | Accept for 12 months, replace at renewal | Managing Director |
What the first pass usually reveals
Two things, reliably. First, that the highest-scoring items are almost never the ones the last vendor presentation was about — they are patching discipline, backup integrity and joiner-mover-leaver hygiene. Second, that four or five rows have no real owner, because they sit between IT and operations and have therefore belonged to nobody for years.
Both are valuable findings. A cybersecurity risk register that surfaces unowned risk in its first week has already paid for the afternoon it took to build.
Choosing a treatment for every cybersecurity risk register row
Every row ends in one of four decisions. Being explicit about which one matters more than the precision of the cybersecurity risk register scoring, because an unstated decision defaults to “we will worry about it later”, which is not a treatment.
Mitigate
Reduce likelihood, impact or both by doing something. This is the default for most rows and the only one that consumes budget directly. Write the specific action and its date into the cybersecurity risk register, not a general aspiration — “review our backup approach” is not a mitigation, “enable immutable retention on the Veeam repository by 31 March” is.
Transfer
Move the financial consequence elsewhere, usually through cyber insurance or a contractual indemnity. Transfer never moves the operational consequence: your customers still cannot reach the service, and your team still works the weekend. Insurers also increasingly decline claims where basic controls were absent, so transfer works best on top of mitigation.
Avoid
Stop doing the thing that creates the exposure. Decommission the legacy application, exit the data-sharing arrangement, or take the on-premises server out of service. Avoidance is underused in SMEs because it looks like a business decision rather than a security one, but it is often the cheapest available answer.
Accept, properly
Acceptance is legitimate and needs a signature. A risk accepted by the managing director, with a stated reason, an expiry date and a review trigger, is governance. The same risk left unscored at the bottom of a spreadsheet is negligence wearing the same clothes. Put accepted risks in front of the board at every review so acceptance stays a live decision.
| Treatment | Use when | Cost profile | Common mistake |
|---|---|---|---|
| Mitigate | Control gap is fixable at sensible cost | Capital or effort now | Vague actions with no date |
| Transfer | Loss is financial and quantifiable | Annual premium | Assuming it covers downtime |
| Avoid | Activity has low business value | Often negative, saves money | Never considered at all |
| Accept | Cost of treatment exceeds exposure | Zero now, variable later | Accepting silently, with no expiry |
Building the cybersecurity risk register step by step
The whole first build fits into two afternoons if you resist the urge to be comprehensive. Aim for a cybersecurity risk register of twenty rows that are true rather than sixty that are copied.
Scope the cybersecurity risk register before you populate it
Decide what is in and out in writing: which entities, which systems, whether physical and people risks are included, and whether supplier risk lives here or in a separate third-party register. For most SMEs one combined register is right, because splitting it creates two documents and maintains neither.
Populate from what you already know
Do not start your cybersecurity risk register from a threat taxonomy. Start from your last three incidents, your last support-ticket themes, the findings of any assessment you have had, and the questions your customers keep asking. A cybersecurity programme built from your own history is more accurate than one built from a generic catalogue, and it is faster to write.
Score in a room, not by email
Get three or four people with different views — IT, finance, operations — and score together in ninety minutes. Disagreement is the point: when the operations lead scores an outage impact 5 and IT scores it 2, the discussion that follows is the most valuable half hour of the exercise. Record the agreed number and move on.
Assign one owner and one date
Every row gets a named individual, not “IT” or “the SLT”. Every row gets a review date. Rows without both are not entries; they are notes. A cyber tabletop exercise run against your top three rows is an excellent way to test whether the owners agree they own them.
Keeping the cybersecurity risk register alive
Building it is the easy half. Almost every abandoned cybersecurity risk register was built enthusiastically and then never opened again, because no routine attached to it. The routine is what turns the document from an artefact into a control.
A cybersecurity risk register cadence that survives the day job
Quarterly is the right default for an SME, with a fifteen-minute slot in an existing monthly management meeting for anything urgent. Do not schedule a separate risk meeting; it will be the first thing cancelled. Reviewing the whole cybersecurity risk register quarterly and the top five rows monthly is sustainable for a team that has other work.
Triggers that force an out-of-cycle update
Certain events should reopen the document immediately: any incident, however small; a new system or supplier going live; a significant staff change in a risk-owning role; a major vulnerability affecting something you run; and any change in what you are contractually obliged to protect. Write these triggers into the template so the reaction is automatic.
Reporting upward without a dashboard
Boards do not want twenty rows. They want three things: what are our top five risks, what has changed since last time, and what are you asking us to fund. A single page with those three answers, drawn from the cybersecurity risk register, is more effective than any tooling. NCSC’s board toolkit is the best free framing for that conversation.
The failure patterns to watch for
The cybersecurity risk register that only ever grows. The one where every row is scored medium. The one whose review dates are all in the past. The cybersecurity risk register maintained by one person who leaves. Each is a signal that the document has stopped reflecting decisions and started performing compliance, and each is fixable by pruning ruthlessly at the next review.
Cybersecurity risk register tools: spreadsheet or platform
Tooling is the question people ask first and should ask last. A cybersecurity risk register is a discipline problem before it is a software problem, and the fanciest platform will not survive an organisation that has not decided who owns what.
When a spreadsheet is the right answer
For most organisations under about 150 staff, a cybersecurity risk register kept as a single spreadsheet in a controlled location is genuinely correct. It costs nothing, everyone can read it, and it exports cleanly for auditors. Protect it with version history and restricted edit access, and keep exactly one copy — the failure mode is four copies, not the format itself.
When to graduate
Move when one of three things becomes true: you are maintaining more than about sixty live rows; you need evidence linkage for a certification audit; or more than four people need to update entries concurrently. Those are workload signals, not maturity signals, and buying earlier rarely improves anything.
What to check before buying
| Factor | Spreadsheet | Lightweight GRC tool | Full GRC platform |
|---|---|---|---|
| Annual cost | Effectively zero | £1,500-£8,000 | £15,000+ |
| Setup effort | Hours | Days | Weeks, often with consultants |
| Audit evidence linking | Manual | Built in | Built in, with workflow |
| Review reminders | Calendar entries | Automated | Automated and escalating |
| Concurrent editors | Awkward beyond three | Fine | Fine |
| Right for | Under 150 staff | 150-500 staff or certifying | Regulated or multi-entity |
Whichever you choose, insist on export. A cybersecurity risk register you cannot get out of the tool in a readable format is a hostage, and platform changes are common enough that this matters. Ask for a sample export during the trial, not after the contract. Many firms run this alongside managed IT services, where the provider maintains the technical rows and the business owns the commercial ones.
Frequently asked questions
How many rows should an SME cybersecurity risk register have?
Between fifteen and forty rows for most organisations under 250 staff. Fewer than ten usually means the scope was too narrow or the exercise was rushed. More than sixty usually means control gaps have been logged as risks, which makes the document unmanageable and hides the things that genuinely matter.
Who should own the cybersecurity risk register?
One person maintains it — often an operations director, IT manager or the individual holding the IT security brief. Individual rows are owned by whoever can actually authorise the treatment, which is frequently not the same person. Ownership of the document and ownership of a risk are two different jobs.
How often does it need reviewing?
Review the cybersecurity risk register quarterly as a whole and monthly for the top five, and immediately after any incident or significant change. An annual review is the minimum an auditor will accept but is too slow to be useful operationally, since most SME estates change materially within a year.
Does ISO 27001 require this exact format?
No. The standard requires a documented risk assessment and treatment process with defined criteria, not a particular template. Any cybersecurity risk register format that shows criteria, assessment, treatment decisions, owners and review evidence satisfies it — including a well-kept spreadsheet.
Should supplier risks live in the same document?
For most SMEs, yes. A separate third-party register makes sense once you have more than about thirty suppliers with data access. Below that, splitting the record means two documents fall out of date instead of one, and supplier risk is where SME exposure is growing fastest.
What is the difference between a risk and an issue?
A risk might happen; an issue already has. Issues belong in a remediation plan or incident record, not the cybersecurity risk register. Mixing them is the fastest route to a document nobody trusts, because closed issues accumulate and drown the live entries.
References
NCSC Risk Management Collection
NCSC Cyber Security Board Toolkit
NCSC 10 Steps to Cyber Security
NCSC Cyber Essentials Overview
NIST SP 800-30r1 Guide for Conducting Risk Assessments
NIST SP 800-37r2 Risk Management Framework
NIST SP 800-39 Managing Information Security Risk
CIS Critical Security Controls
