How to Create a Usable Cyber Risk Register for a Small Business

What the register is for, and what you need before starting

A cyber risk register is a shared record of what could go wrong with your information and systems, how bad it would be, who is responsible for deciding what to do about it and when that decision was last looked at. It is not a compliance artefact or a catalogue of every possible threat. Its job is to turn a vague worry (we should probably do something about ransomware) into a decision somebody has actually made.

The NCSC's guidance for organisations new to cyber risk management starts in the same place: work out what matters to the business, list the assets that support it, give each asset an owner and record the risks in a register. It is also candid that this basic method is a starting point, not an approved NCSC method, and will not give a large or complex organisation all the insight it needs. For a small organisation with one or two sites, a cloud office suite and a handful of business applications, a starting point is what you want.

• A spreadsheet or shared table. Anything fancier can wait until the spreadsheet has proved its worth.
• A person with authority to accept risk on the business's behalf, usually the owner, a director or the managing partner. If nobody can accept a risk, nobody really owns it.
• A person who knows how the systems are actually set up. That may be an IT manager, an administrator or your external IT supplier.
• One uninterrupted conversation between those two people. The first draft is mostly talking, not typing.

Agree what High, Medium and Low mean before you score anything

Scores are where most registers quietly fail. If one person's Medium is another's High, the colours in the spreadsheet look authoritative while meaning nothing. The NCSC specifically warns that labels need their meaning documented and that simple matrices can cause errors and miscommunication if the scales are not explained. So agree the wording first, in plain business terms, and write it at the top of the sheet.

The definitions below are our suggested starting wording, not a published standard. Change them to fit your size, and keep them to three levels. A 3 by 3 grid is easy to argue about in ten minutes; a 5 by 5 grid invites an hour of debate over whether something is a 3 or a 4.

For impact, ask what it would mean for the business, not for the computer. Low: an annoyance that is fixed within a working day without customers noticing. Medium: some customers or staff affected, or the business disrupted for more than a day. High: the business cannot properly trade for several days, personal or confidential data is exposed, or the financial hit would be serious for a business your size.

For likelihood, name a time window, because the NCSC notes that risk statements should carry timescales. Low: unlikely in the next twelve months. Medium: could plausibly happen in the next twelve months. High: has happened to you before, or is the kind of thing that happens routinely to organisations like yours.

Multiply the two (Low is 1, Medium is 2, High is 3) to get a score from 1 to 9. Treat 6 and 9 as the ones needing a decision this quarter. That cut-off is a judgement call, not a rule.

Build the first version

Work through these in order. The sequence matters: risks written without a list of what you are protecting tend to come out generic, and scores written before the scale is agreed tend to cluster in the middle.

1. List what the business depends on. Think in terms of things you would notice missing within a day: the email and calendar system, the accounts or CRM package, the shared files, the website or booking system, the card payment arrangements, laptops and phones, and any one critical supplier. Ten to fifteen entries is plenty. For each, note what it holds or does (for example, customer personal data or payroll).
2. Put one named person against each item. Choose someone who would feel the loss and has the authority to decide what to do about it, which is not always the person who administers the system. Avoid owners such as IT, the office or everyone.
3. Write risks as short sentences describing what happens to what. Good: someone's email account is taken over through a phishing link and used to send fake invoices to our customers. Not so good: phishing. A sentence forces you to say the cause, the thing affected and the consequence, which is what makes the score defensible. Aim for roughly a dozen to start. You can add more once these are decided.
   textCopy

   Example entry for a 15-person office using a cloud email suite
   
   Asset: Staff email and calendar
   Risk: A member of staff's account is taken over through a phishing link and used to send fake bank-detail changes to our customers.
   Impact: High (customers could lose money and trust)
   Likelihood: Medium (plausible within twelve months)
   Score: 6
   Risk owner: Managing director
   Decision: Treat
   Action: Require multi-factor authentication on every account; agree a phone-call check for any change of bank details
   Action owner: IT manager
   Action due: End of next month
   Review date: Three months from today
   Notes: Not yet confirmed whether former staff accounts are still active

