Does every incident get its own problem record?

No — problem management typically engages only when an incident is high-impact, recurring, or its cause is unclear. Low-impact, one-off incidents with an obvious, already-understood cause usually don't warrant a separate root-cause investigation.

What is a "known error" exactly?

A known error is a problem that has a documented root cause and a documented workaround, but does not yet have a permanent fix implemented. It lets the service desk resolve future occurrences quickly using the documented workaround, without duplicating the root-cause investigation each time.

Who owns problem management versus incident management in an organization?

They are often staffed by overlapping but distinct teams — incident management is commonly owned by a service desk or NOC team optimized for fast response, while problem management is often owned by senior engineers, SREs, or a dedicated problem manager role with the time and authority to conduct a multi-day root-cause investigation.

Is a permanent fix from problem management deployed through the same process as an incident workaround?

No — a permanent fix normally must go through formal change management (risk assessment, approval, scheduled deployment window), since it modifies the production system structurally, whereas an incident workaround is applied immediately under incident management's own authority specifically because it does not make a lasting structural change.

← Engineering Management, Business & Professional Skills Studio

Concept Explainer · ITIL 4 Service Management

Incident Management vs Problem Management

Restoring service fast and finding out why it broke are both necessary — and ITIL 4 deliberately keeps them as two different practices with two different clocks.

On a live outage, the instinct to fix the root cause immediately is strong, and it's exactly the instinct ITIL 4 asks teams to resist. Incident management exists to restore normal service operation as quickly as possible, minimizing business impact — speed is the entire objective, even if the fix is a workaround that doesn't touch the underlying cause. Problem management exists to identify, document, and eliminate the root causes of incidents (and to reduce the likelihood and impact of future ones) — thoroughness is the objective, even if it takes far longer than any single incident could tolerate. Conflating the two either slows down incident response chasing root cause under pressure, or lets recurring root causes go uninvestigated because each recurrence gets treated as "just another incident" to work around again.