Change Management Policy

Change Management Policy — Trust Centre — Compass IoT

Our commitment

Uncontrolled change is one of the most common causes of production incidents. Every change to our platform goes through a defined process before it reaches production.

This policy applies to all changes to Compass IoT's production infrastructure, platform code, configuration, and data pipelines — regardless of how minor they appear. It applies to all employees, contractors, and vendors with the ability to make changes to production systems.

Scope

What counts as a change

Policy in place

A change is any modification to a production system, service, or configuration that could affect availability, security, data integrity, or customer-facing behaviour. This includes:

Deployments of new code, features, or bug fixes to the production environment.
Changes to infrastructure configuration — including cloud resources, networking, access controls, and secrets.
Database schema changes or data migrations.
Changes to third-party integrations, API connections, or data pipeline configuration.
Updates to security controls, firewall rules, or authentication configuration.
Dependency upgrades, including third-party libraries and platform components.

Classification

Change types

All changes are classified before they enter the approval process. The classification determines the level of review, testing, and approval required.

Standard Low risk

Pre-approved, routine changes that follow a documented and tested procedure. Low risk, well understood, and repeatable. No individual approval required beyond the standard process.

Examples: routine dependency updates, scheduled certificate renewals, documented configuration toggles.

Normal Moderate risk

Changes that require assessment, testing in staging, and peer review before production deployment. The majority of feature releases and infrastructure updates fall into this category.

Examples: new feature deployments, infrastructure scaling changes, database migrations, integration updates.

Emergency Expedited

Changes required immediately to resolve a production incident or critical security vulnerability. The standard review timeline is compressed, but documentation and post-change review are still required.

Examples: critical security patch, hotfix for active incident, data integrity remediation.

Process

How changes move through the process

Normal and Standard changes follow a five-stage process. Emergency changes compress stages two and three but are not exempt from documentation or post-change review.

Stage 01

Request and classification

Change request raised with a description of the change, its purpose, affected systems, and estimated risk.
Change classified as Standard, Normal, or Emergency.
Rollback plan documented — every change must have a defined path to revert if something goes wrong.
Dependencies and downstream impacts identified.

Stage 02

Review and approval

Normal changes require peer review by at least one engineer not involved in authoring the change.
Changes with significant security or data impact require review by engineering leadership.
No change is deployed to production without documented approval — verbal approval alone is not sufficient.
Emergency changes require expedited approval from an engineering lead or leadership team member.

Stage 03

Testing

All Normal changes are deployed and validated in the staging environment before production.
Automated test suites are run as part of the deployment pipeline — failures block production deployment.
Data migrations are tested against a copy of production data in staging wherever feasible.
Security-relevant changes are reviewed against known vulnerability patterns before deployment.

Stage 04

Deployment

Changes are deployed during defined deployment windows where possible, avoiding peak usage periods.
Production deployments are monitored in real time — the deploying engineer remains available for a defined observation period after release.
Automated monitoring alerts are active during and after deployment to detect anomalies.
Rollback is initiated immediately if a critical issue is detected post-deployment.

Stage 05

Post-change review

All changes are confirmed as successful or rolled back within the observation period.
Emergency changes are subject to a mandatory post-change review within two business days.
Any unexpected impacts identified during or after deployment are documented and investigated.
Change record is closed with outcome, any deviations from plan, and lessons noted.

Principles

How we approach change

Beyond the process, our change management is shaped by a set of operating principles that apply to every deployment regardless of size or urgency.

No direct production access. No engineer deploys changes to production directly from their local machine. All deployments go through the automated pipeline.
Every change is reversible by design. If a rollback plan cannot be documented, the change design needs to be revisited before it proceeds.
Separation of duties. The engineer who authors a change is not the same person who approves it for production.
Small and frequent over large and infrequent. We prefer incremental changes that are easier to test, review, and roll back over large batch releases.
All changes are logged. Every production change is recorded with its author, approver, timestamp, affected systems, and outcome.
Emergency does not mean undocumented. Speed is required — but bypassing documentation entirely is not acceptable even in an emergency.

Policy review

Policy ownership and review

This Change Management Policy is owned by Compass IoT's engineering leadership and reviewed annually, or following any incident where an uncontrolled or poorly managed change was a contributing factor.

Questions

Get in touch

Questions about our change management process or deployment practices.

trust@compassiot.com→