External Consultant Orientation & Access Deprovisioning
GitLab will from time-to-time bring in the expertise of External Consultants to work on a specific task for a pre-defined period. Depending on the nature of this engagement and the tasks at hand, the aforementioned External Consultant(s) may require access to certain GitLab systems and information which may include Slack, Customer Data, and Infrastructure Environments.
Consultant Orientation
- The Orientation Issue for External Consultants can be found in the Lifecycle Management Project - this issue should only be created by a Vendor Manager i.e. the individual responsible for initiating the consulting relationship, once a Vendor Contract Request has been created an moved through the approval process.
Once this process is complete the External Consultant will be added to ContractWorks and not Workday which is strictly for GitLab Team Members.
Important Actions
- If you will be making use of an External Consultant please be sure to add the prefix
-CTR
to any associated Usernames and / or Handles that are temporarily created for this user. This allows Team Members to quickly ascertain whether someone is an External Consultant and allows for auditing to be done on these accounts. - If an External Consultant is assigned access to any repositories on a GitLab instance, please be sure to set an expiry date for this access which is aligned to the length of engagement.
Deprovisioning Access
The Vendor Manager is responsible for initiating External Consultant offboarding functions once the External Consultant reaches the end of their engagement with GitLab. This will predominantly center on the deprovisioning of access to any GitLab systems and information which were made available at the time of orientation with the support of IT Ops and the Tech Stack Provisioners.
190e30aa
)