> ## Documentation Index
> Fetch the complete documentation index at: https://trust.denialbase.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Change management policy

> Annex A.8.32 — formal policy governing how changes to Denialbase systems are planned, reviewed, and deployed.

<Info>
  This is the policy document. For the operational walkthrough of the change pipeline (PR gates, CI/CD, deploy pipeline), see [Change management](/trust/change-management).
</Info>

**Owner**: CTO · **Approved by**: Security Officer · **Policy version**: 0.9 (draft)

## Purpose

No change reaches production without:

1. **Review** — at least one independent reviewer.
2. **Automated verification** — tests + lint + security scans pass.
3. **Traceability** — every change is linked to an issue / ticket and an approving reviewer.
4. **Rollback capability** — every deploy can be rolled back quickly.
5. **Audit record** — the change history is preserved for 7 years.

## Scope

All changes to:

* Application source code (backend, frontend, E2E).
* Infrastructure-as-code (Terraform).
* CI/CD pipeline configuration.
* Security tooling configuration (Brakeman, gitleaks, WAF rules, Cloud Armor policies).
* Database schema.
* Policies and documented procedures (this Trust Center).

Out of scope: individual workstation configuration, personal dotfiles.

## Change categories

| Category               | Examples                                                             | Approval needed                                               | Deploy window      |
| ---------------------- | -------------------------------------------------------------------- | ------------------------------------------------------------- | ------------------ |
| **Standard**           | Feature work, refactors, bug fixes, dependency patches               | 1 reviewer (author ≠ reviewer)                                | Business hours     |
| **Security-sensitive** | Auth, encryption, policies, PHI handling, Pundit changes             | 2 reviewers, one must be CTO or Security Officer              | Business hours     |
| **High-risk**          | Database migrations, prod secret rotation, WAF changes, IAM bindings | 2 reviewers + CTO sign-off; deploy planned + announced        | Low-traffic window |
| **Emergency**          | Patch for active vulnerability, incident response fix                | 1 reviewer (post-hoc OK for Sev-1), Security Officer notified | Immediately        |

## Controls for every change

<Steps>
  <Step title="Planning">
    Change is linked to an issue / ticket describing the business or security need.
  </Step>

  <Step title="Branch">
    Work happens on a feature branch; `master` is protected.
  </Step>

  <Step title="Pull request">
    PR template includes: summary, test plan, security considerations, rollback plan.
  </Step>

  <Step title="Automated checks (blocking)">
    * Linting (RuboCop, ESLint, terraform fmt + validate)
    * Backend tests (rspec with 90% coverage)
    * Frontend tests (Vitest with 80% coverage)
    * E2E smoke tests (Playwright)
    * SAST: Brakeman, Trivy (Terraform), gitleaks
    * Dependency scans: bundler-audit, npm audit, license\_finder
    * TypeScript type check
    * OpenAPI freshness (if API changed)
  </Step>

  <Step title="Human review">
    Required review from a non-author. Security-sensitive changes require a 2nd reviewer.
  </Step>

  <Step title="Merge">
    Squash-merge preferred to keep master history linear. Merge commit includes the PR description.
  </Step>

  <Step title="Deploy">
    Automated build + push + deploy pipeline runs via Workload Identity Federation. Cloud Run rolls out with health-check gating.
  </Step>

  <Step title="Monitor">
    Sentry + Cloud Monitoring watch for error-rate anomalies. First 15 minutes post-deploy have elevated attention.
  </Step>

  <Step title="Rollback (if needed)">
    Any previous Cloud Run revision can be promoted via a single command. Terraform state is versioned for infra rollbacks.
  </Step>
</Steps>

## Protected branch rules

`master` is protected:

* No direct pushes (enforced by GitHub).
* Required status checks before merge (listed above).
* Required reviews from code owners for security-sensitive paths.
* Signed commits required for anyone with write access (as of Q2 2026).
* Force-push disabled.

## Database migrations

* `strong_migrations` gem enforces safe-migration patterns at development time.
* Migrations must be **reversible** unless explicitly flagged and reviewed.
* **Backfills separated** from schema changes (two PRs or two migrations).
* **Concurrent index creation** for tables > 10k rows.
* **No column drops** without `safety_assured` block + compatibility window.
* Migrations run in the Cloud Run **migration job**, not in the runtime.

## Emergency changes

For Sev-1 incidents or actively exploited vulnerabilities:

<Steps>
  <Step title="Ship the fix">
    Minimum viable fix, reviewed by any one qualified engineer. Skip secondary gates that aren't relevant.
  </Step>

  <Step title="Notify">
    Security Officer + CTO informed in real time (incident Slack channel + status page if customer-impacting).
  </Step>

  <Step title="Post-hoc review">
    Full PR review completed within 1 business day after the fire is out, including any tests that should have caught this.
  </Step>

  <Step title="Post-mortem">
    Within 5 business days — covered under [Incident response](/trust/incident-response#post-incident-review).
  </Step>
</Steps>

No emergency change bypasses: audit logging, signature on the commit, or the requirement that the Security Officer is informed.

## Infrastructure changes

Terraform changes follow the same PR flow with added gates:

* `terraform fmt -check -recursive` (blocking)
* `terraform validate` (blocking)
* `terraform plan` output attached to the PR for review
* Trivy config scan (blocking on MEDIUM+)
* Apply happens via CI after merge, under the deploy service account
* Apply output is archived with the commit

Specific high-risk Terraform changes require CTO + Security Officer sign-off:

* IAM binding changes
* KMS or Secret Manager changes
* VPC / firewall changes
* Cloud Armor / WAF rule changes
* Org-level policy changes

## Segregation of duties

* **Author ≠ reviewer** — enforced.
* **Deploy runs under CI service account** — no human holds production deploy credentials.
* **Break-glass access** for prod data is separate from code deploy — different approval path.
* **Security Officer independence** — security changes are reviewed by Security Officer, who is not an operational owner of the code being changed where practical.

## Customer-visible communications

Changes that affect customers visibly are communicated via:

* **Status page** — for outages, planned maintenance.
* **In-app changelog** — for product changes.
* **Email notifications** — for security-material changes (new subprocessor, policy update).
* **Trust Center (this site)** — for any change to security or compliance commitments.

## Records retained

| Record                 | Retention                                             |
| ---------------------- | ----------------------------------------------------- |
| PR history             | Permanent (GitHub)                                    |
| CI/CD run logs         | 2 years (GitHub Actions retention + extended archive) |
| Deploy logs            | 1 year (GCP Cloud Logging)                            |
| Emergency change log   | 7 years                                               |
| Terraform plan outputs | 1 year                                                |
| Post-mortem records    | 6 years                                               |

## Review

This policy is reviewed annually by the Security Officer and CTO, and whenever a material change is made to the CI/CD pipeline.

## Related

* [Change management](/trust/change-management) — implementation detail (pipeline, gates, pipeline stages)
* [Vulnerability management](/trust/vulnerability-management) — SLAs for fix deployment
* [Incident response](/trust/incident-response) — emergency change coordination