Implements the change-management requirements of the Operations Security Policy.

​
Standard change

  1. Plan & assess. Document purpose, specification, dependencies, and rollout plan in the PR description.
  2. Authorize. Approving review on the PR (see Code Review). For substantial changes, also notify the system owner or the CTO.
  3. Communicate. For changes affecting external partners or customers, post in #releases at least 5 business days in advance (shorter for emergency changes per the Emergency change section).
  4. Test. Changes are tested in a non-production environment (staging) before production deploy.
  5. Deploy. Per the planned schedule. Deploys go through GitHub Actions.
  6. Verify. Post-deploy smoke tests, monitoring dashboards, error rates.
  7. Rollback. If the change fails or causes regression, revert via the Rollback Procedure.

​
Emergency change

Emergency changes may be expedited but must undergo retrospective review and authorization. Process:
  1. Deploy the fix.
  2. Notify engineering on-call (and the CISO if security-related) in #engineering-incidents.
  3. File the Emergency Change Retro intake form within 24 hours documenting the change, root cause, and review. A retrospective PR is opened from the same ticket.
  4. The post-hoc review captures approver and any follow-ups.

​
Continuity

ICT continuity plans, response procedures, and recovery procedures are kept up to date with significant changes. See Business Continuity.

​
Records

Change records (PRs, deploy history, ticket trail) are retained per the Records Retention Schedule → Security and operations (3 years) and the system-by-system Data Retention Matrix.

​
Version history

VersionDateDescriptionAuthorApproved by
1.0May 8, 2026Initial versionCameron WolfeIshan Jadhwani