ITSM vs Incident Management

ITSM treats IT as a set of services delivered to users, with processes to design, transition, operate, and improve them. Frameworks such as ITIL describe practices including incident management, problem management, change enablement, service request management, service level management, configuration management, and IT asset management. ITSM is about how the whole operation fits together.

Incident management handles unplanned interruptions or degradations of a service. Its job is detection, logging, categorisation, prioritisation, response, communication, and restoration. Success is measured by time to acknowledge, time to restore, and how well stakeholders were kept informed. Finding the underlying cause is explicitly someone else's job.

When an incident reveals a recurring or unknown cause, problem management investigates and removes it. When the fix needs a change to production, change management assesses and schedules it. Knowledge management captures workarounds. Incident management is the front door; the other processes keep the same incident from coming back.

Small engineering teams often run incident management well with on-call, a ticket or channel per incident, and postmortems, without any formal ITSM programme. As organisations grow, especially with internal IT, compliance obligations, or many services, the other ITSM processes become necessary to avoid repeat incidents and uncontrolled change.

Full ITSM suites model services, configuration items, changes, requests, assets, and their relationships, which brings power and significant implementation effort. Incident-focused tools concentrate on intake, assignment, communication, timelines, and analytics. The right choice depends on which processes you actually run today, not which ones a framework lists.

Incident management metrics include mean time to acknowledge and restore, incident volume by severity, and customer impact. ITSM metrics span the whole service: change success rate, problem backlog, request fulfilment time, service level attainment, and the share of incidents caused by changes.

Buying a full ITSM suite to solve a slow incident response, treating every ticket as an incident, closing incidents without ever opening problems, and measuring incident teams on root-cause metrics they do not own. Each blurs responsibilities and slows restoration.

SubZero focuses on incident management: tickets, agent assignment, customer email threaded into the ticket, a public intake form, required root-cause codes on close, and response and resolution analytics. Root-cause codes are the bridge to problem management, so recurring causes are visible without a full ITSM implementation.

Most teams follow a similar path. First, on-call and a consistent way to log and assign incidents. Next, postmortems and cause codes. Then problem management for recurring causes and lightweight change control for risky deploys. Formal request, asset, and configuration management usually come later, when scale or compliance demands them. Adopting processes in that order keeps overhead proportional to value.

Most frameworks define a major incident process for high-impact events: a dedicated coordinator, a communication cadence, and executive updates. It is still incident management, just with more structure, and it should be rehearsed before it is needed.