IT Risk Management Basics and the Risk Register

IT risk management is the habit of identifying what could go wrong with your technology, judging how likely and how damaging each problem would be, and deciding what to do about the important ones. The tool at its centre is the risk register: a simple table listing each risk, its score, its owner and its planned response. You can build a useful one in an afternoon with a spreadsheet.

What counts as an IT risk

A risk is something that might happen and would hurt the business if it did. It is not the same as an incident, which has already happened. Typical IT risks include:

• Loss of data through hardware failure, error or ransomware.
• A key system being unavailable for a long period.
• Unauthorised access to customer or staff data.
• A supplier failing or a service being withdrawn.
• Reliance on one person who holds all the knowledge or passwords.
• Unsupported or unpatched software.
• Failure to meet data protection obligations such as GDPR (this is not legal advice).

The process in five steps

1. Identify

List the systems and data the business cannot do without. For each, ask: what could stop it working, what could expose it, what could corrupt it? Talk to the people who use it daily; they know the fragile parts. Walk through the process end to end, including suppliers and staff changes.

2. Assess

Score each risk for likelihood and impact on a simple scale. A five-point scale works well.

Score	Likelihood	Impact
1	Rare	Minor inconvenience
2	Unlikely	Small, quickly fixed
3	Possible	Noticeable disruption or cost
4	Likely	Serious damage to operations or reputation
5	Almost certain	Threatens the business

Multiply the two to get a rating. Treat it as a ranking tool: the difference between a 12 and a 15 is a matter of judgement, but the difference between 4 and 20 is not.

3. Decide the response

There are four standard options:

• Reduce the risk with controls, such as backups, multi-factor authentication or patching.
• Avoid it by stopping the risky activity.
• Transfer it, for instance through insurance or a contract with a supplier.
• Accept it, deliberately and with a named person agreeing, when the cost of treatment outweighs the exposure.

4. Assign owners

Every risk needs a named person who is responsible for seeing the response through. A risk owned by "IT" or "everyone" is owned by nobody.

5. Review

Risks change as the business changes. Review the register on a schedule and after any significant event, whether a near miss, a new system or a staffing change.

A sample risk register

ID	Risk	L	I	Score	Response	Owner
R1	Main database fails and the latest backup cannot be restored	2	5	10	Reduce: automated backups, quarterly restore test	Operations lead
R2	Staff account compromised by phishing	4	4	16	Reduce: multi-factor authentication, staff awareness training	Office manager
R3	Only one person knows the admin passwords for key systems	3	4	12	Reduce: shared password manager, documented procedures	Director
R4	Accounting software supplier changes terms	2	3	6	Accept: review at renewal, keep data exportable	Finance lead

The figures above are illustrative scores for a made-up business, not benchmarks. Yours will differ because your business does.

What goes in each column

• Risk description: what could happen and what it would cause, in one plain sentence.
• Likelihood and impact: your scored estimates, and ideally a short note on why.
• Existing controls: what already reduces the risk.
• Planned response and due date: the specific action, not a vague intention.
• Owner and review date.

A practical checklist

1. List critical systems and the data on them.
2. Brainstorm risks with the people who use them.
3. Score each risk and rank the list.
4. Pick a response for each of the top risks.
5. Assign an owner and a date to each action.
6. Agree a review rhythm and put it in the calendar.
7. Report the top risks to the owner or board in plain language.

Common mistakes

• Making it too long. A register with 200 entries is never read. Focus on the significant ones.
• Listing only technical risks. People, process and supplier risks are often bigger.
• Scoring with false precision. It is a ranking, not science.
• No owner or deadline. Without these, nothing happens.
• Filing it and forgetting. An out-of-date register is worse than none because it gives false comfort.
• Accepting risks by default. Acceptance should be a conscious choice by someone with authority.

Linking risk to controls

A risk register tells you what could go wrong. Controls are the measures that make it less likely or less damaging. Controls come in three kinds: preventive (multi-factor authentication stops many account takeovers), detective (monitoring alerts you to unusual logins) and corrective (a tested restore gets you back after a failure). Good coverage has all three for your most serious risks, not just prevention.

For each high-scoring risk, ask what controls exist today, how confident you are that they work and what the score would be once the planned actions are done. The second score, often called residual risk, shows whether your plan is actually worth the effort.

Risk appetite in plain language

Different businesses tolerate different levels of risk. A clinic holding patient information has little room for data exposure; a small design studio might accept a day of downtime. Agree, in a sentence or two, what level of score needs action and who must approve acceptance of anything above it. A common approach is to define bands, such as scores above a chosen number needing a response plan and a senior sign-off, with lower ones reviewed periodically.

Reporting upward

Owners and directors need a summary, not the whole register. A one-page view with the top five risks, their trend since last time, the actions in progress and any decisions needed is enough. Use plain language: "if the finance server failed, we could not invoice for roughly the length of the restore" tells a director more than a numerical score does.

Third-party and supply-chain risk

Your risks include those you inherit from suppliers: a hosting provider outage, a software vendor being acquired, a developer leaving. For each critical supplier, record what you depend on them for, what the contract says about service levels and data return, and what your fallback is. Review these when contracts renew.

Near misses are free lessons

When something nearly goes wrong, such as a phishing email that someone almost clicked, a backup job that failed for a week or a laptop left on a train, record it and check whether the register reflects it. Near misses show which risks are more likely than you scored them, and they cost nothing to learn from. A blame-free habit of reporting them is one of the most effective, cheapest controls a small business can adopt.

Getting started

Pair this with an IT strategy: the strategy says where you are going, and the register says what might stop you. If you would like an outside view of either, Soch Tech's IT consulting and support service includes strategy planning and risk management, and our guide to building an IT strategy for a small business is a good companion read.