In short
IT risk management is the continuous process of identifying what could go wrong with an organisation's technology, estimating how likely and how damaging each risk is, deciding how to treat it — reduce, transfer, avoid or accept — and monitoring it over time. A risk register records each risk, its owner, its score before and after controls, and the actions agreed to reduce it.
What counts as an IT risk
An IT risk is any uncertain event involving technology that could harm the organisation's objectives. Common examples include:
- Unpatched systems exploited by attackers, or ransomware encrypting critical data.
- A single server, link or supplier whose failure would stop an essential service.
- Dependence on one staff member who alone knows how a system works.
- A personal data breach leading to regulatory action and loss of trust.
- Power or connectivity outages at a data centre or branch.
- Failing to meet a legal or contractual obligation, such as data protection requirements.
Assessing risk: likelihood and impact
Most organisations score risks on two scales — how likely the event is and how severe the impact would be — typically from 1 to 5 each. Multiplying the two gives a score from 1 to 25, which is plotted on a risk matrix and grouped into bands such as low, medium, high and critical.
The scales only work if everyone applies them the same way. Define what each level means in concrete terms: for impact, the financial loss, length of disruption, regulatory consequence or reputational effect; for likelihood, how often the event could reasonably be expected to occur.
Inherent vs residual risk
Inherent risk is the level of a risk before any controls are considered. Residual risk is what remains after the controls and mitigations already in place. The gap between the two shows how much the controls are doing — and if residual risk is still above what the organisation is willing to accept, further treatment is needed.
Treating risk
There are four broad ways to respond to a risk:
- Reduce — add or strengthen controls, such as patching, redundancy or monitoring.
- Transfer — shift part of the impact to another party, for example through insurance or contract terms.
- Avoid — stop the activity that creates the risk.
- Accept — consciously tolerate the risk, with approval at the right level and a review date.
The risk register
The risk register is the working record of risk management. Each entry should include:
- A clear description of the risk — cause, event and consequence.
- The risk owner accountable for managing it.
- Likelihood, impact and score, both inherent and residual.
- Existing controls and the additional mitigation actions agreed, with owners and due dates.
- The date of the last review and the next review.
Monitoring and review
Risks change. Review the register on a regular cycle, and also when something happens that could change a score: an incident, a significant change to systems, a new critical vulnerability, a supplier problem or an audit finding. Tracking how scores move over time shows whether treatment is working.
Connecting risk to the rest of ICT management
Risk management is most useful when it draws on live information rather than opinion alone. Asset records show what is at stake; vulnerability findings and incidents show where threats are materialising; vendor dependencies expose single points of failure and concentration risk; business continuity plans show how well the organisation could recover.
How Ontech ICTM supports this
Ontech ICTM's risk capabilities include:
- A risk register recording inherent and residual risk, mitigations with owners, and review dates.
- Five-by-five likelihood and impact scoring with a heat map, banding scores of 20 and above as critical, 12 and above as high and 6 and above as medium.
- A unified risk score calculated from live data on incidents, compliance posture, business continuity risk, security findings and vendor single points of failure.
- Vendor concentration-risk analysis based on recorded application dependencies.
- Rule-based infrastructure risk scores derived from CPU, memory and disk thresholds.
Step by step: How to set up an IT risk register
Agree the scoring scales
Define what each likelihood and impact level from 1 to 5 means for your organisation, and the score bands that trigger action.
Identify risks
Run workshops with ICT, security, operations and business owners, and draw on incidents, audit findings and vulnerability reports.
Assign owners
Give every risk a named owner who is accountable for managing it.
Score inherent and residual risk
Score each risk before controls, then again taking existing controls into account.
Decide treatment
For risks above your tolerance, agree actions to reduce, transfer or avoid them — or record a formal acceptance with approval.
Review regularly
Revisit the register on a fixed cycle and after significant events, and report the highest risks to leadership.
Key takeaways
- IT risk management identifies, scores, treats and monitors technology risks continuously.
- Likelihood multiplied by impact, on agreed 1-to-5 scales, gives a comparable score.
- Residual risk — after controls — is what decides whether more action is needed.
- Every risk needs an owner, a treatment decision and a review date.
- Live data from assets, vulnerabilities, incidents and vendors makes risk scores more reliable.
Frequently asked questions
What is a risk matrix?
A risk matrix is a grid — commonly five by five — with likelihood on one axis and impact on the other. Each risk is placed according to its scores, and the resulting cell or product of the two scores indicates its band, such as low, medium, high or critical. It helps compare very different risks on one scale.
What is the difference between inherent and residual risk?
Inherent risk is the level of risk before any controls are applied. Residual risk is the level that remains after existing controls and mitigations. Decisions about further action should be based on residual risk compared with what the organisation is prepared to accept.
How often should IT risks be reviewed?
On a regular cycle — many organisations review high risks monthly and the full register quarterly — and additionally whenever an event could change a score, such as an incident, a major system change, a new critical vulnerability or a supplier failure.
Who should own an IT risk?
The person best placed to manage it and with the authority to act — often the owner of the affected business service or system, not automatically the head of ICT. The owner is accountable for the treatment plan and for keeping the assessment current.
What is the difference between a risk and an issue?
A risk is something that might happen; an issue is something that has already happened and needs resolving. When a risk materialises it becomes an issue or incident, and the risk assessment should be reviewed in light of what occurred.