Change Management

The Change Management module governs the lifecycle of changes to your organization’s systems, configurations, and operational environment. Change requests, configuration baselines, releases, system acceptance reviews, environment-separation posture: each is one record type capturing a piece of the controlled-change discipline.

This module is not your ITSM ticket system. It’s the governance layer above the systems that actually execute changes. It captures the requested change, the approval, the baseline at a moment in time, the release that delivers it, and the acceptance after delivery — with audit-grade traceability.

When you would reach for this

You set up change management when:

A framework or regulator requires controlled change with approval, testing, and rollback discipline.
Production systems have a defined change advisory process and you want the process recorded inside governance, not just in tickets.
Configuration baselines need to be captured at deliberate moments (post-deployment, pre-audit, pre-major-change) and compared over time.
Releases need to be tracked from planning through deployment to acceptance.
System acceptance reviews (formal acceptance of a new or significantly-changed system) need an audit trail.
Environment separation (development, test, staging, production) needs governance posture.

You don’t reach for this for the actual execution of a change (deployment, configuration, build pipelines). Those live in the engineering systems. Change Management is the governance of the change, not the execution.

What lives in change management

Five record types:

Change request is one proposed change. It carries:

A title and a stable key.
A change kind (standard, normal, emergency, pre-approved, etc.; free text).
A subject (what’s being changed: a system, a control, a process, a configuration).
The risk and impact assessment.
An owner and approver routing.
A status walking through proposed, under-review, approved, scheduled, in-progress, complete, verified, closed, cancelled, rolled-back.

Configuration baseline captures the configuration of a subject at a point in time. It carries the subject, a baseline snapshot, the moment captured, and a baseline kind (post-deployment, pre-audit, scheduled).

Release is a packaged deployment of one or more changes. It carries scope, schedule, source, release notes, deployment posture.

System acceptance is the formal acceptance of a new or substantially-changed system into operational service. It captures the acceptance criteria, the test results, the residual risks, and the accepting authority.

Environment separation review captures the posture of an environment (dev, test, staging, production) at a review point: data isolation, access posture, configuration drift between environments.

A worked example: a passenger rail operator governs changes to its train control and signalling

A passenger rail operator runs train control and signalling systems on safety-critical operational technology. Any change to these systems is subject to a rigorous governed process: assessment, approval, testing, scheduled implementation, post-implementation verification. The head of operations engineering, Margit, sets up Change Management like this.

Step 1: change request lifecycle. Each proposed change is registered:

A signal-timing adjustment on a corridor: change kind standard, low risk, owner the engineer-on-watch.
A firmware upgrade to the central control system: change kind normal, high risk, owner the control systems lead, requires multi-party approval including independent safety engineer.
An emergency override during an incident: change kind emergency, captured after the fact with full incident documentation.

Each change request has a risk and impact assessment, approval routing, and walks the status lifecycle.

Step 2: configuration baselines. Before and after every normal or major change, configuration baselines are captured for the affected systems. The baseline snapshot is the source of truth for what configuration was in place at that moment, regardless of any subsequent drift or change.

Step 3: releases. Major changes are packaged as releases. A quarterly central-system patch bundle becomes one release containing many change requests. The release record carries the bundled scope, the deployment window, the rollback plan, and the post-deployment verification plan.

Step 4: system acceptance. When a new platform is brought into service (say, a new station-management subsystem), it goes through formal system acceptance: defined acceptance criteria, documented test results, residual-risk capture, accepting authority sign-off. The acceptance record is the audit-grade evidence that the system was deemed fit for service.

Step 5: environment separation reviews. Quarterly, the team reviews the separation between development, test, simulation, and production environments. Each review captures: data isolation posture, access control posture, drift between environments, any cross-environment dependencies. Findings flow into the main findings register.

Step 6: link to the rest of the governance program. Through Controls, the controls for change discipline reference the change records. Through Findings, failed verification or rollback events become findings. Through Audit Packages, an audit covering the change discipline can assemble the full register of change requests, baselines, releases, and acceptances.

After a year:

Every change to a regulated system has a governed record with approver, schedule, verification, and (if applicable) rollback.
Configuration baselines provide point-in-time fidelity for any compliance question.
Releases bundle the work cleanly for major deployments.
An auditor reviewing the safety case can be shown the full chain from change request through acceptance.

Change kinds

Kind	Meaning
`standard`	A pre-defined, low-risk, repeatable change. Typically pre-approved.
`normal`	A standard reviewed change requiring approval.
`emergency`	A change required to address an active incident; approval may be retrospective.
`pre-approved`	A change in a category that has standing approval.
`regulated`	A change subject to additional regulatory steps.

Kind is free text; use what your organization uses.

What you’ll see in the product

Change Management lives under Governance → Change Management in the workspace.

Five top-level tabs: Change Requests, Configuration Baselines, Releases, System Acceptances, Environment Separation Reviews.

Inside a change request, you see the full record, approver state, scheduled window, linked baseline before/after, linked release (if applicable), verification status, activity history.

Inside a release, you see the bundled change requests, scope, deployment plan, post-deployment verification status.

Inside a system acceptance, you see the acceptance criteria, test results, residual risks, accepting authority.

Inside an environment separation review, you see the environment pair under review, posture snapshot, drift indicators, findings raised.

Every change is captured in the workspace Audit Log.

Common workflows

Registering a change request

Change Management → Change Requests → New. Pick the change kind, capture the subject and the risk assessment.
Route for approval.
Capture pre-change baseline if applicable.
Schedule the implementation.
After implementation, capture post-change baseline and verification result.
Close with status verified or rolled-back.

Packaging a release

Releases → New. Pick the scope (which change requests are included).
Capture the schedule and rollback plan.
After deployment, capture the verification result.
Close.

Conducting a system acceptance

System Acceptances → New. Pick the system being accepted.
Define the acceptance criteria.
Capture test results against each criterion.
Document residual risks.
Route to the accepting authority for sign-off.

Reviewing environment separation

Environment Separation Reviews → New. Pick the environment pair (e.g., production vs staging).
Capture the current posture: data isolation, access control, configuration drift.
Raise findings for any gaps.
Sign off.

Looking for the API?

See Change Management API reference for the v1 REST endpoints to read change requests, baselines, releases, and acceptances from an external system.

Controls - change discipline controls reference these records.
Findings - failed change verification surfaces here.
Audit Packages - change records bundle into audit packages.
Assets - changes typically target asset records.
Secure Development - secure-development gates reference change records.
Vulnerability Management - patches are typically delivered as change requests.