What is ITIL 4 Problem Management? Root cause analysis and KPIs
Definition 
Problem management is the ITIL 4 practice that reduces the likelihood and impact of incidents by identifying their actual and potential causes and by managing workarounds and known errors. It is one of the 17 service management practices within ITIL 4’s 34 management practices, and it works in three phases: problem identification, problem control and error control.
Why do the same incidents keep coming back, and what does that cost?
They come back because restoring service and removing its cause are two different jobs, and only one of them is on the clock during an outage.
33%
of engineering time goes to fighting fires instead of new features
USD 76M
median annual cost of high-impact IT outages
41%
of leaders still learn about outages from complaints or manual checks
Source: New Relic, 2025 Observability Forecast
The cost lands twice as a result. The first payment is the incident itself: someone is interrupted, someone else drops what they were doing, service returns. The second arrives next month, when the same fault produces the same ticket and the same scramble. Only the first payment shows up in the incident report.
The scale of that second bill is visible in how engineering time is now spent. New Relic’s 2025 Observability Forecast found that engineers spend 33% of their time fighting fires or addressing disruptions, taking focus away from developing new features. The same study puts the annual median cost of high-impact IT outages at USD 76 million, with those outages carrying a median cost of USD 2 million per hour. Detection remains oddly manual: 41% of leaders reported that they still learn about service interruptions through inefficient means, such as customer complaints, incident tickets or manual checks.
The causes behind those failures are rarely exotic. Uptime Institute’s 2025 outage analysis found that nearly 40% of organizations have suffered a major outage caused by human error over the past three years, and that 85% of those incidents stem from staff failing to follow procedures or from flaws in the processes themselves. Procedural faults are precisely the kind that survive a restart. Nothing about closing the ticket touches them.
Problem management is the practice that goes after the second payment. It accepts that incident management will restore service and asks a separate question: what allowed this, and what stops it happening again.
What is a problem in ITIL 4, and how does it differ from an incident?
A problem is a cause, or potential cause, of one or more incidents. The incident is what the user experiences; the problem is what produced it.
AXELOS defines the purpose of the practice as reducing the likelihood and impact of incidents by identifying actual and potential causes of incidents, and managing workarounds and known errors. Two commitments sit inside that sentence. Causes count even when no incident has happened yet, which makes part of this practice proactive by definition. And managing a workaround is treated as doing the work rather than postponing it, which is a more useful position than it first appears.
Four terms carry the practice, and blurring any two of them produces a register full of records that are really just old incidents.
| Term | What it is | What it triggers |
|---|---|---|
| Incident | An unplanned interruption to a service, or a reduction in its quality | Restore service as quickly as possible |
| Problem | A cause, or potential cause, of one or more incidents | Investigate, analyze and prioritize against other problems |
| Known error | A problem that has been analyzed but not yet resolved | Publish the workaround; decide whether to fund the permanent fix |
| Workaround | A solution that reduces or eliminates the impact of an incident or problem while a full resolution is unavailable | Apply at first line; record it so the next agent finds it |
The closure test separates the first two cleanly. An incident is closed when the user can work again. A problem is closed when the cause can no longer produce that incident. Different tests, different timescales, and usually different people best placed to apply them. Organizations that run one test for both end up with a service desk that becomes very fast at fixing the same thing forever.
ITIL 4 keeps problem management among the 17 service management practices, one family within the 34 management practices that also include 14 general management practices and 3 technical management practices. The name survived the move from ITIL v3, where change management became change enablement, but the position changed: ITIL v3 placed problem management inside the Service Operation lifecycle stage as a process with a defined sequence, while ITIL 4 treats it as a practice feeding several value streams.
In an organization releasing weekly rather than quarterly, that matters. Investigation stops being something that happens after the operational dust settles, and its output competes for capacity alongside feature work.
How does a problem move from first symptom to closed cause?
Through three phases that run continuously rather than in single file, fed by a set of triggers that decide the quality of everything downstream.
Where do problem records come from?
Six sources account for most of them: trend analysis across incident categories, the review that follows a major incident, event data from monitoring, supplier and vendor advisories, defects surfaced during testing before release, and the informal knowledge of engineers who already know which component is fragile. The last of those is the most underused and the cheapest to collect.
Nothing in the incident queue forces anyone to notice that one category has produced eleven tickets this quarter. Somebody has to look, on a schedule, with the authority to open a record. That is why identification is the thinnest part of most practices: it depends on data nobody owns.
What happens in problem identification, problem control and error control?
| Phase | Central question | What it produces |
|---|---|---|
| 1Problem identification | Which underlying faults are worth investigating at all? | Problem records raised from trends, events, supplier notices and test results |
| 2Problem control | What is actually causing this, and how much does it hurt? | Root cause analysis, risk assessment, prioritization, a known error record with a workaround |
| 3Error control | What removes it permanently, and is that worth funding? | A change request, an accepted residual risk, or a decision to keep the workaround |
Problem control ends in a decision, not a fix. Once the cause is understood the record is reclassified as a known error, whether or not anyone has resolved anything. That reclassification is the point of the phase: it converts an open investigation into something first line can act on today.
Error control is the phase organizations quietly skip. A permanent fix travels as a change, so it needs authorization from change enablement and a slot in the release schedule, which means it competes with everything else IT wants to ship. Not every known error deserves to win that competition. Some belong in the register with an accepted risk, a named owner and a review date.
What kills a problem register is not the decision to defer, it is the absence of any decision: records opened during a major incident review, assigned to nobody, reviewed never. Volume grows, credibility drains, and within a year the register is an archive rather than a work queue.
Is a workaround good enough, or does every problem need a permanent fix?
A workaround is a legitimate outcome, and ITIL 4 says so by naming it in the purpose of the practice.
The arithmetic supports that position. A documented workaround that cuts impact for three thousand users next Tuesday is worth more than a permanent fix that lands in the next quarter. Time to workaround is often the honest measure of what the practice delivers, because it is the moment user pain actually drops.
The known error database, or KEDB, is where that value gets collected. Its whole purpose is retrieval under pressure: an agent halfway through a call needs to find the known error in seconds, or the record may as well not exist.
This is why problem management fails so reliably when it is disconnected from knowledge management. A workaround nobody can retrieve during an incident has no operational value at all, however carefully it was written.
When does a workaround become a risk?
When it outlives the decision that created it. A known error stays open for two years, the workaround gets baked into a runbook, new joiners learn it as the way the service works, and nobody ever formally accepted the underlying risk. The decision was not made badly; it was never made. Review dates on known error records exist to force that judgment back onto someone's desk while acting on it is still cheap.
How do you choose the right root cause analysis technique?
Match the technique to the shape of the fault. ITIL 4 does not mandate one method.
The practice guidance points to established root cause analysis techniques, alongside impact analysis techniques such as business impact analysis and component failure impact analysis, and leaves the selection to the analyst. Most teams instead reach for whichever technique they learned first, which is why five whys gets applied to problems it cannot solve.
| Technique | Suited to | How it works |
|---|---|---|
| Five whys | Simple linear faults with one clear causal chain | Ask why repeatedly until the answer stops being a symptom |
| Ishikawa (fishbone) diagram | Problems with many candidate causes spread across teams | Map causes visually into categories such as people, process, technology and suppliers |
| Kepner-Tregoe problem analysis | Complex faults where the obvious answer keeps turning out to be wrong | Describe what, where, when and scope; identify possible causes; test the most probable; verify the true one |
| Pareto analysis | Deciding which problems justify investigation at all | Rank causes by frequency or impact, then concentrate on the few producing most of the pain |
| Fault tree analysis | Failures in systems with redundancy and layered dependencies | Work backward graphically from the failure through the combinations that could have produced it |
| Pain value analysis | Prioritizing when every problem looks urgent | Score the real business pain: users affected, duration, service criticality and cost |
Why do root cause investigations stall?
Two errors show up regardless of which technique is on the whiteboard. The first is stopping at the component. “The disk filled up” is a symptom wearing technical vocabulary; the causes are why nothing alerted before it filled and why no one owned the threshold.
The second is letting the analysis drift into an inquiry about who was careless. Google’s site reliability engineering practice argued for blameless postmortems on plainly practical grounds: engineers who expect to be punished stop volunteering the detail that makes an investigation useful, and the organization loses its best evidence. ITIL 4’s emphasis on culture and collaboration points the same way.
Why does proactive problem management keep losing to the incident queue?
Because it is a scheduling problem dressed up as a maturity problem.
Reactive problem management starts from something that already broke. Proactive problem management starts from a pattern, a risk or a near miss: a component that fails twice a quarter, a vendor advisory, a capacity curve heading the wrong way, a service that stays up only because someone restarts it every Sunday night. The analysis is identical. What differs is the trigger and, more importantly, who is paying for the time.
Given the same people and one queue, the queue wins every day, because the queue is visible and the prevented incident is not. Organizations that sustain proactive analysis do one specific thing: they protect the capacity, whether that is a named analyst, a fixed share of a team’s week, or a standing review that cannot be cancelled for operational reasons.
The raw material is already in the building. Incident trend reports, events raised through monitoring and event management that never became incidents, capacity data, and service reviews run under service level management all point at candidates. Major incident reviews are the richest source of all, on one condition: the actions they generate have to be tracked to closure.
A review that produces recommendations nobody owns has cost a room full of expensive people an afternoon and changed nothing.
Who owns problem management, and which practices does it depend on?
Accountability normally sits with a problem manager or practice owner, but almost all of the value is realized by another practice, which makes ownership and handoff the same conversation.
Who does what in the practice?
- Problem manager or practice owner Owns the practice, the prioritization rules and the known error register
- Problem coordinator or analyst Runs individual investigations and keeps the records current
- Technical specialists Supply diagnostic depth for the components and services they know
- Service owner Decides whether a residual risk is acceptable for their service
- Change authority Authorizes the changes that carry permanent fixes
- Service desk Links incidents to existing problems and applies published workarounds
In smaller IT organizations one service manager holds most of these roles at once. That works, with a single condition: whoever investigates cannot also be the person the queue escalates to, or the investigation will not happen.
Which ITIL 4 practices does problem management hand off to?
Incident management supplies the symptoms and consumes the output, since every published workaround is capacity handed back to first line. Change enablement carries the permanent fixes, and a problem that never reaches a change request has been understood rather than resolved. Knowledge management keeps known errors findable.
Service configuration management maintains the configuration management database (CMDB) that makes dependency and impact analysis possible; without it, root cause analysis degenerates into interviewing whoever was on shift. Service level management decides which problems matter by making the business consequence of a recurring fault visible in service review, and measurement and reporting is what keeps availability management honest about repeat causes rather than aggregate uptime.
Which KPIs prove that causes are actually being removed?
The ones that count recurrence rather than activity.
Problem records raised is the metric most often reported and the least informative: a practice that opens forty records a month and closes none looks busy in exactly the same way as one that is working.
- Repeat incident rate The share of incidents matching an existing problem or known error, the clearest evidence that causes are being removed rather than managed
- Incidents resolved with a published workaround Shows whether the known error database is reaching first line or sitting in an archive
- Time to workaround How long users wait for relief, which usually matters more to them than time to permanent fix
- Problem backlog age The share of open problems past their review threshold, which exposes a register turning into a graveyard
- MTRS for recurring incident classes Mean Time to Restore Service is the customer-facing measure, distinct from Mean Time to Repair (MTTR), which covers component-level repair
- Outcome of problem-driven changes Fixes that fail on release point at analysis that stopped one level too early
Two of these carry warnings. Repeat incident rate can only be calculated if the service desk actually links incidents to problem records, so the number is a test of data discipline before it is a test of the practice.
An improving MTRS alongside a flat repeat rate is not progress. It means the organization has become efficient at handling a fault it has not removed, which is the second payment again, discounted slightly.
Fewer repeat tickets, and a record of why they stopped
Diagnostic depth comes from monitoring and observability tooling. What a service management platform contributes is the record: what recurred, what caused it, what was decided, and whether it came back.
Matrix42 is an enterprise service management, unified endpoint management and asset management platform, and Matrix42 Enterprise 25.4 has been assessed by an accredited Pink Elephant consultant as PinkVERIFY-certified across eleven ITSM processes, problem management among them.
In daily use that means problem management runs as a defined process next to incident, change, knowledge and configuration management rather than in a spreadsheet beside them. Matrix42 Enterprise applies incident clustering and trend analysis to surface common causes, links problem records to the related changes and assets, documents known errors for reuse at first line, and routes permanent fixes into change management or service requests.
Dashboards show which recurring issues are driving ticket volume and whether resolutions are holding. Underneath sits an integrated CMDB kept current through discovery and dependency mapping, so impact and root cause analysis start from recorded relationships rather than recollection, and Matrix42 Intelligence surfaces similar tickets and relevant knowledge articles while an agent is still working the call.
Infrastructure monitoring and application performance tools connect as integrations. Matrix42 does not replace them.
Key takeaways
- A service management practice Problem management is one of ITIL 4’s 17 service management practices, part of 34 management practices in total. Its purpose is to reduce the likelihood and impact of incidents by identifying their causes and managing workarounds and known errors.
- Two closure tests, not one An incident is closed when the user can work again; a problem is closed when the cause can no longer produce that incident. Running one test for both is how a service desk gets fast at fixing the same fault indefinitely.
- Workarounds are output, not excuses A known error with a published workaround delivers relief immediately, while the permanent fix competes for capacity like any other change. Review dates are what stop a workaround quietly becoming the service.
- Technique follows difficulty Five whys suits linear faults, Ishikawa and Kepner-Tregoe suit tangled ones, and Pareto and pain value analysis decide what deserves investigation at all. Blameless analysis is what keeps the evidence flowing.
- Recurrence is the proof Repeat incident rate, incidents resolved with a published workaround and problem backlog age show whether causes are being removed. Problem records raised shows only that somebody is typing.
What changes when a service desk starts closing causes instead of tickets?
The question it is accountable for changes, and everything else follows from that.
A service desk measured on speed alone will get faster at the same faults for as long as the funding lasts. That is not a failure of effort, it is what the measurement asked for. Problem management replaces “how quickly was service restored” with “can this happen again”, and no other ITIL 4 practice is accountable for asking it.
Keep the evidence in one place
What that usually requires is not a heavier process but three unglamorous things: incidents linked to problem records so recurrence is visible, protected time for investigation, and known errors that reach first line while they are still useful. See how the Matrix42 approach to service management keeps that evidence in one place instead of scattered across tickets and inboxes.
Explore the future of ITSM→FAQs
Problem management is the ITIL 4 practice that reduces the likelihood and impact of incidents by identifying their actual and potential causes and managing workarounds and known errors. It investigates why incidents happen instead of restoring service, and its output is a known error with a workaround, a permanent fix delivered through change enablement, or a residual risk that has been formally accepted.
Incident management restores normal service as quickly as possible and is measured on speed of restoration. Problem management investigates the underlying cause so the incident cannot recur, and is measured on whether recurrence falls. The closure test differs: an incident is closed when the user can work again, while a problem is closed when the cause can no longer produce that incident.
Problem management is a service management practice. ITIL 4 groups its 34 management practices into 14 general management practices, 17 service management practices and 3 technical management practices. Problem management sits in the service management group, alongside incident management, change enablement, knowledge management and service configuration management.
The three phases are problem identification, problem control and error control. Problem identification finds the faults worth investigating, drawing on incident trends, event data, supplier advisories and test results. Problem control analyzes and prioritizes the problem and produces a known error record. Error control manages known errors over time, delivering permanent fixes through change enablement or formally accepting the residual risk.
A known error is a problem that has been analyzed but not yet resolved. Once the cause is understood, the record is reclassified as a known error and usually carries a documented workaround. Those records are held in a known error database, or KEDB, so the service desk can apply the workaround immediately rather than escalating the same issue repeatedly. Retrieval speed is what makes the database useful.
Yes. ITIL 4 treats managing workarounds as part of the purpose of the practice, not as a failure to fix. A documented workaround reduces impact for users straight away, while the permanent fix competes for capacity like any other change. The risk is leaving a known error open indefinitely, so workarounds should carry a review date and a named owner for the residual risk.
ITIL 4 does not mandate a single method. Commonly used techniques include five whys for simple linear faults, Ishikawa or fishbone diagrams for problems with many candidate causes, Kepner-Tregoe problem analysis for complex faults, Pareto analysis for prioritization, fault tree analysis for systems with redundancy, and pain value analysis for scoring real business impact. The difficulty of the fault should decide which one is used.
Reactive problem management investigates faults that have already caused incidents. Proactive problem management looks for causes before an incident occurs, using incident trends, monitoring data, supplier advisories, capacity patterns and near misses. The analysis method is the same and only the trigger differs, which is why proactive work depends on protected capacity: given one shared queue, operational work displaces prevention every time.
The most useful measures are repeat incident rate, the share of incidents resolved with a published workaround, time to workaround and problem backlog age. Mean Time to Restore Service (MTRS) for recurring incident classes shows the customer-facing effect, distinct from Mean Time to Repair (MTTR) at component level, and the outcome of problem-driven changes shows whether the analysis went deep enough. Counting problem records raised measures activity rather than effect.
Problem management is a standard module in most enterprise IT service management platforms, and the practical test is whether it links incidents, problems, changes and configuration items in a single data model rather than across separate tools. Pink Elephant's PinkVERIFY certification is one independent indicator of process coverage: Matrix42 Enterprise 25.4 is certified across eleven ITSM processes, problem management among them. Diagnostic depth still comes from monitoring and observability tooling, which connects through integrations.
Related Articles
What is IT Service Management (ITSM)?
IT Service Management (ITSM) is a structured approach that organizations use to design, deliver, manage, and continually improve IT services to align closely with business goals.
The ITSM Buyer's Guide: How to choose IT Service Management software for your business
Your ITSM vendor choice shapes your IT operations for years. It affects how cost-effectively you manage daily service delivery, so compare your options carefully.
NIS2 and DORA compliance guide: Securing European businesses through automated IT governance
European businesses must balance technological innovation with strict regulatory compliance. The EU has introduced NIS2 (Network and Information Systems Directive) and DORA (Digital Operational Resilience Act) to enhance cybersecurity and operational resilience across sectors critical to the economy.
How AI transforms Service Management: A European guide to responsible implementation
AI in service management refers to artificial intelligence technologies that automate, augment, and predict IT service management operations. These technologies range from AI assistants that help agents find information faster, to autonomous AI agents that resolve issues without human intervention, to proactive AI that prevents incidents before they occur.
Sources
- 1 AXELOS / PeopleCert, “Problem management: ITIL 4 practice guide,” 2020.axelos.com/resource-hub/practice/problem-management-itil-4-practice-guide
- 2 itSM.tools, “ITIL 4 Management Practices Explained: Full List and Purposes,” 2026.itsm.tools/34-itil-4-management-practices/
- 3 Beyond20, “An Overview of the Problem Management Practice in ITIL 4,” 2024.beyond20.com/blog/an-overview-of-the-itil-4-problem-management-practice/
- 4 IT Process Wiki (IT Process Maps), “Problem Management,” 2024.wiki.en.it-processmaps.com/index.php/Problem_Management
- 5 New Relic, “New Relic Study Reveals Businesses Face an Annual Median Cost of $76 Million from High-Impact IT Outages,” 2025.newrelic.com/press-release/20250917
- 6 Uptime Institute, “Uptime Announces Annual Outage Analysis Report 2025,” 2025.uptimeinstitute.com/about-ui/press-releases/uptime-announces-annual-outage-analysis-report-2025
- 7 Uptime Intelligence, “Annual outage analysis 2025,” 2025.intelligence.uptimeinstitute.com/resource/annual-outage-analysis-2025
- 8 ManageEngine, “ITIL problem management techniques,” 2024.manageengine.com/products/service-desk/itsm/problem-management-techniques.html
- 9 Google, “Postmortem Culture: Learning from Failure,” Site Reliability Engineering, 2017.sre.google/sre-book/postmortem-culture/