Incident management versus problem management in ITIL

The correct answer: B. Problem management

✅ Why this answer

• Incident management: its aim is to restore service as quickly as possible, even with a temporary fix such as restarting the server. It succeeded at that three times.
• Problem management: its aim is to find the root cause of recurring incidents and remove it, so they do not happen again.

The same failure recurring is a clear sign of a problem that needs investigating.

❌ Why the other options are wrong

• (A): incident management did its job by restoring service, but it does not investigate the deeper cause.
• (C): release management plans the rollout of updates to the production environment, and may later be used to deploy the fix, but it does not investigate the cause.
• (D): the service catalog is a list of the services available to users; it has no role in investigating failures.

💡 Key concept

The rule: an incident is handled with speed, a problem with investigation. Success at the first does not mean the second is finished.

Until the cause is permanently fixed, the known error and its workaround are documented in the knowledge base, so the service desk can handle future incidents quickly. The permanent fix is then carried out through change management.

In the exam: words such as “recurring”, “for the third time” or “root cause” point to problem management, and words such as “restore service” or “as quickly as possible” point to incident management.

🔗 Related facts and questions

• Related ITIL terms: incident (an unplanned interruption or degradation of a service), problem (the cause of one or more incidents), known error (a problem whose cause is known and that has a documented workaround), service request (a routine request, not a failure), and change (adding, modifying or removing anything that could affect a service).
  Practice question: a user forgot their password and asks for a reset. Incident or service request? → Service request.
• The whole path: a recurring incident, then a problem record, then root cause analysis, then a known error with a workaround, then a change request for the permanent fix, then closing the problem once the incidents are confirmed to have stopped.
  Practice question: the cause turns out to be a memory leak on the server, fixed by an update from the vendor. Which process authorizes the update? → Change management.
• Root cause analysis (RCA) tools: asking “why?” five times (5 Whys), the fishbone (Ishikawa) diagram, and Pareto analysis to find the few causes behind most incidents.
• Two kinds of problem management: reactive, after incidents recur as here, and proactive, by analyzing incident trends and system logs before a failure happens.
• Setting priorities: an incident’s priority = impact × urgency. The service level agreement (SLA) sets the response and resolution time for each priority. An EHR login screen frozen for many users is a major incident, with its own escalation path.
• The perception gap in system outages: a related question in the full bank.
• Types of change and emergency change: "Types of change and emergency change" (in the full bank).
• COBIT and ITIL: "COBIT for governance and ITIL for service management" (in the full bank).