Change Management Policy

Governs how changes to Finaisse code and infrastructure are proposed, reviewed, tested, and deployed. Subordinate to the Information Security Policy.

Policy owner	Security & Infrastructure Owner (Sekhar Prakash)
Applies to	All changes to blitz, blitz-ui, fin-infra, and deployed environments
Effective	2026-08-19 (v0.1 draft)
Review cadence	Annual + on major change
SOC 2	CC8.1

1. Purpose

Ensure every change reaching a Finaisse environment is reviewed, traceable to an approved source change, and reversible — preventing both security regressions and availability incidents.

2. Scope

All application code, frontend, and infrastructure-as-code changes, and all deployments to staging and (future) production.

3. Policy statements

3.1 Source control & review

• All changes are made via Git and merged through pull requests — no direct commits to main for changed code.
• Peer review before merge is expected practice but is not enforced: the ruleset requires 0 approvals, so an author can merge their own PR. Kept this way by owner decision (2026-09-24); revisit before production deploys run through the merge-to-deploy flow.
• Branch protection is enforced on the default branch of blitz, blitz-ui, fin-infra and fin-internal-docs by the org-level ruleset DefaultBranchProtection: pull request required (no direct push), no force-push, no branch deletion. Organization admins can bypass. There are no required status checks since 2026-09-15 (see §3.2). finwebsite and fin-works are not covered. 🎯 Target — required review (at least 1 approval, or code-owner review on the deploy manifest release.json) (F-37; owner: Security & Infrastructure Owner).
• Repositories squash-merge; the squashed commit is the traceable unit of change.

3.2 Automated validation gates

• CI (GitHub Actions) builds and validates every change; images are published to GHCR.
• No automated check blocks a merge. Dependency and security scanning state — what runs, what was withdrawn and why — is recorded once in the Control Register. Change control rests on the pull-request requirement plus branch protection (§3.1), not on a gating check; review within the PR is by convention, not enforced.
• 🎯 Target — add security scanning as required CI gates: dependency (SCA), secret, container image, and IaC scanning, plus SAST (F-31). These run ad-hoc today; the decision on tooling (GitHub Advanced Security vs OSS) is an open owner decision.

3.3 Deployment

• Deployments are performed through code (fin-infra scripts / GitHub Actions), not manual dashboard edits. For AWS, all infrastructure is Terraform; manual console changes are prohibited except documented bootstrap steps.
• Deploys wait for each service tier to reach a healthy state and fail the run on a bad rollout.
• Image tags resolve at deploy time; deploys occur after the image build completes.

3.4 Production change control (AWS — target state)

🎯 Target, applies at AWS production go-live:

• A Terraform plan review/approval gate before apply (F-22).
• Change record (what, why, security impact) for production-affecting changes.
• Defined rollback path for every deployment (see Rollback).
• An emergency change procedure for incident remediation, with review after the fact.

4. Traceability & audit

Every production change is traceable to a reviewed, approved commit via the CI/CD pipeline. Deployment history is retained. 🎯 Target (AWS) — CloudTrail records all infrastructure API calls (F-11).

5. Enforcement & exceptions

Changes bypassing this policy are reverted unless retroactively reviewed and approved. Emergency exceptions require owner notification and post-change review.

Revision history

Version	Date	Author	Change
0.1	2026-08-19	Security & Infrastructure Owner	Initial draft
0.2	2026-09-24	Security & Infrastructure Owner	§3.1 corrected to the live ruleset: branch protection covers four repos (not fin-infra alone), peer review is not enforced (0 required approvals), no required status checks.