Change management statement
Status: operative document. Version 1.0, 2026-09-18. Owner: Yannick M. Richard. Review cycle: annual, or on material change. Companion to the scope statement and the statement of applicability (control A.8.32). Not a certification document.
1. Why this document exists
Control A.8.32 requires change management. In most organisations that means a written procedure describing a ticketing process. Here it is different: change management is enforced by the tooling rather than by a document, and the purpose of this document is to describe that mechanism accurately so it can be relied upon.
The short version: it is not possible to change the fleet without a reviewed, CI-verified commit, and it is not possible for a change that breaks the fleet to remain deployed.
2. The change path
Every change to production follows this path. There is no other path — imperative changes are not the working model, and no operator has a workflow that bypasses it.
| Step | What happens | What enforces it |
|---|---|---|
| 1. Proposal | A change is made on a branch of the configuration repository | Git; the main branch requires a pull request |
| 2. Review | The change is opened as a pull request and reviewed before merge | Branch protection: unreviewed changes do not reach main |
| 3. Verification | CI evaluates the configuration, builds the affected systems and runs secret scanning | Automated checks on every PR; a failing check blocks the merge |
| 4. Pre-merge guard | The PR is checked against the current state of main for conflicts | A guard job fails the PR if the branch has drifted, forcing a rebase and re-verification |
| 5. Deployment | Merging to main deploys to affected hosts, or a deployment is dispatched explicitly for a chosen host | The deploy workflow; each run is recorded |
| 6. Health gate | After deployment, the host is given a settle period, then critical services are checked | A health gate that runs on the target host |
| 7. Automatic rollback | If the health gate finds a violation, the deployment reverts | Automatic rollback to the previous generation |
3. The health gate and rollback
Steps 6 and 7 are the part that makes this more than a paper process.
After a deployment, the target host is allowed to settle, and then a fixed set of critical services is checked. A violation triggers an automatic rollback to the previous known-good generation. The rollout does not continue on a host that failed its own health check, and the operator is alerted.
This means the practical guarantee is stronger than “changes are reviewed”: a change that passes review and CI but breaks a critical service in production is reverted automatically, without relying on anyone noticing.
4. Evidence that this happened
Because the configuration is version-controlled and the deployment workflow is itself in the repository, the change history is inspectable: every change has a commit, a review record, and a CI run. Deployments, including their health-gate outcome, are recorded as workflow runs.
Where a change is reverted by the health gate, the rollback is visible in the deployment record and the change must be re-proposed as a new commit — it does not silently reappear.
5. Emergency changes
An emergency change (a security fix or an outage response) is permitted to move faster, but it does not bypass the mechanism: it still lands as a commit, and in a genuine emergency it may be deployed directly on a host and then reconciled back into the repository immediately afterward. The reconciliation is required — an emergency change that is not reflected in configuration would be reverted by the next deployment, which is the correct behaviour and a deliberate design choice.
6. What this does not cover
- Changes made outside the configuration. Secrets are held in an encrypted store and rotated through a documented flow; that rotation is itself part of the managed process rather than an exception to it.
- Third-party changes. Upstream dependencies move on their own schedule. They enter the fleet only through a pinned, reviewed update process, subject to a minimum-age policy for new versions.
- A compromised deployment pipeline. If the pipeline itself were compromised, this control would not save us; that risk is recorded as R-02 in the risk register and mitigated by secret scanning, review requirements and the health gate rather than eliminated.
7. Review
| Date | Version | Change |
|---|---|---|
| 2026-09-18 | 1.0 | Initial statement, describing the enforced mechanism rather than an aspirational process. |