Alignment is not certification
ITIL certification is held by individuals who pass PeopleCert examinations, not by software. This document describes how Orbit's data model and workflows map to ITIL 4 practice terminology and structure. It is not, and should not be read as, a claim that Orbit or RME Solutions is "ITIL certified." The accurate phrasing — and the one used throughout this document — is that Orbit "supports ITIL 4 practices."
Current edition — verified 2026-08-13
ITIL 4 (34 practices organised around a Service Value System, four dimensions, and seven guiding principles) remains fully valid and is the terminology this document, and docs/whitelabel-plan/02-ISO27001-ITIL-ALIGNMENT.md, is written against. PeopleCert — which has owned ITIL since acquiring it from Axelos in 2021 — launched ITIL Version 5 on 12 February 2026: Foundation is live, further modules are rolling out through 2026, and ITIL 4 continues to run in parallel during the transition. ITIL 5 adds AI-governance/responsible-AI guidance, an eight-activity lifecycle (was six), Complexity Thinking, and Industry 5.0 human-centricity. ITIL 4 is not deprecated — this document uses "ITIL 4" as the still-current, still-understood terminology, and names ITIL 5's existence here rather than silently going stale as the newer edition becomes more widely adopted.
What "enabled capability, not complete practice" means
Every practice below follows the same honest shape, carried directly from the full technical register: Orbit can provide forms, states, relationships, and evidence hooks for a practice. It cannot create the organisation's service ownership, staffing, governance, targets, or continual review by itself. A practice being listed as "supported" means the data model and workflow exist to run it — not that running it well is automatic.
| ITIL 4 practice | What Orbit provides | What remains the organisation's own responsibility |
|---|---|---|
| Incident management | A typed record with queueable status, priority, comments, assignment, resolution date, and notification hooks. | Triage criteria, escalation paths, major-incident roles, post-incident review. |
| Service request management | Catalogue-driven request types with typed forms, role-based visibility, approval flags, and attachments. | Entitlement rules, fulfilment ownership, standard turnaround targets. |
| Service catalogue management | Declarative, versionable catalogue and form definitions — adding a service is a configuration change, not a code change. | Catalogue governance, cost/content review, retirement of stale services. |
| Request fulfilment | Form-driven submit plans covering ticket, procurement, and lifecycle actions. | Fulfilment-group ownership, exception handling, requestor communication. |
| Change enablement | Change type, scheduled dates, risk level, backout plan, approval fields, and release-tagged deployment history. | Standard/normal/emergency approval paths, CAB where applicable, post-change review. |
| Service level management | A SLATarget date/time field and ticket ageing visibility. | Agreed targets, calendars, breach ownership and review cadence. |
| Problem management | Problem-type records with root cause, workaround, and workaround-availability fields. | Trend analysis, known-error publication, recurring-problem review. |
| Knowledge management | This plan's own subject — see docs/kb-plan/00-OVERVIEW.md. | Authorship/review ownership, publication approval, content expiry. |
| Service configuration and asset management | A structured asset record with device identifiers and affected-asset references. | CI ownership, dependency mapping, disposal evidence — not a full CMDB. |
| Monitoring and event management | Usage telemetry and activity/audit visibility. | Alerting, thresholds, on-call ownership, event correlation. |
| Information security management | Fail-closed configuration, leak gates, sanitised inputs, attachment policy, role-based UI guards. | Risk assessment, access review, incident response, a complete ISMS. |
| Supplier management | Provider seams make Microsoft 365/hosting/relay dependencies visible in the codebase. | A supplier register, assurance reviews, exit planning. |
| Continual improvement | CI quality gates, dependency-update cadence, and release audit provide improvement inputs. | A formal improvement backlog, benefits review, and learning loop. |
Known gaps — the honest headline items
- Impact and Urgency are not consistently used to derive Priority, despite both fields existing — ITIL 4 practice expects Priority to be a function of the two, not chosen independently.
- No enforced incident-to-problem linkage or known-error publication — Problem records capture root cause and workaround content, but nothing structurally connects a Problem back to the Incidents it explains.
- No differentiated Standard/Normal/Emergency approval workflow for changes, despite the
ChangeTypeclassification existing — every change currently follows the same approval shape regardless of type. - No service-level breach detection or escalation —
SLATargetexists as a field; measuring and acting on it is not automated.
None of these are proposed as new schema in this document — per this repository's standing rule, standards alignment alone does not justify adding a field, list, or table; a real, evidenced operational need does. See the full register (linked below) for each gap's phase and owner type.
See also
docs/whitelabel-plan/02-ISO27001-ITIL-ALIGNMENT.md— the full, file-level ITIL 4 practice register (13 practices, each with source-control- implemented / deployment-required / organisational-required / known-gap detail) this article summarises for a KB audience. Not superseded, not duplicated wholesale.docs/kb-plan/00-OVERVIEW.md— the plan that makes Knowledge management, specifically, a genuinely staff-editable practice rather than only an "enabled capability."docs/standards/iso-9001-alignment.md— where ITIL's change enablement and continual improvement practices overlap with ISO 9001's process-approach and continual-improvement clauses.