How to build an IT risk register for a small business

Why bother with a register

Most small businesses carry IT risks that everyone vaguely knows about but nobody has written down: the backup nobody has tested, the founder who holds the only admin password, the ageing server, the single internet connection. Writing them down forces a decision on each one. Either you fix it, accept it knowingly, or transfer it, for example through insurance or a contract.

A register also helps when others ask. Insurers, larger customers, banks and potential buyers increasingly want to see that a business understands its risks. Showing a current, honest register is far more convincing than answering a questionnaire from memory, and it shows that risk is being managed rather than ignored. It also gives a new manager or IT provider a fast way to understand where the business stands.

What to put on the list

Start with the obvious categories. Security risks include phishing, ransomware, compromised accounts and payment redirection fraud. Availability risks include internet outages, power cuts, hardware failure and a cloud service going down. Data risks include accidental deletion, loss of a laptop, an unchecked backup and a privacy breach. People risks include key-person dependency and staff who leave without proper handover. Supplier risks include a software vendor failing or an IT provider holding your passwords.

Then add risks specific to your business. A medical practice may list access to patient records, an accounting firm may list tax season workload on systems, and a manufacturer may list the computer that runs a production machine. Ask each team leader what would stop their team working for a day, and you will usually uncover the most important items quickly.

Scoring likelihood and impact

For each risk, score how likely it is to happen in the next year and how bad it would be if it did, each on a simple scale such as one to five. Multiply the two to get a rough priority. Do not agonise over precision; the purpose is ranking, not prediction. A phishing attempt is very likely, while a fire is unlikely but severe, and both deserve attention for different reasons.

Write a sentence on what the impact would actually look like: hours of downtime, lost revenue, a regulatory notification, damage to reputation or a large recovery cost. Plain descriptions help owners understand why a risk is ranked where it is, and make it easier to justify spending on controls. They also make the register readable by someone who joins the business later and was not in the room when the scores were set.

Controls, owners and decisions

Next to each risk, list the controls already in place, such as multi-factor sign-in, a tested backup, a second internet connection or a documented leaver process. Then note any gaps and the action planned to close them, with a target date. Give every risk an owner, a named person in the business who is responsible for keeping it under control, even if the technical work is done by an outside provider.

Some risks will be accepted. That is fine, as long as it is a conscious decision recorded with a reason, such as the cost of a backup generator being far more than the likely loss from a rare power cut. An accepted risk documented by the owners is very different from a risk nobody noticed.

Keeping it current

Review the register quarterly, ideally as part of a regular IT review. Update scores, close completed actions, add new risks and remove ones that no longer apply. Any time something significant happens, such as a security incident, a new system, an office move or a big new client, revisit the relevant lines straight away. Date every review so anyone reading the register can see how recently it was checked.

Keep the register short enough that people actually read it. Fifteen to thirty well-described risks are more useful than two hundred generic ones copied from a template. Share the top five with the owners or board each quarter with a one-line status, so the most important risks stay visible without drowning anyone in detail.

Connecting the register to the budget

The register should drive spending. When you build the annual IT budget, look at the highest-scoring risks and ask what reducing each would cost. This gives owners a clear basis for decisions, because each item is linked to a risk they have already agreed matters. It also helps resist spending that sounds impressive but does not reduce any risk on the list, which is a common trap when a supplier is selling hard.

Over time, the register also becomes a record of improvement. Seeing risks move from high to medium to low as controls are added is a useful measure of progress, and a good way to show the value of IT spending to people who do not follow the technical detail. Keep old versions of the register, or at least a dated summary of the top risks each quarter, so that progress is visible over a year or more rather than only in the latest snapshot.