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 Linear ticket.
2. Automated Testing – CI pipeline executes unit, integration, SCA and SAST scans; PR must pass.
3. Peer Review – Minimum 1 approver with appropriate domain knowledge.
4. Security Review – Changes touching auth, crypto, or PII flagged for Security Champ review.
5. Approval – Merge triggers infrastructure plan validation and requires SRE sign-off for infra 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. Segregation of Duties

No individual may both approve and deploy a change to production unilaterally. CI enforces this via branch protection rules.

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.0