Change scope, change type, and roles and responsibilities are pre-established and documented in a change control workflow; notification and approval requirements are also pre-established based on risk associated with change scope and type.
Having a structured workflow and guidance on change management helps reduce the risk of GitLab experiencing platform or application instability by increasing the predictability and reproducibility of the change management process.
This control applies to all systems within our GitLab.com production environment. The production environment includes all endpoints and cloud assets used in hosting GitLab.com and its subdomains. This doesn't include third-party systems that support the business of GitLab.com, which can be found in CM.3.01.
There are two primary changes that occur in production: infrastructure changes and code changes. Infrastructure changes are done in accordance with the Change Management process. Code changes are made in accordance to our contribution, review, and approval processes, which is described as part of the Service Lifecycle Workflow control. Changes made to third-party systems ared related to the Third-Party Change Management Workflow control, which is currently still being developed.
Non-public information relating to this security control as well as links to the work associated with various phases of project work can be found in the Change Management Workflow control issue.
Examples of evidence an auditor might request to satisfy this control: