Business Technology Change Management covers changes to System settings in addition to Process and Policy changes. The Business Technology Change Management (CM) process at GitLab provides a framework for the thorough documentation, testing, and evaluation of proposed changes to the Business Technology systems. The CM process mitigates risk to production applications that could threaten the stability, resiliency, security, data availability, integrity, and regulatory compliance.
This handbook page defines the steps necessary to implement and maintain CM processes to ensure changes are planned, documented, reviewed, and approved in a controlled manner.
Making a user- or group-level change doesn't require a Business Technology change request. For example, if your team decides to make a change to one of your team's group settings on GitLab.com, a Business Technology change request isn't required. However, if you decide to make a change to a configuration or setting for GitLab.com globally, that requires a change request. Another example is Google Drive. If you decide to make a change to one of your team's Google Drive folders, no Business Technology change request is required. But if you change the default sharing setting of all of Google Doc for GitLab, a Business Technology change request is required.
Additional examples include: If you are making a Process and/or Policy change that will impact only your team's process, a change management is not required. If you are making a Process and/or Policy change that will impact one or more other departments, a change management is required.
For additional information regarding Change Management, refer to our Change Management Workflow Control Guidance.
A Business Technology change request is only needed when a change is being requested for review for applications already listed in our tech stack.
There are many benefits from effective change management.
Outage prevention and reducing user impact
Helps ensure that changes are made with good planning
Change management is required as part of many regulations and is audited for effectiveness
Note This would be the final stage of scope. As the first iteration, we will need to scope this down more and implement phases to the scope.
Change Management process covers changes to systems across the Business Applications.
Examples
A few examples are listed below. These examples are not meant to be all encompassing.
| Role | Responsibility |
|---|---|
| IT Compliance Team | Maintain a mechanism to intake and respond to Change Management Activities |
| Provide complete and accurate responses within documented SLA | |
| Document and report any risks or trends identified during Change Management Activities | |
| Maintain Metrics | |
| Business Requestor | Complete the Change Management issue |
| Work with the Technical Owner to document, test, and obtain approval(s) for change | |
| Technical Owner | Work with the Business Requestor to ensure requested change is documented, tested, and approval(s) have been completed |
| Ensure Peer Review is completed prior to obtaining Business Approval | |
| Peer Review | Review and ensure requested change has been documented and there are no undocumented downstream impacts |
| Post Implementation Review | Review of the change in production after the change is made to ensure everything is working as expected |
| Business Owner | Review and provide approval prior to change being implemented |
Minor Change
A minor change is a low risk, well-understood change which does not require testing (such as with a record change, as opposed to a configuration change). Changes may be implemented directly in Production, have no financial impact, are related to general maintenance, and can be easily reversed.
Standard
A standard change is a pre-authorized change that is low risk, relatively common and follows a specified procedure or work instruction.
Comprehensive
A comprehensive change is high risk, high impact, or has a more complex procedure.
Emergency
An emergency change follows the same approval process as comprehensive.
| Approval Type | Description | Minor | Standard | Comprehensive | Emergency |
|---|---|---|---|---|---|
| Peer Review | Peer Reviews are performed by a peer of the change Requestor or Developer and are intended to identify any potential issues with the planned change or change process. Note: The peer review process was established to mitigate the risk of the lack of segregation of duties between developer and implementer. The review provides comfort that changes to the production environment are valid. | No | No | Yes | Yes |
| Post-Implementation Review | Performed by a peer of the change Requestor or Developer and are intended to ensure the change is working as expected after the change has been implemented in Production. | Yes | Yes | Yes | Yes |
| Impacted Team(s) Management/Code Owner approval | Approval by Management that is responsible for the particular system | Yes | Yes | Yes | Yes |
| Business Approval | Approval by Impacted Team(s) Management approval that is responsible for the particular system or is impacted by the change. | No | No | Yes | Yes |
| Head of IT, Business | The Head of IT must approve all changes made during blackout periods | No | No | Yes | Yes* |
Blocked periods are established to ensure that BT system changes do not adversely affect quarter-end, or year-end closing processes for financially significant applications.
Their duration is typically established by the requirements of the Finance and Sales departments and not IT itself.
Significant Enterprise Applications
All other applications and/or tools Last 7 calendar days and first 7** calendar days of each quarter
All exceptions need Head of BT and Business approval
*Significant Enterprise Applications are: Coupa, NetSuite, Salesforce, Zuora
**Finance impacted systems.
Where possible, mass deployments such as macOS operating system upgrades (i.e. Monterey to Ventura) or net new software rollouts will be done by Department. Smaller changes such as security patches or minor updates of existing software are not subject to the same schedule and can be deployed globally after Phase 1 testing is complete. The order of mass deployments will be as follows:
VIP support for significant or disruptive changes will be treated via direct support from the Service Desk team who will schedule a call at a convenient time to ensure the update or deployment is successful with minimal disruption.
If you wish to join the volunteers group to test new software, please join the #it-security-beta-testers channel on Slack and let us know - everyone can contribute!
If during the Business Technology change request process it's decided team members should be notified of a change (for example, changing the default Google Doc sharing settings), please ensure that you communicate the change and its impact by posting in #whats-happening-at-gitlab.
If the change is approved and requires communication to team members, communicate the change, its rationale, and its impact.
Please note the change will always be implemented on a Tuesday following the change approval and communication. This will allow the ability and coverage should the change need to be backed out and re-reviewed.
If no communication is required or the change has been communicated already, make the change.
Exceptions to this procedure will be tracked as per the Information Security Policy Exception Management Process.
