Temporary Service Providers are team members that are provided by an outside vendor under an authorized contract, for a limited period of time.
Similar to our Access Request process for team members, we have an access request process for consultants or professional services providers. We track issues related to consultants/professional service providers in the Temporary Service Providers group. Temporary Service Providers need to go through the Professional Services Procurement process before they can be onboarded.
All steps below must be completed prior to any onboarding or access assignment.
If the vendor requires access to systems to complete work, the vendor manager (ie. the GitLab team member who will manage the relationship with the temporary service provider, generally a people manager) is responsible for creation of a Vendor Access Request and Orientation issue.
Access Request: These issues aren't created in the same location as access requests for team members. Please use the following link to create an AR using the access request template and assign it to yourself and the relevant provisioner(s) for the tools that the professional services provider requires access to, please also tag the
@gitlab-com/business-technology/team-member-enablement team. The AR should include only systems that are necessary to the work that the vendor will be performing.
Orientation Issue: To support the service provider through the set up of the most common tools used at GitLab, an orientation issue must be created. Assign to yourself and the professional services provider if they have a GitLab account with the required access.
Please read instructions on how to request access to the following applications (managed by IT):
-extpostfix, e.g., .
janedoe-ext. From there, the manager can include their username information in their access request along with the minimum groups/projects they need to complete job duties. Contractors who will make contributions to GitLab directly should be added to the
gitlab-org/contractorsgroup, so that automations related to triage and review can be run against their merge requests.
GSuite/Google Workspace: Google Workspace access (including a @gitlab.com email address) will not be provided unless there are reasons why Temporary Service Providers would require it. Documents and shared drives within G Suite/Google Workspace can be shared outside of GitLab so a @gitlab.com email address isn't required for that purpose. Situations where we would provide access are:
what is my IPv4in google search from work computer), and location (NOTE: this information should not be stored in the GitLab issue).
Please read the information below carefully, failure to follow through with the TSP offboarding process can result in compliance violations.
GitLab's user access review is an important control activity required for internal and external IT audits. Please refer to our Access Review Procedure to review the reason Gitlab user access reviews are conducted. This handbook page will detail the process of executing specifically our contractors user access reviews.
IT will be monitoring contractor accounts that have not logged in for 21 days and notifying the responsible GitLab managers to confirm that the contractors should still be active.
Please refer to the above sections of this page for additional information related to managing Contractors.