Skip to main content
This is the policy document. For the operational walkthrough of the change pipeline (PR gates, CI/CD, deploy pipeline), see Change management.
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

CategoryExamplesApproval neededDeploy window
StandardFeature work, refactors, bug fixes, dependency patches1 reviewer (author ≠ reviewer)Business hours
Security-sensitiveAuth, encryption, policies, PHI handling, Pundit changes2 reviewers, one must be CTO or Security OfficerBusiness hours
High-riskDatabase migrations, prod secret rotation, WAF changes, IAM bindings2 reviewers + CTO sign-off; deploy planned + announcedLow-traffic window
EmergencyPatch for active vulnerability, incident response fix1 reviewer (post-hoc OK for Sev-1), Security Officer notifiedImmediately

​
Controls for every change

1

Planning

Change is linked to an issue / ticket describing the business or security need.
2

Branch

Work happens on a feature branch; master is protected.
3

Pull request

PR template includes: summary, test plan, security considerations, rollback plan.
4

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)
5

Human review

Required review from a non-author. Security-sensitive changes require a 2nd reviewer.
6

Merge

Squash-merge preferred to keep master history linear. Merge commit includes the PR description.
7

Deploy

Automated build + push + deploy pipeline runs via Workload Identity Federation. Cloud Run rolls out with health-check gating.
8

Monitor

Sentry + Cloud Monitoring watch for error-rate anomalies. First 15 minutes post-deploy have elevated attention.
9

Rollback (if needed)

Any previous Cloud Run revision can be promoted via a single command. Terraform state is versioned for infra rollbacks.

​
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:
1

Ship the fix

Minimum viable fix, reviewed by any one qualified engineer. Skip secondary gates that aren’t relevant.
2

Notify

Security Officer + CTO informed in real time (incident Slack channel + status page if customer-impacting).
3

Post-hoc review

Full PR review completed within 1 business day after the fire is out, including any tests that should have caught this.
4

Post-mortem

Within 5 business days — covered under Incident response.
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

RecordRetention
PR historyPermanent (GitHub)
CI/CD run logs2 years (GitHub Actions retention + extended archive)
Deploy logs1 year (GCP Cloud Logging)
Emergency change log7 years
Terraform plan outputs1 year
Post-mortem records6 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.