Skip to content

Change Management Policy

Document ID: POL-005 Document owner: Sebastian Windeck (CTO) Classification: Confidential Version: 1.0 Approved: March 2026 Next review: March 2027 Frameworks: ISO 27001 (A.8.32) | SOC 2 (CC8.1)


1. Purpose

This policy establishes the process for managing changes to information systems, infrastructure, and applications at CTW Data Solutions GmbH. It ensures changes are assessed, approved, tested, and documented to prevent unintended disruption.


2. Scope

All changes to production systems including:

  • Application code (Quick-ID API, SDKs)
  • Azure cloud infrastructure (VMs, networking, Key Vault, databases)
  • GitHub repository settings and CI/CD pipelines
  • Google Workspace configuration
  • Security controls and ISMS documentation

3. Change Categories

Category Description Approval Examples
Standard Low-risk, routine, pre-approved Sebastian Windeck (CTO) Dependency updates, minor bug fixes, documentation updates
Normal Moderate risk; requires review ISO + Sebastian Windeck (CTO) New features, infrastructure changes, access control changes
Emergency Critical fix needed immediately ISO (retroactive approval within 24h) Security patches, incident response, critical outage fix

4. Change Process

4.1 Request

  1. Requestor creates a Change Request (GitHub Issue or Change Request Template)
  2. Describe: what, why, impact, rollback plan
  3. Classify the change category

4.2 Assessment

Check Responsibility
Security impact assessment Sebastian Windeck (CTO)
Data protection impact (if personal data affected) DPO
Business impact and rollback plan Change requestor
Dependencies and scheduling Sebastian Windeck (CTO)

4.3 Approval

Category Approver(s) Method
Standard Sebastian Windeck (CTO) GitHub PR approval
Normal ISO + Sebastian Windeck (CTO) GitHub PR approval + written confirmation
Emergency ISO (retroactive) Post-incident documentation within 24h

4.4 Implementation

  1. Changes are implemented via GitHub pull request
  2. All PRs require at least one code review approval
  3. Automated CI/CD pipeline runs: lint, SAST, tests
  4. Changes are deployed to staging first where applicable
  5. Production deployment follows successful staging validation

4.5 Verification

  1. Post-deployment verification confirms the change works as intended
  2. Monitoring is checked for anomalies in the 24 hours following deployment
  3. If issues are detected, rollback is executed per the documented rollback plan

4.6 Documentation

All changes are recorded via:

  • GitHub PR history (code changes)
  • GitHub Issues (change requests)
  • Azure Activity Log (infrastructure changes)
  • Changelog entries for significant changes

5. Emergency Changes

  • Emergency changes may bypass the standard approval process
  • ISO must be notified immediately
  • Full documentation and retrospective review must occur within 24 hours
  • An emergency change that introduced new risk must update the Risk Register

6. Review

This policy is reviewed annually or following a significant change-related incident.


Approved by: CEO / Information Security Officer, CTW Data Solutions GmbH Date: March 2026