Change Management Procedure

How changes to production systems are proposed, reviewed, approved, and deployed

Public

Change Management Procedure

Implements: Information Security Policy Section 7 (Change Management) Owner: ISMS Owner Last Updated: 21 May 2026 Next Review: 21 November 2026

Change Types

TypeDefinitionApprovalDeployment Window
StandardRoutine code change, dependency update, config change1 reviewer via PR approvalAny time
SignificantNew feature, API change, infrastructure change, security-sensitive2 reviewers including Security LeadBusiness hours (AEST)
EmergencyHotfix for P1/P2 incident, critical vulnerability patchISMS Owner or Security Lead verbal approval, post-hoc PRImmediately

Standard Change Process

1. Propose

  1. Create a branch from main
  2. Make changes following repository coding standards
  3. Write or update tests as needed

2. Review

  • Open a Pull Request with description of what and why
  • Automated CI must pass (lint, test, build)
  • At least 1 approved review required
  • CODEOWNERS rules apply (if file path requires specific reviewer)

3. Merge

  • Squash merge to main
  • CI deploys automatically to sandbox (where applicable)

4. Deploy to Production

  1. For Rust Workers: CI builds WASM, deploys via wrangler deploy
  2. For TypeScript Workers: CI deploys via wrangler deploy
  3. For mobile: App store review process applies separately

5. Verify

  1. Check Cloudflare dashboard for error rates
  2. Verify key endpoints return expected responses
  3. Monitor for 30 minutes post-deploy

Significant Change Process

All steps from Standard, plus:

  • Design review before implementation (brief written description of approach)
  • 2 reviewers required on PR, one of whom must be the Security Lead
  • Staged rollout where possible (sandbox first, then production)
  • Rollback plan documented in PR description
  • Post-deploy monitoring for 2 hours

Emergency Change Process

  1. Verbal approval from ISMS Owner or Security Lead (Slack, phone, or in-person)
  2. Fix applied directly. may bypass standard branch naming
  3. Deploy immediately to production
  4. Post-hoc PR created within 24 hours documenting the change
  5. Post-incident review to determine if the emergency could have been prevented

Rollback Procedure

Cloudflare Workers

# List recent deployments
wrangler deployments list

# Rollback to previous version
wrangler rollback

If Rollback Fails

  1. Revert the merge commit on main
  2. Push the revert
  3. CI will deploy the reverted version
  4. Investigate root cause before re-attempting the change

Change Log

All changes are tracked via:

  • Git commit history (immutable record of all code changes)
  • GitHub PR descriptions (what, why, reviewer approvals)
  • Cloudflare deployment logs (when each version went live)
  • This procedure does not require a separate change log. Git is the source of truth