ITIL problem management finds and removes the root cause of incidents that keep coming back. Incident management restores service as fast as possible; problem management asks why the service broke, records a known error with a workaround so the service desk can respond quickly next time, and then removes the cause through a planned change so the same ticket stops returning. ITIL 4 splits this work into three phases: problem identification, problem control and error control.
What is ITIL problem management?
In ITIL, a problem is the cause, or potential cause, of one or more incidents. The purpose of the problem management practice is to reduce the likelihood and impact of incidents by identifying their actual and potential causes, and by managing workarounds and known errors.
Three terms do most of the work in this practice:
- Problem: the underlying cause of one or more incidents, whether or not you know what it is yet.
- Known error: a problem that has been analysed but not yet resolved. You know the cause, but the permanent fix is still pending.
- Workaround: a way to reduce or remove the impact of an incident or problem while the full fix is not available, such as restarting a service or rerouting traffic.
Why it matters: when a team only fights incidents, the same outage gets fixed five times by five different engineers. Each ticket closes on time, but capacity drains away and users lose patience. Problem management turns that repeated effort into one investigation, one documented workaround and one permanent fix.
ITIL 4 describes three phases:
- Problem identification: spotting and logging problems, usually from incident trends, major incidents, supplier notices or test teams.
- Problem control: analysing the problem, prioritising it by risk to services, and documenting workarounds and known errors.
- Error control: managing known errors, reassessing workarounds, and deciding whether a permanent fix is worth its cost and risk.
Problem management vs incident management vs change management
These three practices are often confused because they handle the same outage at different moments. Incident management gets users working again. Problem management finds out why it happened. Change management safely puts the permanent fix into production. A healthy ITSM process links all three records so nothing is lost between teams. For the incident side in detail, see our guide to the incident management process, and for the fix stage, our guide to IT change management.
| Incident management | Problem management | Change management | |
|---|---|---|---|
| Goal | Restore normal service quickly | Find and remove the root cause | Deliver changes without breaking service |
| Trigger | A user report or an alert | Repeat incidents, a major incident or a trend | A request for change (RFC), often raised from a problem |
| Timeframe | Minutes to hours | Days to weeks | Scheduled into a change window |
| Main output | Resolved incident | Root cause, known error, workaround | Implemented and reviewed change |
| Typical owner | Service desk and support groups | Problem manager | Change manager and change authority |
| Measured by | Response and resolution time against SLA | Repeat incident rate, time to root cause | Change success rate, changes causing incidents |
The problem management process, step by step
Most teams run problem management as eight steps. The table maps each step to the ITIL 4 phase it belongs to and the record it should leave behind, so you can audit whether a problem was handled properly.
Two rules keep the process honest. First, every problem record links to the incidents that triggered it, so you can measure whether the fix worked. Second, a problem is not closed when the root cause is found; it is closed when the change that removes the cause has been implemented and the related incidents have stopped.
| Step | What happens | ITIL 4 phase | Output |
|---|---|---|---|
| 1. Detect | Spot a problem from repeat incidents, a major incident, monitoring trends or a supplier notice | Problem identification | Candidate problem |
| 2. Log | Create a problem record with symptoms, affected services and configuration items, and linked incidents | Problem identification | Problem record |
| 3. Categorise and prioritise | Classify by service and category; prioritise by business impact, urgency and how often it recurs | Problem control | Priority and owner |
| 4. Investigate and diagnose | Run root cause analysis with the right technical teams and evidence | Problem control | Confirmed root cause |
| 5. Document workaround and known error | Record the cause and a tested workaround in the known error database | Problem control | Known error record |
| 6. Raise a change | Submit a request for change for the permanent fix, with risk and rollback details | Error control | RFC linked to the problem |
| 7. Resolve | Implement the fix through change management and watch for related incidents | Error control | Implemented change |
| 8. Review and close | Confirm incidents have stopped, capture lessons learned, update the KEDB and close | Error control | Closed problem, updated knowledge |
Reactive vs proactive problem management
Reactive problem management starts after something has gone wrong: a major incident, or the same incident showing up again and again. Most teams begin here because the evidence is already in the ticket queue.
Proactive problem management looks for weaknesses before they cause incidents. Typical sources are incident trend reports, monitoring data that shows a component degrading, vendor security bulletins, capacity reports and post implementation reviews from changes. It needs more maturity, because someone has to own the analysis when nothing is visibly broken.
Mature teams run both. A simple way to start proactive work is a monthly review of the top ten incident categories by volume: any category that keeps growing, or any single configuration item that appears in many tickets, becomes a candidate problem.
Roles and responsibilities
Problem management fails most often because nobody owns it. Name the roles even if one person covers more than one of them.
| Role | Responsibilities |
|---|---|
| Problem manager | Owns the process, sets priorities, makes sure every problem has an owner, chairs problem reviews and reports on KPIs |
| Service desk | Links related incidents, flags repeats, applies workarounds from the KEDB and feeds data into investigations |
| Technical and support teams | Run the root cause analysis, propose workarounds and design the permanent fix |
| Change manager and change authority | Assess and approve the RFC that carries the permanent fix, and schedule it safely |
| Service owner | Accepts the business risk when a known error will not be fixed straight away |
| Suppliers | Investigate and fix causes inside their products, under underpinning contracts |
Root cause analysis techniques
Choose the technique to match the problem. Simple, linear failures suit 5 Whys; problems with many possible contributors suit a fishbone diagram; a long list of recurring issues suits Pareto analysis.
5 Whys. Ask why the failure happened, then ask why again of each answer until you reach a cause you can act on. Example scenario: users lose access to the finance application every Monday morning. Why? The application server runs out of memory. Why? A weekend batch job leaves sessions open. Why? The job was changed last quarter and the cleanup step was removed. Why? The change had no test case for session handling. The root cause is a gap in change testing, not the server, so adding memory would only hide it.
Fishbone (Ishikawa) diagram. Draw the problem as the head of a fish and group possible causes on the bones, for example people, process, technology, suppliers, environment and data. It keeps a team from fixing on the first cause someone suggests.
Pareto analysis. Sort incident categories or causes by volume and fix the few that create most of the tickets first. It is the quickest way to choose which problems to open.
Fault tree analysis. Start from the failure and work downward through the combinations of events that could cause it. It suits complex infrastructure where several failures must line up before an outage happens.
Timeline analysis. Put every event, alert, change and ticket on one timeline around the failure. Many root causes become obvious once you see that a change went in ten minutes before the first alert.
Whatever the method, record the evidence in the problem record. A root cause that lives only in an engineer’s head will be rediscovered at the next outage.
The known error database (KEDB)
The known error database holds every known error with its symptoms, root cause, workaround and fix status. It is where problem management pays the service desk back: when an incident matches a known error, the agent applies the documented workaround in minutes instead of escalating.
A good known error record contains:
- Symptoms, written the way users and monitoring describe them, so agents can match incidents quickly
- The confirmed root cause
- A tested workaround with clear steps
- Affected services and configuration items
- Links to the problem, the related incidents and the RFC for the permanent fix
- Status, owner and a review date
KEDB best practices:
- Write workarounds for the person who will use them, usually a level 1 agent, not for the engineer who found them
- Publish known errors into the knowledge base the service desk already searches
- Review open known errors on a fixed schedule and retire them when the fix is in
- Archive rather than delete, so history is there when a similar problem appears
- Track how often each workaround is used; heavy use is a strong case for funding the permanent fix
Problem management KPIs to track
Measure outcomes, not activity. A team that closes many problems while repeat incidents keep rising is not doing problem management well. Set targets from your own baseline over the first quarter rather than copying industry numbers.
| KPI | What it tells you | How to measure |
|---|---|---|
| Repeat incident rate | Whether root causes are really being removed | Incidents matching an existing problem or known error, as a share of all incidents |
| Mean time to root cause | How quickly investigations reach a confirmed cause | Average time from problem logged to root cause recorded |
| Known errors with workarounds | How well the service desk is equipped | Share of open known errors that have a tested workaround |
| Problem backlog and age | Whether the team has capacity for the work | Open problems by priority and age band |
| Problems resolved by change | Whether investigations end in permanent fixes | Problems closed with a linked, successful change |
| Incidents avoided | The value of the practice to the business | Drop in incidents for a category or CI after the fix went in |
Problem management best practices
- Define what triggers a problem record. For example, every major incident, and any incident type that recurs a set number of times in a month on the same service.
- Link incidents to problems from day one. Without the link you cannot prove the fix worked.
- Separate the workaround from the fix. Publish the workaround fast, then take the time to fix the cause properly through change management.
- Prioritise by business impact. A minor issue that hits payroll every month can outrank a dramatic one that happened once.
- Hold a short, regular problem review. Fifteen minutes each week on new problems, stuck investigations and known errors waiting for a fix keeps the backlog moving.
- Use your configuration data. Knowing which configuration items, services and recent changes are involved shortens most investigations.
- Close the loop with knowledge management. Every root cause and workaround should end up somewhere the service desk will find it.
- Report KPIs to service owners. Problem management competes for engineering time, so show the incidents it removes.
Common challenges and how to fix them
Most problem management programmes stall for the same handful of reasons. Each has a practical fix.
| Challenge | What it looks like | Fix |
|---|---|---|
| No clear owner | Problems are opened and never progress | Name a problem manager and an owner for every problem record |
| Poor incident categorisation | Trends cannot be found because tickets are mislabelled | Simplify categories and make closure categories mandatory |
| Root cause stops at the symptom | “Server rebooted” recorded as the cause | Use 5 Whys or a fishbone and require evidence before closing |
| Fixes never reach production | Known errors stay open for months | Raise an RFC from every known error and review the queue with the change manager |
| Disconnected tools | Incidents, problems, changes and assets sit in different systems | Run all four on one ITSM platform with linked records |
Problem management software: what to look for
Spreadsheets can hold a short list of problems, but once you have more than a handful of services, you need problem management software that links records automatically. When you shortlist tools, check for:
- Creating a problem directly from an incident, and linking many incidents to one problem
- An ITIL aligned problem workflow with categories, priorities and escalation
- Space to record root cause analysis with evidence, ideally on a timeline
- Known error records with workarounds that agents can find from the incident screen
- Links to configuration items, so you can see the affected assets and their history
- Raising a change from the problem, and seeing the change status from the problem record
- Automatic capture of resolutions into the knowledge base
- Reports on problem backlog, age and repeat incidents
- Deployment options and data location that match your compliance needs
The table lists problem management capabilities as described on each vendor’s own product page, checked November 2026. It is a starting point for a shortlist, not a full comparison; confirm plan availability on each vendor’s pricing page.
| Tool | Problem management capabilities named on the vendor’s page |
|---|---|
| Infraon ITSM | ITIL compliant problem process, root cause analysis on a visual timeline of events, create problems from incidents and link other incidents, link to configuration items, known error records with workarounds, RCA generated after closure (Professional plan) |
| ServiceNow ITSM | Problem states from New through Root Cause Analysis to Closed, known errors and workarounds, relationships between problems, dashboards for problem managers |
| Freshservice | Root cause, symptoms and workaround fields, event timelines, known error marking, links to incidents, changes and releases |
| ManageEngine ServiceDesk Plus | Convert incidents to problems, link incidents and changes, mark known errors, save workarounds to the knowledge base, problem templates |
See how Infraon ITSM links incidents, problems, known errors and changes on one record. Explore problem management, or read how Eternis Fine Chemicals reports up to 75% higher agent productivity.
How Infraon ITSM supports problem management
Infraon ITSM runs incident, problem, change and release management on one platform, so the problem record, the incidents behind it and the change that fixes it stay linked. Problem management is included in the Infraon ITSM Professional plan at $57 per user per month, with Essential at $19 and Standard at $47 (USD, save 20% with yearly billing; see ITSM pricing).
What the problem module does:
- A predefined, ITIL compliant problem process with priorities, categories and rule based escalation with manual override
- Root cause analysis on a visual timeline of events, with an RCA generated after closure
- Create a problem from an incident and link other incidents to it
- Known error records whose workaround is visible in configuration item records, incident records, knowledge and service reports
- Pain value analysis with risk records, mitigation and risk assessment
- Tracking against tolerance breaches with notifications, and routing of problem records to support partners
- Resolutions captured automatically into the knowledge base, so agents see them on new incidents
The fix then moves into change management with CAB approval in the same platform. To see the affected configuration items and their history on every problem, connect Infraon Assets; application discovery and dependency mapping are in the Assets Professional plan ($524 per month for 1,000 assets and 10 users).
Deployment and compliance. Infraon ITSM is available as SaaS, or as the Enterprise edition on premise or hybrid, deployed in the country you need, with Arabic language support. Infraon holds ISO/IEC 27001:2022, ISO 20000-1:2018 and SOC 2 Type 2, and Infraon ITSM is PinkVERIFY verified for 12 processes and aligned with ITIL 4.
Proof from customers. Eternis Fine Chemicals, India’s largest exporter of aroma chemicals, runs Infraon ITSM and reports up to 75% higher agent productivity and up to 50% lower annual IT spend. Tatanet Services scaled its operations to manage 80,000+ nodes on Infraon ITSM with higher SLA compliance. Both case studies are in the Infraon case study library.
Problem management is in Infraon ITSM Professional at $57 per user per month. Start your 14 day free trial, book a demo or compare plans.
Final thoughts
Problem management is where an IT team stops paying for the same outage twice. Start small: define what triggers a problem, link incidents to problems, publish workarounds to the service desk and push every confirmed cause into a change. Then measure repeat incidents, not tickets closed. Once those habits are in place, a tool that keeps incidents, problems, changes and configuration items linked makes the practice easier to run at scale.
Frequently Asked Questions
What is problem management in ITIL?
Problem management is the ITIL practice that finds and manages the causes of incidents. It reduces the likelihood and impact of incidents by identifying actual and potential causes, documenting workarounds and known errors, and removing causes through planned changes.
What is the difference between incident and problem management?
Incident management restores service as quickly as possible. Problem management investigates why the incident happened and removes the cause so it does not recur. One problem can sit behind many incidents.
What is a known error in ITIL?
A known error is a problem that has been analysed but not yet resolved. Its root cause is understood and it usually has a documented workaround, stored in the known error database until a permanent fix is implemented.
What are the three phases of ITIL 4 problem management?
Problem identification (finding and logging problems), problem control (analysing them and documenting workarounds and known errors) and error control (managing known errors and deciding on permanent fixes).
Which root cause analysis technique should I use?
Use 5 Whys for simple, linear failures, a fishbone diagram when many factors could be involved, Pareto analysis to choose which recurring issues to tackle first, and fault tree or timeline analysis for complex infrastructure failures.
Which KPIs measure problem management?
The most useful are repeat incident rate, mean time to root cause, the share of known errors with workarounds, problem backlog and age, and the share of problems closed with a successful change.
Which Infraon plan includes problem management?
Problem management is part of the Infraon ITSM Professional plan at $57 per user per month (USD), which also includes change and release management. Every product also has an Enterprise plan with customisation options, priced on request.
