Change Management Policy (A.8.32)

Document ID: change-management-policy
Version: 1.0
Effective from: 2025-01-01
Owner: ISMS owner
Review cycle: Annual

note

This document is aligned to ISO/IEC 27001:2022 Annex A as a self-assessment. SigmaShake holds no ISO 27001 certification.

---

Purpose

Ensure that changes to production systems are assessed, authorised, and documented to prevent unintended disruption or security degradation.

Change categories

Category	Examples	Authorization required
Standard (pre-approved)	Dependency updates, documentation, non-logic configuration	PR review + tests pass
Normal	New features, schema migrations, new collectors	PR review + tests pass + self-review checklist
Emergency	Critical security patch (CVE), production break	Deploy immediately, document within 24h
Major	New service, new trust boundary, new data category	PR review + threat model update + rollout plan

Change process

1. Plan — Write a description of the change and its motivation. Open a PR when the change uses one (PR review is a target, and no verified control enforces it)
2. Review — Self-review using the code review checklist (Secure Development Policy)
3. Test — Run: bun run typecheck:all && bun run test:all
4. Approve — Target: merge takes one review (no verified control enforces this today). The ISMS owner approves changes; review is by external tooling (/review or /ultrareview) and is passed automatically; independent review is not performed today. Compensating controls are in the Statement of Applicability
5. Deploy — bun run deploy via the deploy-guard script (the clean-tree check against origin/main runs only when SSG_DEPLOY_STRICT=1 is set)
6. Verify — bun run compliance:dev and post-deploy evidence check

Deploy guard

Cloudflare Worker deployments go through shared/agent-config/scripts/deploy-guarded.sh. By default the script passes straight through to wrangler deploy and does not check the working tree. The check that refuses a deploy when any tracked file differs from origin/main is opt-in. Set SSG_DEPLOY_STRICT=1 to turn it on. The origin/main check is not enforced by default.

Schema migrations

D1 migrations are numbered sequentially (migrations/NNNN_*.sql) and applied via wrangler d1 migrations apply. Migrations are append-only; no destructive column drops.

Rollback

• Worker code: Deploy previous version via wrangler rollback
• Schema: Rollback migrations are not supported in D1; design migrations to be additive
• Evidence: Evidence objects are written once and are not rolled back. The 90-day R2 Object Lock is a target set by hand in the Cloudflare dashboard; the weekly r2-object-lock-verify collector checks the rules, and verification is an open ISMS-owner action

Evidence

Collector	Cadence	Control
merge-activity	Daily	A.8.25, A.8.32
deployments	Weekly	A.5.8, A.8.32
branch-protection	Daily	A.8.19, A.8.25, A.8.31