What a risk is
In IT, a risk is a possible event that could harm the organization’s goals, combined with how likely it is and how bad the effect would be. A server failing is an event. A risk is “the main file server fails during business hours and staff cannot work for a day”. Writing risks in that form, with a cause, an event and a consequence, makes them easier to discuss and rank.
Risk management is the ongoing process of finding such risks, judging their size, deciding what to do about them, and checking later whether the decision worked. The overall oversight of that process sits within IT governance, which decides how much risk is acceptable. This article focuses on the process itself.
The basic process
- Establish the context. Decide what is in scope: a department, a system, the whole organization. Agree on the scoring method before you start.
- Identify assets and risks.
- Analyze and score the risks.
- Evaluate and prioritize.
- Treat the risks.
- Monitor and review.
Identify what matters
Begin with the things the organization depends on: systems, data, services, people with unique knowledge, and key suppliers. Then ask what could go wrong with each. Useful prompts include:
- What would happen if this system were unavailable for a day? A week?
- What if this data were lost, changed or exposed?
- What if the one person who understands this left?
- What if a supplier stopped providing the service?
- What if staff made a common mistake, such as responding to a fraudulent email?
Talk to the people who run the work, not just IT. They often know about informal workarounds and dependencies that never made it into any diagram. Lists of common threats, such as malware, hardware failure and human error, can serve as prompts, but your own context matters more than any generic list.
Score likelihood and impact
Most small organizations do well with a simple scale. Rate likelihood from 1 to 5 and impact from 1 to 5, then multiply to get a score from 1 to 25.
| Score | Likelihood | Impact |
|---|---|---|
| 1 | Rare | Minor inconvenience |
| 2 | Unlikely | Noticeable but short disruption |
| 3 | Possible | Significant disruption or cost |
| 4 | Likely | Serious harm to operations or reputation |
| 5 | Almost certain | Severe, lasting harm |
Write down what each level means in your organization, for example, tying impact levels to hours of downtime or to cost bands, so different people score consistently. These numbers are judgments, not measurements. They help with ranking, but they should not be mistaken for precise predictions. If a risk is hard to score, note the uncertainty instead of forcing false precision.
A hypothetical risk register
A risk register is a table that records each risk, its score, who owns it and what is being done. The following example is entirely hypothetical and uses invented scores for a small office.
| Risk | Likelihood | Impact | Score | Owner | Planned treatment |
|---|---|---|---|---|---|
| Staff member is tricked by a fraudulent email and shares a password | 4 | 4 | 16 | IT lead | Awareness sessions; enable multi-factor sign-in |
| Important server runs without recent updates and is compromised | 3 | 4 | 12 | IT lead | Monthly update schedule; check for exceptions |
| Backups fail and are discovered only when needed | 2 | 5 | 10 | Operations manager | Regular restore tests |
| Company laptop is lost or stolen | 3 | 3 | 9 | Office manager | Disk encryption; remote lock option |
| Internet provider outage halts online work for a few hours | 3 | 2 | 6 | Operations manager | Mobile hotspot as fallback |
The score is simply likelihood multiplied by impact: 4 × 4 = 16, 3 × 4 = 12, 2 × 5 = 10, 3 × 3 = 9 and 3 × 2 = 6. Sorted by score, the phishing risk comes first and the internet outage last. Note that the backup risk has a lower score than the update risk but a very high impact, which is why some teams treat any impact of 5 as needing attention regardless of the product.
Prioritize
Sort the register by score and then apply judgment. Consider cost and effort, quick wins, legal or contractual obligations, and risks that depend on each other. Many organizations define bands, for example high, medium and low, and set expectations for each, such as “high risks need a plan and a named owner within a stated time”.
Treat the risks
There are four common responses:
- Reduce. Add controls that lower likelihood or impact, such as patching, training, backups or access restrictions. This is the most common choice.
- Avoid. Stop the activity that creates the risk, such as retiring an unsupported system.
- Transfer. Share the risk with another party, for example through insurance or a contract with a supplier. Transfer rarely removes the organization’s responsibility entirely, so read the terms carefully.
- Accept. Knowingly live with the risk, usually because it is small or the cost of reducing it is higher than the benefit. Acceptance should be a recorded decision by someone with the authority to make it, not a default through inaction.
After treatment, some risk remains. This leftover is called residual risk, and it should be recorded as well.
Many of the controls come from other areas. A security awareness program addresses human error. Regular vulnerability scanning and good patch management tackle technical weaknesses. A tested disaster recovery plan limits the damage of failure, and a response plan helps when something does happen. Considering business continuity alongside risk helps decide which systems need the most protection.
Monitor and review
A register is a living document. Review it on a regular schedule, often quarterly or twice a year for smaller organizations, and also when something changes: a new system, a new supplier, an incident, a change in regulations. After an incident, check whether the relevant risk was on the register and whether its score was reasonable. Report the top risks to leadership in a short, plain summary.
Where compliance fits in
Compliance requirements, such as laws, contract terms and industry rules, are a source of risk in two ways: failing to meet them may bring penalties or lost business, and they often prescribe controls. Include them in the assessment by listing the obligations that apply and asking where the organization may fall short. Which requirements apply varies with location, sector and the data you hold, so consult qualified advisers for specifics.
Common mistakes
- Treating the assessment as a one-time project
- Listing only technical risks and ignoring people, suppliers and processes
- Using scores as exact predictions
- Creating a long register nobody reads; a focused list of the top risks is more useful
- Leaving risks without owners
- Accepting risks silently
- Assessing only after an incident has already occurred
Getting started
Choose a limited scope, perhaps your five most critical systems. Gather the people who know them for an hour, list what could go wrong, score each risk on the 1 to 5 scales, and agree on owners and next steps. A rough first register that people actually use is better than a perfect one that never gets finished. Refine it on each review, and remember that outcomes remain uncertain no matter how thorough the process is; the aim is better decisions, not the removal of all risk.