4. Score each risk for impact and likelihood using the scales you agreed, and write the scores down alongside a one-line reason. If you are unsure between two levels, record the higher one and note the uncertainty. The NCSC stresses that risk estimates should not give decision makers false certainty, and a note saying we do not know how exposed this is yet is more honest than a confident number.
5. Record a decision for every risk. The NCSC's basic method gives four: treat it (put controls in place to reduce it), avoid it (stop doing the risky thing), transfer it (for example through insurance or a supplier contract) or accept it. Accepting a risk is a legitimate choice, but it has to be someone's explicit choice with a name and a date, not a default outcome of never getting round to it.
6. For anything you are treating, add the next action, who will do it and by when. Separate the risk owner (accountable for the decision) from the action owner (does the work) where they differ. Your controls baseline can come from the NCSC's Small Business Guide, the free NCSC Cyber Action Toolkit or the Cyber Essentials requirements, rather than from a blank page.
7. Add a review date to every row, then sort the sheet by score. Read the top five aloud together. If anyone is surprised by an entry, or an owner objects to being the owner, fix it now while everyone is in the room. You should finish with a sheet where every row has a score, a decision, a name and a date, and where the top few rows have actions you could start on Monday.

Keep it alive without making it a chore

A register that is written once and filed is worse than none, because it gives a comfortable impression of control. The NCSC's board guidance says changes to risk should be assessed at least twice a year, and more often for higher-risk or fast-changing organisations. For a register this small we would suggest a short quarterly slot in the diary, with the same two people, as our own judgement rather than an official figure. Half an hour is realistic when the list is a dozen rows.

Between reviews, reopen the register when something material changes. Typical triggers are a new system or supplier holding your data, a move to home or hybrid working, a merger or office move, staff with admin rights leaving, an incident or near miss at your own business, or a significant warning about something you rely on. When a risk is treated, record what was done and re-score it afterwards. The gap between the original and the new score is the evidence that the work made a difference, and is the thing worth showing a partner, insurer or board.

Check it is usable

A register earns its keep if it can survive a quick, slightly awkward test. Hand it to someone who was not in the room and ask them three questions.

• Can they tell which three risks matter most right now, without being told?
• For any risk you point at, can they name who owns it and what has been decided?
• Can they see when each one was last reviewed and when it is next due?

If it is not working

Most failures are visible within the first couple of reviews. These are the common ones and what to do about each.

• Everything is scored Medium. The scales are probably too vague. Go back to the impact and likelihood wording and tie each level to something concrete such as days of disruption or customers affected.
• The list has grown to dozens of entries. Group similar risks (several account-takeover variants can usually be one entry) and park anything with a low score in a short second tab. A long register nobody reads has the same effect as no register.
• Owners are generic or absent. Reassign each risk to one person. If the real decision-maker is the owner or a director, say so and brief them properly; a risk nobody with authority will own is a governance gap, not a spreadsheet problem.
• The technical entries feel like guesses. That is normal if nobody has checked how things are configured. Make the first action on that row to find out (for example, who has admin rights, or whether backups have been tested to restore), then re-score.
• Reviews keep slipping. Put the dates in two diaries and make the review a recurring meeting with an agenda of the top risks and anything that changed. If it genuinely keeps slipping, reduce the cadence slightly rather than abandoning it.
• You need to show this to someone outside the business. A register shows that you have thought about the risks; it does not by itself prove they are controlled. For a technical sense check, a regulatory question or a contractual requirement, ask a specialist or your insurer what they actually need rather than assuming. The ICO says UK GDPR security should be appropriate to the risks and that you should be able to show you have analysed them, and a register is a sensible place to record that analysis, but it is not a substitute for taking advice on your own obligations.