IT risk management in ITIL 4 is the risk management practice, whose purpose is to ensure the organization understands and effectively handles risk. It covers identifying risks, assessing likelihood and impact, assigning owners, choosing a treatment, and monitoring results in a risk register. Risk management is one of the 14 general management practices among ITIL 4’s 34 practices, alongside 17 service management and 3 technical management practices.
What does poor IT risk management cost?
The Uptime Institute’s 2026 Annual Outage Analysis reports that 57% of respondents said their most recent major outage cost more than $100,000.
For the second consecutive year, 1 in 5 reported costs exceeding $1 million. Its 2025 analysis found nearly 40% of organizations had suffered a major outage caused by human error over the past three years.
Power remains the leading cause of impactful outages, so better process discipline cannot prevent every outage. Uptime’s 2025 report also found that 85% of human-error outages came from staff not following procedures or from flaws in the procedures themselves, and that kind of process risk depends on clear ownership more than on sophisticated modeling.
According to Gartner’s 2026 CIO Agenda, chief information officers (CIOs) who proactively manage geopolitical and vendor risks are 51% more likely to outperform, yet only 28% do so.
Was risk management a process in ITIL v3?
No. The IT Process Wiki records that ITIL v3 had no standalone risk process.
Risk sat inside service strategy, availability management, continuity and information security management, and external frameworks such as Management of Risk (M_o_R) supplied the method. What ITIL 4 added, on 11 January 2020, was a name, a category and a practice guide of its own.
Making risk a general management practice also settles accountability, because general management practices belong to the management layer. The risk method therefore sits above both the service desk and the security team.
Across the 34 ITIL 4 practices, risk management is one of the few that supplies criteria to the others, such as the risk thresholds change enablement applies at authorization.
What is a risk register in ITIL?
A risk register is the practice’s core artifact, a centralized record of identified risks with their likelihood, impact, owner and planned response.
Control assessments, audits and monitoring keep it current, but registers still decay when entries are free text that points at nothing, because such an entry cannot be reassessed when the estate changes.
When an entry is linked to an asset record, a planned change or a supplier, as the Matrix42 risk register allows, a decommissioning or a contract renewal puts it back in front of its owner. Those records come from service configuration management, which maintains the Configuration Management Database (CMDB), and from IT asset management, and they tie each risk to systems that actually exist.
Two kinds of entry are often missing from registers.
- Third-party exposure Uptime’s 2026 analysis puts third-party IT and data center service providers behind about two-thirds of reported impactful outages over nine years. That makes vendor risk management a register concern as much as a relationship management one.
- Artificial intelligence (AI) IBM’s Cost of a Data Breach Report 2026 records a 56% increase in AI-driven attacks, which added an average of $1 million to the cost of a breach.
For organizations in scope of the NIS2 Directive (the EU’s second Network and Information Security Directive), the register is where treatment of both becomes visible.
What are the 4 risk treatment options?
The four risk treatment options are avoid, modify, share and retain. These are the terms ISO/IEC 27005 uses; ISO 31000 describes the same choices at greater length, and some ITIL sources call them avoid, reduce, share and accept.
The four ITIL 4 risk treatment options
| Treatment option | What it means | When it fits | Example in IT |
|---|---|---|---|
| Avoid | Eliminate the source of the risk by not doing the activity or removing the exposure | The exposure outweighs any benefit and a workable alternative exists | Retiring an unsupported application instead of extending it for another year |
| Modify (reduce, mitigate) | Lower the likelihood, the impact, or both, using a control | The activity has to continue but the exposure can be engineered down | Automated patch deployment with tested rollback to limit failed-change impact |
| Share (transfer) | Move part of the exposure to a third party through contract or insurance | Another party can carry or absorb the exposure better than you can | Liability terms and service credits agreed with a hosting provider |
| Retain (accept) | Take the risk knowingly and in writing, inside the stated risk appetite | Treatment costs more than the exposure, or no proportionate treatment exists | Accepting a low-impact legacy integration until its replacement ships |
Retain is often misread as doing nothing. A retained risk is a documented decision inside an agreed risk appetite, and an undocumented risk is simply unmanaged.
ISO 31000:2018 also defines risk as the effect of uncertainty on objectives, so upside risk belongs in the same process, although registers seldom record it.
What is the difference between risk management and change enablement in ITIL 4?
The register is a standing organizational asset; change risk assessment is a per-change decision that feeds it.
Change enablement weighs the exposure of one proposed change against its benefit at authorization, using criteria that risk management supplies, and the register then absorbs whatever the change teaches.
Conflating the two produces two failure modes. In one, risks end up as fields on a change record and vanish when it closes. In the other, the register learns nothing from failed changes, so the same procedural weakness gets reassessed change by change and is never treated. Service validation and testing is a risk-reduction treatment applied before authorization. A risk that keeps materializing belongs in a problem record, which is problem management work.
Risk register entry, change risk assessment and incident: three different records
| Record | What it captures | Time horizon | Typical owner | What creates it |
|---|---|---|---|---|
| Risk register entry | A condition that could affect objectives, with likelihood, impact, treatment and review date | Standing, until closed or formally accepted | Risk owner | Assessment, audit, monitoring, or a risk that materialized elsewhere |
| Change risk assessment | The exposure created by one specific change, weighed against its benefit | The life of that change | Change authority | A change request entering authorization |
| Incident record | A risk that has already materialized and is affecting a service | Until service is restored | Incident manager or service owner | Detection by monitoring, a user report, or a failed change |
The three records also feed each other. A failed change closes its assessment, opens an incident and revises the register entry behind it. In Matrix42, an incident can be linked to the risk it materialized from, so that sequence stays on record.
What does a risk manager do in ITIL 4?
The risk manager owns the risk management method, while each individual risk has its own named risk owner.
The IT Process Wiki names the risk manager as the practice’s process owner; InvGate assigns the role the risk management policy, the day-to-day running of the practice, the upkeep of the register and reporting to stakeholders. Each risk then needs its own risk owner: one named person accountable for it and for its countermeasures.
That owner should be a service owner or budget holder outside the risk function, because ownership without the authority to approve budget or changes leaves the risk untreated.
In practice there are four roles, each with its own decision: the risk manager sets the method, the risk owner decides the treatment, the service owner carries the service, and the change authority authorizes the individual change.
Where that split is missing, registers fill with risks owned by committees. The same gap appears in IT projects, when a risk escalated out of the project management practice reaches the register without a named owner.
What are the KPIs for risk management in ITIL 4?
The key performance indicators (KPIs) for IT risk management fall into two groups: outcome metrics that show whether treatments work, and hygiene metrics that show whether the register is maintained.
- Outcome metrics Show whether treatments changed anything, for example mitigation effectiveness, escalation timeliness and the reduction in risk-related incidents.
- Hygiene metrics Show whether the register is maintained, for example completeness, training completion and policy compliance.
These examples come from Giva’s list of twelve risk management KPIs, and the grouping is this article’s own. The official AXELOS practice guide sits behind PeopleCert membership, so every KPI list published online is a secondary source.
Hygiene metrics are easier to improve than outcome metrics, and a register that is complete, fully owned and entirely untreated can score well on every hygiene measure. Report both groups so that a tidy register is not mistaken for a treated one.
Is ITIL 4 risk management the same as ISO 31000?
No. ISO 31000:2018 is a general risk management standard that supplies principles, a framework and a process, and ITIL 4 risk management works alongside it.
ISO states that the standard gives guidelines and is not intended for certification. ITIL 4’s practice is lighter and describes how risk management connects to change, continuity, supplier and security practices without providing a complete method.
For information security risk, ISO/IEC 27005 gives guidance on information security risk assessment aligned to ISO/IEC 27001. Control Objectives for Information and Related Technologies (COBIT) covers governance, and PeopleCert’s dedicated risk scheme is Management of Risk (M_o_R 4). There is no ITIL 4 Practitioner: Risk Management module.
Does ITIL 5 change the risk management practice?
No. Risk management remains a general management practice in ITIL (Version 5), although the categories around it change.
PeopleCert released ITIL Foundation (Version 5) on 12 February 2026, with ITIL Foundation Bridge (Version 5) for ITIL 4 certificate holders from 26 February 2026. ITIL 4 continues alongside it through the transition.
According to ITSM.tools, the ITIL Foundation (Version 5) publication keeps all 34 practices and regroups them into two categories, 12 general management practices and 22 product and service management practices, with the former technical management practices moved into the second group. Nothing in the change affects what a register has to contain.
Key takeaways
- Risk management is a general management practice Its classification places the risk method in the management layer, above the service desk and the security team.
- ITIL 4 turned risk into a named practice ITIL v3 had no standalone risk process and relied on frameworks such as M_o_R and ISO 31000. ITIL 4 gave risk its own practice and guide, which changed the emphasis while the underlying methods stayed the same.
- A useful register links to real records An entry that names no configuration item, service, asset, supplier or contract cannot be reassessed when the estate changes. The quality of IT risk management therefore depends on the quality of configuration and asset data.
- Change records and risk records serve different purposes A change risk assessment ends with the change it authorized, while the register entry stays open. Keep both, and feed what each failed change taught you back into the register.
- ITIL 4 is one approach among several ISO 31000 supplies the principles, framework and process backbone, ISO/IEC 27005 handles information security risk assessment, COBIT covers governance, and M_o_R 4 is the dedicated risk scheme. ITIL 4’s practice is the lighter layer that connects them to service management.
One risk register that points at the assets, changes and suppliers it depends on
Much of the risk that hurts IT is ordinary: a known procedure nobody followed, attached to a risk nobody owned.
A risk register kept in a separate tool loses sight of the records it depends on. The Matrix42 Risk Management solution has a single risk register across business units. Each entry links to the records it depends on: planned changes in change management, critical assets in IT asset management, and third parties in supplier management. Matrix42 Discovery and Dependency Mapping keeps the dependencies between systems current, so impact assessment uses today’s connections.
Matrix42 is a service management platform with a risk register; it does not offer a governance, risk and compliance (GRC) suite or an enterprise risk management product. Service and asset risk scoring is on the Matrix42 roadmap and is not yet part of the product.
Give every risk an owner and a record
See how planned changes, critical assets, third parties and the risks attached to them share one data model in Matrix42 IT service management.
Explore the future of ITSM→FAQs
Change enablement assesses each proposed change against the criteria the risk management practice defines: what the change touches, what depends on it, how likely failure is, and what failure would cost. The change authority weighs that against the expected benefit before authorizing. Lessons from the change, especially from a failure, then go into the register so they outlast the change record.
No. PeopleCert offers ITIL 4 Practitioner modules for 15 practices, including change enablement, problem management, IT asset management and information security management, but risk management is not among them. The dedicated risk qualification in the same portfolio is Management of Risk (M_o_R 4), offered at Foundation and Practitioner level as a separate scheme from ITIL.
Yes. ITIL 4 follows the ISO 31000 definition of risk as the effect of uncertainty on objectives, and uncertainty runs in both directions. In practice, registers lean toward threats, so the opportunity responses of exploit, enhance and escalate are rarely used. Recording an upside risk makes a decision not to pursue an opportunity visible and deliberate.
No. They are two separate general management practices. Information security management protects the confidentiality, integrity and availability of information and generates security risks; risk management supplies the organization-wide method, criteria and register those risks are recorded against. Security risk is one input stream into the register, alongside supplier, asset, project and continuity risk.
A risk owner is the single named individual accountable for one specific risk, for choosing and maintaining its countermeasures, and for reporting when its likelihood or impact shifts. Ownership needs authority, because if the named person cannot approve the budget or the change that treats the risk, the entry sits in the register unresolved while everyone assumes somebody else is handling it.
Risk appetite is the amount and type of risk an organization is willing to take in pursuit of its objectives, agreed before any individual risk is assessed. In IT service management it becomes practical thresholds: which changes need full authorization, which outage durations are tolerable, which suppliers require contractual safeguards. Without those thresholds, each risk decision becomes a separate negotiation.
ISO 31000:2018 is generic risk management guidance for any risk in any organization. It is explicitly not intended for certification. ISO/IEC 27005 is narrower and gives guidance on information security risk management aligned to ISO/IEC 27001. Many IT organizations run ISO 31000 as the umbrella method and ISO/IEC 27005 for security risk assessment.
Service continuity management consumes what risk management produces. Business impact analysis and risk assessment establish which services cannot tolerate interruption and what would cause one; continuity planning then sets recovery objectives, standby capability and invocation criteria for exactly those services. Continuity plans built without a current register can end up protecting services that are no longer the most critical.
A usable register in an IT service management tool is more than a list of text entries. Each record references the configuration items, services, assets, suppliers and contracts it concerns, and carries a named owner, likelihood and impact rated against defined criteria, the chosen treatment and a review date. Matrix42 keeps the register in the same platform as the change, asset and supplier records each entry points at.
Related articles
ITIL 4 practiceWhat is ITIL 4 Problem Management? Root cause analysis and KPIsRead the article →
ITIL 4 practiceWhat is ITIL 4 Project Management? Scope, roles and metricsRead the article →
ITIL 4 practiceWhat is ITIL 4 Service Validation and Testing? Criteria and MetricsRead the article →
ITIL 4 practiceWhat is ITIL 4 Relationship Management? Scope, roles and KPIsRead the article →
ITIL 4 topicWhat is a Configuration Management Database (CMDB)?Read the article →
ITIL 4 overviewITIL 4 practices for IT Service ManagementRead the article →
Sources
- 1 AXELOS / PeopleCert, “Risk management: ITIL 4 Practice Guide,” 2020.axelos.com/resource-hub/practice/risk-management-itil-4-practice-guide
- 2 IT Process Wiki / IT Process Maps, “Risk Management,” 2025.wiki.en.it-processmaps.com/index.php/Risk_Management
- 3 ISO, “ISO 31000 - Risk management,” 2018.iso.org/iso-31000-risk-management.html
- 4 PeopleCert, “ITIL Foundation (Version 5),” 2026.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil-5-foundation-version-50-4154
- 5 PeopleCert, “M_o_R 4 Practitioner (Management of Risk),” 2026.peoplecert.org/browse-certifications/change-risk-and-benefits-management/M_o_R-3/m_o_r-4-practitioner-3303
- 6 Uptime Institute, “Annual Outage Analysis Report 2026,” 2026.uptimeinstitute.com/about-ui/press-releases/uptime-announces-annual-outage-analysis-report-2026
- 7 Uptime Institute, “Annual Outage Analysis Report 2025,” 2025.uptimeinstitute.com/about-ui/press-releases/uptime-announces-annual-outage-analysis-report-2025
- 8 IBM with Ponemon Institute, “Cost of a Data Breach Report 2026,” 2026.ibm.com/reports/data-breach
- 9 Gartner, “The CIO Agenda 2026: Master Agility, Risk and Tenacity,” 2026.gartner.com/en/articles/cio-agenda
- 10 Giva, “ITIL 4 Risk Management Practice,” 2025.givainc.com/resources/itil/risk-management
- 11 InvGate, Sophie Danby, “ITIL & Risk Management: How Do They Relate?,” 2023.blog.invgate.com/itil-4-best-practice-overviews-risk-management
- 12 ITSM.tools, Stephen Mann, “ITIL Version 5 Management Practices Explained: Complete List and Definitions,” 2026.itsm.tools/itil-version-5-management-practices
- 13 PeopleCert, “ITIL 4 Practice Certifications,” 2026.peoplecert.org/ITIL4-practices