Provide guidance and insight into the change management requirements, that have to meet the various compliance audits, such as for SOC2 and SOX.
For compliance purposes, there are a minimum set of requirements that GitLab should be able to evidence to an auditor performing an operating effectiveness evaluation of GitLab change processes and procedures. These requirements include:
As a supplement to evaluating the change processes at GitLab, an Auditor may also perform testing of privileged access to production systems and reconcile the access against those with development access. Something to keep in mind as we work through the change management discussion. With how GitLab operates, this may not be a viable solution.
There are certain cases where all the change requirements may not be possible prior to being implemented into production. For example, if GitLab experiences major downtime, critical fixes may need to be deployed to make GitLab available again. In these cases, this is considered to be an emergency change. In order to mitigate the risks of unauthorized code being deployed to production, we should ensure that if an emergency change has to be deployed that someone separate than the individual who deployed the change reviews the change after-the-fact and provides a confirmation that the change was performed correctly.
There may be some cases where it does not make sense for a change to be tested prior to being deployed. For example, in a third party system where we are making a change to a vendor provided configuration (such as making a change to the password expiration), it would not make sense to test the change given that this is a vendor provided setting.
|Change Steps||Description||GCF Control Mapping|
|Open Change Issue||Create change issue to track change||[CM.1.01 - Change Management Workflow](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/-/issues/781)|
|Change requirements documented||Document:
- Change Description
- Impact of Change
- Test Results
- Backout Procedures (in-scope SOX systems)
|[CM.1.02 - Change Approval](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/-/issues/782)|
|Change is Tested||Testing is conducted in non-production environment
prior to approval and deployment
|Emergency Change||Approval obtained retroactively depending on the urgency of the change||[CM.1.04 - Emergency Changes](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/-/issues/1692)|
|Approval for Change||Approval is provided by someone
other than change requestor
|[CM.2.01 - Segregation of Duties](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/-/issues/783)|
|Change is Deployed to Production||Once tested and approved,
the change is deployed to production.
|MR is tracked in Change Issue||Merge request is linked to the change issue.|
|Close Change Issue||Close change issue|