Incident vs Problem vs Change: What the Difference Actually Means
Most teams adopting ITIL for the first time raise everything as an incident, because that is the button they know. It works until the same outage happens for the fourth time and nobody can point to what is being done about the cause. The distinction between these three records is not bureaucracy — each one answers a different question.
Incident: "service is broken, restore it"
An incident is an unplanned interruption or degradation. The goal is restoration, not understanding — if rebooting the service fixes it for the user, the incident is resolved even though nobody knows why it broke. Incidents carry SLA timers, because the person affected is waiting.
Examples: mail relay is down, a user cannot connect to VPN, the finance share is read-only.
Problem: "why does this keep happening?"
A problem is the underlying cause of one or more incidents. It exists on a different clock — nobody is sitting waiting for a problem record, so it should not carry the same response SLA. Its output is a root cause, and usually a known error with a documented workaround.
The signal you need one: you have resolved the same incident more than twice. Group them behind a problem record and the repeat stops being invisible.
Change: "we are going to alter something on purpose"
A change is planned work that alters the environment. The point is not paperwork — it is that someone other than the implementer agrees the risk is acceptable, and that there is a record of what was altered when something breaks two days later. Changes carry risk, an approver and a schedule, not a response SLA.
Examples: firewall rule modification, mail server version upgrade, switching an authentication provider.
How they connect in practice
- VPN drops for three users on Monday. Three incidents, each resolved by a reconnect.
- It happens again Wednesday. Someone raises a problem and links the incidents to it.
- Investigation finds a firmware bug. The problem gets a known error and a workaround, published to the knowledge base so the next incident is resolved in a minute.
- The fix — a firmware upgrade — is raised as a change, approved, scheduled for a weekend, and implemented.
- The problem closes. Incidents stop arriving.
The mistake worth avoiding
Do not put problems and changes on the same SLA clock as incidents. A team measured on "close problems within four hours" will simply stop raising them, and you lose the one record that was making repeat failures visible.
SupportCentral keeps incidents, problems and changes as separate records that link to each other, with SLA timers only where they belong. See how to set SLA targets that hold up.