GitLab
A single application for the entire DevOps lifecycle
GitLab Professional Services
Accelerate your software lifecycle with help from GitLab experts
Popular GitLab use cases
Remote Work Continuous Integration (CI/CD) Source Code Management (SCM) Out-of-the-box Pipelines (Auto DevOps) Security (DevSecOps) Agile Development Value Stream ManagementGitLab
A single application for the entire DevOps lifecycle
GitLab Professional Services
Accelerate your software lifecycle with help from GitLab experts
Popular GitLab use cases
Remote Work Continuous Integration (CI/CD) Source Code Management (SCM) Out-of-the-box Pipelines (Auto DevOps) Security (DevSecOps) Agile Development Value Stream ManagementUpon notification of a reassignment or transfer, management reviews the GitLab team member's access for appropriateness. Access that is no longer required is revoked and documented, and any shared authentication credentials to which the team member had access are rotated.
The purpose of this control is to ensure there is a process in place to remove access to user accounts that is no longer necessary in the event of a role change. This control helps ensure that only authorized and active accounts can be accessed and used to prevent any unauthorized use or access of GitLab customer, GitLab teammember, and partner data. PeopleOperations would be responsible for advising of role change and new hiring manager of reviewing and de-provisioning any access that was no longer required.
This control applies to any system or service where user accounts can be provisioned.
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 Role Change: Access De-Provisioning control issue.