Alignment is not certification
ISO/IEC 20000-1:2018 is a requirements standard for an organisation's service management system (SMS). ISO describes it as covering the planning, design, transition, delivery, monitoring, review and improvement of services. The standard was confirmed as current in 2023, and Amendment 1:2024 — Climate action changes applies to it. See the official ISO/IEC 20000-1:2018 page and the official Amendment 1:2024 page.
This article is an alignment appraisal of Orbit's product evidence hooks. It is not a statement that Orbit, RME Solutions, or any client's deployment is certified or conforms to ISO/IEC 20000-1. Certification or other conformity assessment applies to a defined organisational SMS scope and requires competent independent assessment against the applicable standard and evidence. Orbit can help a client operate and retain evidence for that SMS; it cannot supply the client's policy, leadership, competence, service commitments, risk decisions, operating discipline, or audit conclusions.
The amendment adds climate-action context to management-system consideration. Orbit does not determine a client's climate risks, interested-party needs, service impacts, or applicable objectives. Those are client SMS decisions that should be reflected in the client's context, planning and review evidence where relevant.
Appraisal at a glance
Orbit is strongest as a structured record and workflow surface around a service desk: a declarative service catalogue, typed request forms, ticket and change records, approval status, comments, attachments, notification hooks, activity and release evidence, and SharePoint-native version history. These are evidence hooks, not a complete SMS. The client still owns the service portfolio and scope, service owners, targets, calendars, staffing, supplier controls, continuity arrangements, measurement method, audit programme and management review.
Clauses 4–10: management-system alignment
| ISO/IEC 20000-1 theme | Orbit evidence hooks | Client SMS responsibility and boundary |
|---|---|---|
| 4 — Context and scope | Service catalogue and request categories give a practical view of services exposed through Orbit. The repository documents the product boundary, provider seams and data model in docs/ARCHITECTURE.md and docs/data-model.md. | Define the SMS scope, services, organisational context, interested parties, dependencies and exclusions. Consider relevant climate-change issues under Amendment 1:2024. Orbit does not decide what is in scope or prove that the scope is complete. |
| 5 — Leadership | Roles and assignment concepts appear in ticket, approval and catalogue workflows; release controls and deployment documentation provide product-development evidence. | Top management must establish direction, policy, accountability, service objectives and resources. A named service owner or an approval field is not proof of leadership commitment, governance effectiveness or an SMS policy. |
| 6 — Planning | Tickets and changes can capture Impact, Urgency, RiskLevel, ChangeType, scheduled dates and backout-plan information where the configured record exposes those fields. | Identify and treat SMS/service risks and opportunities, set measurable service-management objectives, and plan how objectives will be achieved. Orbit does not calculate risk, derive priority reliably, maintain a risk register, or decide climate-related actions. |
| 7 — Support | SharePoint-backed records, catalogue/form definitions, comments, attachments, notifications, role/visibility configuration and native version history can support documented information, communication and operational competence evidence. | Provide competent people, awareness, controlled documented information, communication arrangements and resources. The client controls access, retention, training, records policy and the authoritative SMS documentation. UI role guards are not a substitute for tenant permissions or organisational controls. |
| 8 — Operation | The operational evidence hooks below cover catalogue intake, typed records, approvals, assignment, fulfilment, change records, resolution data, activity/audit views and release history. | Plan and control the service lifecycle and the client's operating processes. The client must define and execute service commitments, acceptance criteria, escalation, supplier oversight, continuity, availability, security, testing, and service reporting. Existing fields do not mean the corresponding process is effective or automated. |
| 9 — Performance evaluation | Activity/audit views, ticket ageing, service-catalogue records, release audit data and portal-usage telemetry can provide raw inputs for reporting. docs/POWERBI-DASHBOARD.md describes reporting direction. | Establish what is measured, how it is calculated, data quality and frequency, who reviews results, internal-audit criteria/programme, and management-review inputs and outputs. Orbit does not provide a complete measurement system, audit programme, independent audit, or management-review record. |
| 10 — Improvement | Problem-type records have structured root-cause/workaround areas; ticket comments, activity history, release audit and CI quality gates can preserve improvement inputs and product-release evidence. | Control nonconformities, corrective action, continual improvement, lessons learned and benefits. Orbit does not ensure that recurring incidents become problems, that corrective actions are effective, or that the client runs a continual-improvement governance loop. |
Clause 8 operational requirements relevant to Orbit
The following is a practical product-to-SMS view of the operational themes. It is deliberately not a reproduction of the standard's text or a claim that a field alone satisfies a requirement.
| Operational theme | Orbit product evidence hooks today | Client-owned operating evidence / current limitation |
|---|---|---|
| Service portfolio and catalogue | Configurable catalogue entries and forms are defined in instances/<id>/catalogue.json and instances/<id>/forms/; catalogue reads and dispatch are implemented in src/providers/sharepoint/catalogue.ts. Ticket categories and request types provide a structured intake path. | Maintain the authoritative portfolio, service owners, lifecycle states, user eligibility, costs, risks, dependencies and review cadence. Orbit's catalogue is not automatically a complete portfolio or a portfolio-governance process. |
| Relationship and agreement management | Requestor, assignee, watcher, approval and parent/lead-ticket relationships can be recorded; approval workflows and notifications provide interaction evidence. See docs/APPROVAL-WORKFLOWS.md. | Define customer and provider relationships, service requirements, agreements, targets, responsibilities, escalation and communication. Orbit does not negotiate, approve or continuously assure agreements, and SLATarget is only a per-record date/time hook. |
| Supply, demand and capacity | Ticket volumes, categories, ageing, closure flow and demand-driver reporting can support management inspection; assets include a free-text Supplier hook. | Forecast demand, determine capacity, resource people and technology, and manage suppliers and service dependencies. Orbit does not perform capacity planning, enforce supplier evaluation, or establish supplier agreements and exit plans. |
| Design, build and transition | Change records can distinguish Standard, Normal and Emergency, capture risk/scheduling/backout information where configured, and connect operational work to release evidence. docs/RELEASE-WORKFLOW.md describes controlled product release activities. | Define service design criteria, transition plans, testing, acceptance, knowledge transfer, rollback, ownership and post-transition review. Orbit has no claim of automated service validation or a differentiated change-route workflow today. |
| Resolution and fulfilment | Typed Incident, Request, Change and Problem records have statuses, priorities, assignment, comments, resolution dates and catalogue-driven forms/approval flags. | Define triage, escalation, fulfilment groups, workaround and resolution quality, customer communication and closure criteria. Incident-to-Problem linkage and known-error publication are not enforced. |
| Service assurance | Ticket ageing and SLATarget display, activity/audit views and telemetry can be used as inputs to service reporting. | Define service measures, reporting periods, calendars, exclusions, breach ownership, review and corrective action. Orbit does not currently detect SLA breaches or escalate them automatically. |
| Continuity and availability | Orbit can retain operational records and configuration evidence in the client's SharePoint/tenant environment; docs/ARCHITECTURE.md identifies continuity and backup as deployment concerns. | Establish availability targets, continuity and recovery plans, dependencies, backups, tests, invocation authority and lessons learned. Orbit does not provide a continuity plan, availability monitoring, recovery objective management or tested recovery capability. |
| Information security in service operation | Role/visibility configuration, SharePoint permissions, input sanitisation, attachment checks, audit/activity views and documented security boundaries provide supporting evidence hooks. See docs/ZERO-TRUST-ARCHITECTURE.md and docs/security/sharepoint-item-authorization.md. | Operate the client's information-security controls, access reviews, incident response, retention, vulnerability/DLP controls and supplier assurance. Orbit's browser/UI guards and attachment checks are not, by themselves, a complete security management system or conformity evidence. |
Current gaps and management implications
These are material gaps for an ISO/IEC 20000-1 appraisal. They are stated as current product limitations or client responsibilities, not as a promise of future automation:
- SLA breach detection:
SLATargetcan be stored and displayed, but Orbit does not currently detect breach, pause/resume service clocks, or escalate a breach. The client needs a defined calculation, calendar and review/control path. - Impact/urgency priority derivation:
ImpactandUrgencyexist, but are not consistently collected or used to derivePriority. A client must define its matrix and operating rule; this document does not invent a schema field or claim an automation that is not present. - Incident–Problem linkage: Problem records can hold root cause and workaround information, but the relationship from the incidents explained by a problem and the known-error publication process are not enforced.
- Change-route differentiation:
ChangeTypehas Standard, Normal and Emergency values, but Orbit does not currently provide distinct approval and control routes for those types. - Continuity and availability: No Orbit feature by itself supplies tested continuity/recovery arrangements, availability monitoring, or evidence that agreed service levels are achievable.
- Supplier governance: A supplier value can appear on asset/procurement records and provider dependencies are documented, but supplier selection, evaluation, agreements, performance review, risk treatment and exit planning remain client-owned.
- Measurement and reporting: Telemetry and activity/audit data are inputs, not a complete measurement framework. Definitions, baselines, targets, data quality, reporting, review and action ownership remain to be established.
- Audit and management review: Orbit can surface operational history and release evidence, but it does not provide an independent internal-audit programme, auditor independence, a complete management-review agenda/minute record, or evidence that findings are closed effectively.
Evidence use and assurance posture
For a client assessment, treat Orbit records and repository documents as sampled supporting evidence: catalogue and form definitions, ticket/change/problem records, approval and comment history, activity/audit views, release audit data, tenant configuration and operating reports. Validate each item against the client's SMS scope, documented procedure, agreed service requirements and actual operation. Do not treat a screenshot, field, configuration file or product workflow as proof of conformity in isolation.
Internal Orbit references
docs/ARCHITECTURE.md— product boundaries, data and deployment responsibilities.docs/data-model.md— documented ticket, asset, catalogue and approval fields; it also records fields that are not consistently fetched or operationalised.docs/standards/itil-4-alignment.md— related service management practice appraisal and the same priority, linkage, change-route and SLA gaps.docs/whitelabel-plan/02-ISO27001-ITIL-ALIGNMENT.md— detailed security/ITIL evidence and gap register.docs/POWERBI-DASHBOARD.md,docs/RELEASE-WORKFLOW.mdanddocs/APPROVAL-WORKFLOWS.md— reporting, release and approval evidence context.