Process family
IT service management process: incident, change and release templates
The IT service management family: incident management, ITIL change management and software release as one chain, with the help desk, severity classification, bug triage, deployment, patch and vulnerability templates that feed work into it.
IT service management is the run side of IT. A disruption is logged and the service restored, the permanent fix is raised as a request for change, and an authorized change reaches production through a release. The three templates in the sequence are those handoffs; the seven around them are the queues and cycles that feed work into it: help desk, severity, bugs, deployment, patches, vulnerabilities and the SOC 2 change record.
An incident arrives as a user contact or an alert. The help desk logs it, separates it from a service request, fixes what it can at first line and passes the rest to incident management: set priority, open the major incident bridge if it is one, diagnose against the SLA target, restore service, close when the user confirms. If the root cause is still unknown at closure, the last step raises a problem record. The permanent fix is raised as an RFC and enters change management as standard, normal or emergency: impact assessment, a rollback plan, the CAB or the ECAB, the change calendar, a post-implementation review.
When the change is software, the release process takes the build from scope freeze through the automated test gate, staging and UAT to the go/no-go, the release window, smoke tests and the soak period, with rollback and hotfix branches. The deployment template covers the mechanics that approval assumes: quality gate, registry promotion, staging checks, blue-green or canary, and a rollback when the error budget is breached. Bug triage is the defect intake behind both: reproduction, duplicate check, severity and priority, code review and QA verification, and a production-down defect raises an incident rather than waiting on the backlog.
The usual failures sit at the seams. Priority argued case by case: the severity classification tree fixes P1 to P4 from four questions, unavailable or degraded, how many users or sites, critical function or revenue blocked, data or safety exposure, so the same evidence gives the same level. Fixes applied with no record: the SOC 2 CC8.1 change workflow is the same RFC-to-review chart with an approval recorded at each gate; patch management makes the advisory routine, emergency or monthly, regression test, authorized window, pilot ring first, rescan; vulnerability management is the other intake, authenticated scans, CVSS scoring, SLA bands, rescan before closure, overdue findings escalated.
One step is missing: there is no ITIL problem management template yet. Both the incident template and the help desk end with “Raise a problem record”, and nothing here receives it, so the route from a recurring incident to a known error is not drawn; the closest is root cause analysis in the quality family, which hands into CAPA, not a change. A security alert runs the same log, classify and escalate shape with containment and notification in place of restore and close: that is Security incident response, and the severity tree serves both. The change discipline here is the IT member of the wider Change control family, beside engineering, laboratory and SOP change.
The sequence
Step 1: Incident management process flowchart
A cross-functional incident management process flowchart covering logging, prioritisation, major incident escalation, SLA breach, resolution and closure.
Step 2: Change management process flowchart (ITIL)
An ITIL change management process flowchart covering RFC intake, standard, normal and emergency triage, CAB approval, scheduling, rollout and rollback.
Step 3: Software release process flowchart
A software release process flowchart covering scope freeze, the automated test gate, staging and UAT, go/no-go approval, deployment, rollback and hotfixes.
Also part of this family
- Incident severity classification flowchart — An incident severity classification flowchart: a decision tree taking availability, scope, business impact and exposure tests through to P1, P2, P3 or P4.
- IT help desk process flowchart (incidents and requests) — IT help desk process flowchart: one queue for incidents and service requests, with triage, priority, first-line fix, tier 2 escalation, fulfilment and closure.
- Bug triage process flowchart — Bug triage process flowchart: defect intake, reproduction, duplicate check, severity and priority, escalation, fix, code review, QA verification and release.
- Software deployment process flowchart: build to production — A software deployment process flowchart: build and version the artefact, quality gate, registry promotion, staging checks, canary rollout, automatic rollback.
- Patch management process flowchart (test, approve, deploy in rings) — Patch management flowchart template: advisory intake and applicability, emergency or routine triage, regression testing, change authorisation, ring rollout, rollback, rescan verification and risk exceptions.
- Vulnerability management process flowchart (scan to verified closure) — Vulnerability management flowchart template: scan scope and coverage, authenticated scans, triage and false positives, CVSS and exploit rating, SLA bands, rescan verification, exceptions and overdue escalation.
- IT change management workflow (SOC 2 CC8.1) — A SOC 2-ready IT change management workflow: change request, impact assessment, approval, testing, deployment, post-implementation review, with approval signatures captured per gate.
Related guides
- How to create a change control process — How to design a change control process: define your change categories, keep the pre-approved list short, require a rollback plan, and draw the emergency route rather than pretending it does not exist.
- How to create a decision flowchart — How to create a decision flowchart: write each decision as a question, make the exits exhaustive and exclusive, state the criteria, and give every outcome an ending. With a live bug-triage example.
- How to create an SOP flowchart — How to create an SOP flowchart: one procedure per chart, numbered steps, decision points with stated criteria, and an approved version under change control. With a worked incident-response example.
- How to create an incident management process — How to design an incident management process where severity sizes everything downstream: classify before diagnosing, draw re-classification as a route, and hand the cause to a separate record.