Uncontrolled change is a leading cause of outages and security incidents. This policy describes how Code Cutter Limited (trading as Mailbuttons) manages changes to its production systems so that they are deliberate, reviewed, reversible and recorded.

# Purpose and scope

This policy governs all changes to Mailbuttons production systems: application code, database schema, infrastructure configuration and deployed services. It applies to routine and emergency changes alike. It supports ISO/IEC 27001:2022 Annex A 8.32 (change management) and complements 8.31 (separation of environments).

# Policy

Everything is version-controlled. All production changes originate in git. There are no untracked, hand-edited production changes; the deployed state is reproducible from source. This gives every change an author, a timestamp and a history.

Review and test before deployment. Changes are reviewed via commit review before they are eligible for deployment. Before a build is deployed, it passes the build, typecheck and cargo test steps in CI or locally. Security-sensitive changes additionally receive adversarial security review (see the Secure Development Policy).

Controlled deployment. Production is updated through a single, controlled make deploy process that builds a release artefact and deploys it to systemd-managed services on our Fasthosts UK VPS. Deployment is not performed by ad-hoc manual edits on the server. Each deployment is logged.

Rollback. Because deployments are built from versioned source, rollback is achieved by redeploying a previously known-good build. We do not rely on provider snapshots (Fasthosts does not offer them), so reversibility is designed into the build-and-deploy process itself rather than the hosting layer.

Database schema changes. Schema changes are made exclusively through reviewed SQLx migrations held in source control. Migrations run on application startup, so a schema change is bound to the application version that requires it. Migrations are written to be safe to apply and are reviewed with the same rigour as code.

Logging of changes. Production changes — deployments, migrations and configuration changes — are recorded. This record supports incident investigation and provides an audit trail of who changed what and when.

Separation of duties. Where feasible for a micro-team, we separate the authoring of a change from its release. As a founder-led single-engineer team this separation is partial; we compensate with mandatory version control, automated testing gates, controlled deployment and retrospective review, and we acknowledge this constraint openly rather than claim a segregation we cannot fully staff.

Emergency changes. When an urgent fix is required — for example to remediate an active incident or a critical vulnerability — the normal pre-deployment steps may be expedited. Emergency changes are still committed to version control and deployed through make deploy, and they are reviewed retrospectively as soon as practicable to confirm correctness and capture any follow-up work. No emergency change is left unrecorded.

# Responsibilities

The ISMS Owner is accountable for this policy and for ensuring changes are reviewed, tested, deployed through the controlled process and recorded. The ISMS Owner authorises emergency changes and ensures their retrospective review.

# Review

This policy is reviewed at least annually and after any material change, and is approved by the ISMS Owner.

Related: Secure Development Policy, Vulnerability and Patch Management Policy, Logging and Monitoring Policy, Incident Response Policy