ISMS documentation

Change Management Policy

ISMS Copilot maintains a formal change management policy to ensure all changes to our production systems are reviewed, tested, and deployed safely. Our process balances security and compliance requirements with the need for rapid iteration.

Our change management policy integrates directly with our GitHub workflow and CI/CD pipeline for automated enforcement.

Change Types

We categorize changes into three types based on risk and impact:

  • Standard Changes — Low-risk, pre-approved changes such as documentation updates, dependency patches, and routine configuration updates. These can be auto-merged after automated checks pass.

  • Normal Changes — Feature additions, database schema modifications, API changes, and security updates. Requires full review process with at least one approval before deployment.

  • Emergency Changes — Critical security vulnerabilities, service outages, or data integrity issues. Follows expedited approval process while maintaining audit trail and post-deployment review.

Approval Workflow

Our standard change process follows these steps:

  1. GitHub Issue Creation — Change request documented with justification and impact assessment

  2. Branch and Pull Request — Code changes developed in feature branch with descriptive PR

  3. Automated Testing — CI pipeline runs automated tests including unit tests, integration tests, and security scans

  4. Peer Review — At least one team member reviews code, architecture, and security implications

  5. Approval and Merge — Approved changes merged to main branch

  6. Automated Deployment — Changes automatically deployed to production via our CI/CD pipeline (Supabase, Fly.io, Vercel)

Emergency changes follow an expedited path but still maintain audit trail and require post-deployment review within 24 hours.

Testing and Quality Gates

Before any change reaches production, our automated CI pipeline enforces:

  • Automated test suite execution

  • Database migration validation on Supabase CI environment

  • Static code analysis and security scanning

  • Build verification for all deployment targets

Rollback and Recovery

Our change management policy includes rollback procedures for failed deployments. We maintain the ability to quickly revert changes while preserving data integrity and system availability.

All changes are tracked in GitHub with full audit history including approvers, timestamps, and change justification.

Secrets and Configuration Management

Changes involving secrets, API keys, or sensitive configuration follow additional security controls beyond standard change procedures to prevent credential exposure.

Was this helpful?