Change Management Policy – SOC 2 Edition

1. Purpose

To ensure that changes to Clerk.io production systems are authorised, tested and documented, reducing risk of unintended service disruption or security impact.

2. Scope

Applies to code, infrastructure-as-code, configuration, schema migrations, and third-party service changes that could affect the confidentiality, integrity, availability, or privacy of customer data.

3. Process

1. Proposal – Engineer opens GitHub Pull Request (PR) referencing a Linear ticket. PRs remain mandatory for every production change to preserve traceability to Linear, squash history, and one-click revert capability.
2. Automated Testing – CI pipeline executes unit, integration, SCA and SAST scans; PR must pass before merge.
3. Peer Review (Optional) – Engineers exercise professional judgment to decide whether peer review is warranted. Review is strongly encouraged for complex, high-impact, or otherwise high-stakes changes (e.g. broad refactors, data migrations, customer-facing behaviour shifts); routine or low-risk changes may be merged by the author without an additional reviewer. The author retains full ownership and accountability for the change.
4. Security Review – Changes touching authentication, cryptography, secret handling, or PII data flows are flagged for Security Champ review; this review remains required regardless of the optional peer-review step in §3.3.
5. Merge – Merge triggers infrastructure plan validation; SRE sign-off is required for infrastructure-as-code changes.
6. Deployment – Continuous Deployment auto-rolls to staging ⇒ canary ⇒ prod with automated rollback on failed health checks.
7. Post-Deployment Verification – Monitoring dashboards and Slack bot confirm KPIs within tolerance.
8. Documentation – Merged PR auto-syncs CHANGELOG, and incident docs if applicable.

4. Emergency Changes

Allowed when SLA/customer impact dictates. Steps: * Better Stack Incident Commander grants emergency-change label. * Change logged retrospectively within 24 h. * Post-mortem held within 5 days.

4.1 Protected Branch & Ruleset Overrides

In rare cases where GitHub protected branch rules or repository rulesets must be overridden (e.g. protected_branch.policy_override or repo.ruleset_bypass events), the following apply:

1. Overrides must be initiated or explicitly approved by either the Head of Product or the SRE Lead.
2. The justification for the override and associated risk assessment must be documented in the Git commit message performing the override (additional references in Linear or PR descriptions are optional but do not replace the commit requirement).
3. Overrides are treated as emergency changes and are subject to the same retrospective review and post‑mortem expectations as other emergency changes.

5. Ownership & Segregation of Duties

Engineers are accountable for the changes they author and merge. While peer code review is optional, the following controls preserve the integrity of the change pipeline:

• Every production change flows through a Pull Request linked to a Linear ticket, providing an immutable audit trail.
• Automated CI gates (unit, integration, SCA, SAST) enforce quality and security checks independent of human review.
• Deployment to production is automated through CD pipelines; engineers cannot manually push code to production bypassing the PR + CI flow.
• Branch protection enforces signed commits, required status checks, and prevents direct pushes to protected branches.
• Security-sensitive changes (auth, crypto, PII) and infrastructure changes still require the dedicated reviews described in §3.4 and §3.5 respectively.

6. Evidence & Metrics

• Change tickets & PRs stored in GitHub; immutable.
• Deployment logs retained 1 year.
• Monthly metric: # of production incidents caused by change (<3%).

See Controls Matrix entry CM-01 for evidence mapping.

Evidence ID: CM-01 (refer Controls Matrix).

Version 1.1 — effective 2026-04-29 (peer review moved from mandatory to optional; PRs remain mandatory).