Contingent Worker Policy

1. PURPOSE

This policy has been designed to provide Team Members a high-level overview and guidelines on the different types of contingent workers available as well as how and when each should be used.

2. EXECUTIVE SUMMARY

The purpose of the Executive Summary is to provide a high-level overview of the GitLab Contingent Worker Policy, describe business impact and risk, and review highlights of the policy for appropriate utilization of contingent workers. This document may be distributed to Team Members on an as-needed basis.

3. CONTINGENT WORKERS

Throughout this document, you will see the term “contingent workers” used. This term refers to:

• Staff Augmentation Workers
• Consultancy Services
• Independent Contractors

Definitions:

• Staff Augmentation Workers: Consists of supplemental, non-team member staff used temporarily to fill skill gaps or to provide additional project resources. Staff Augmentation Workers are always provided by an agency. If a Staff Augmentation Worker isn’t through an agency, they must qualify as an Independent Contractor. The Staff Augmentation Worker works within the GitLab organization under the general guidance of a GitLab hiring manager. GitLab maintains responsibility for work deliverables. Little or no responsibility is transferred to the vendor or their staff. Knowledge is solely contributed from the supplied worker. GitLab manages the duration of the assignment. In addition to “what” is delivered and “when”, GitLab maintains control over:
  • “who” delivers the service
  • “where” the service is delivered from, and
  • “how” service is delivered.

Services may be required on a full-time or part-time basis but invariably always temporary rather than permanent. Limited details of these Staff Augmentation Worker are to be held in Workday if the contract worker requires access to Okta and core GitLab applications. Max duration for this worker type is 24 months. The assignment end date must be established up front as established in the Purchase Order. The same Staff Augmentation worker can not return to GitLab after ending an assignment for 3 months.

• Consultancy Services: Consultancy Services are provided by a vendor that contracts with GitLab to provide professional services including expert advice within a particular knowledge domain. GitLab contracts with the third party for certain services and the contract is for the scope of work, i.e., the contract is for a product or service and not for an individual worker, for which GitLab is the customer. This arrangement is for non-core work that we trust an expert company to perform on our behalf and this arrangement is not for situations where we need supplemental labor to assist with the peaks of business. The third party has responsibility for the worker(s) and determines who will perform work and how work will be accomplished. Vendor assumes some or all responsibility for service delivery as detailed in a Statement of Work. In addition to providing staff, Vendor may be expected to provide access to its Intellectual Property to deliver service. Vendor manages its staff (e.g. turnover). GitLab maintains responsibility for “what” is delivered and “when”, but vendor maintains control over:
  • “who” delivers the service (staffing)
  • “where” the service is delivered from, and
  • “how” the service is delivered

Limited details of these Contractor Personnel are to be held in Workday only if the contract worker requires access to Okta and core GitLab applications. There is no limit on the length of contract, it will be the length of assignment necessary to fulfill the scope of work determined by the applicable contract and MSA. GitLab has the right to review and update the MSA as necessary.

• Independent Contractor (option not preferred, used by exception only): An individual(s) who works for a company that they own (sole proprietorship) providing project deliverables incorporated into a Statement of Work (SOW). The individual must work truly independently, provided the freedom of action as to the details, methods, and means of performing services. Independent contractors typically perform services for more than one company. Independent contractors may work on outcome based/milestone arrangements in which the business pays the contractor based on the deliverable achieved or they may get paid on a time and materials basis. While this contingent worker type may be used in certain circumstances, its use is by exception only. All Independent Contractors must be contracted using the Independent Contractor Service Agreement (ICSA).

• Independent contractors (also called consultants, freelancers, self-employed workers):

  • are used for subject matter expertise that is outcome or project based
  • GitLab maintains responsibility for “what” is delivered, “who” delivers the service and “when”, but Independent Contractor maintains control over:
    • “where” the service is delivered from, and
    • “how” the service is delivered

The relationship is defined in the contract between GitLab and the independent contractor.

Limited details of these Contractor Personnel are to be held in Workday if the contract worker requires access to Okta and core GitLab applications.

Max duration for this worker is 24 months, with a 3 month break. End date must be established up front.

Staff Augmentation Worker, Consultancy Services, and Independent Contractor Characteristics:

• Staff Augmentation Worker:

  • The contractor typically works in-house on a GitLab project.
  • The contractor may work on tasks in a manner guided by GitLab, using GitLab laptops that have been loaded with the GitLab security stack.
  • The contractor temporarily fills a position that is part of the GitLab organization structure.
  • The contractor is supervised in the line by a GitLab staff member or is accountable to a GitLab focal point.
  • The contractor’s employing company should be on GitLab’s list of preferred vendors for the provision of contract labor.
  • The contractor submits time to their agency’s designated tool
  • The employing company submits regular invoices based on days or hours worked (standard RtP process) to their agency’s designated tool.
  • The contractor is paid by the Staffing Agency typically on a cost per hour basis as agreed to by GitLab and the Staffing Agency.

• Consultancy Services:

  • To provide the service the vendor may require access to GitLab systems or services.
  • The persons employed by the vendor should not be selected by GitLab for the work, but by the service providing vendor.
  • The persons employed by the vendor are not directed or supervised by GitLab staff.
  • Whenever possible, the vendor should be an existing vendor that has already been vetted through the procurement process.
  • Payment is made to the vendor in accordance with the agreed upon Statement of Work (payment schedule, on the basis of achieved milestones and completion of agreed deliverables or Time and Materials).
  • Consultancy Services may include intellectual property which the vendor makes available as part of the service.
  • Consultancy Services are typically provided under a Fixed Price or Time and Materials contract with defined deliverables. Payments to the vendor are made in line with delivery of services, either through periodic payments against service levels achieved, milestone, time and materials spent, or stage payments against deliverables achieved or an agreed billing schedule

• Independent Contractor:

  • Not the preferred contingent worker type, and should be used only in certain circumstances and by exception only.
  • To provide the service the vendor may require access to GitLab systems or services.
  • If the contract worker requires access to Okta and core GitLab applications, GitLab will provide the contingent worker with hardware.
  • If the contingent worker is not accessing GitLab data or GitLab services, an exception may be allowed via a managed GitLab provided endpoint.
  • Payment is made to the independent contractor based either on (1) a monthly time & hourly rate with a “Not To Exceed” total amount paid, (2) in accordance with an agreed upon payment schedule, or (3) a set total amount on the basis of achieved milestones and completion of agreed deliverables regardless of time.
  • Independent Contractors may include intellectual property which the vendor makes available as part of the service.

4. COUNTRY HIRING GUIDELINES

GitLab will only contract with contingent workers in India, the Philippines, and jurisdictions where GitLab has an entity. Contingent workers identified outside of these countries are considered not in policy. All contingent workers who need access to GitLab resources (Okta and core GitLab applications) will be required to use a GitLab provided laptop running either MacOS or ChromeOS.

Entity / PEO	Country
GitLab Israel Ltd.	Israel
GitLab Inc	United States of America
GitLab Federal, LLC	United States of America
GitLab GmbH Germany	Germany
GitLab PTY Ltd Australia	Australia
BV - Netherlands	Netherlands
BV - Belgium (branch)	Belgium
BV - Finland (branch)	Finland
GitLab Ltd	United Kingdom
Ireland Ltd	Ireland
France S.A.S.	France
GitLab Iberia S.L.	Spain
GitLab Canada Corp	Canada
GitLab Singapore Pte Ltd	Singapore
GitLab Korea Ltd	South Korea
IT BV	India
IT BV	Philippines

5. MISCLASSIFICATION RISK

The improper classification of contingent workers can result in significant legal and financial consequences for GitLab. It is critical that GitLab ensures that all contingent workers are properly classified to mitigate these risks.

6. RECOMMENDED USE OF CONTRACT WORKERS THROUGH A THIRD PARTY VS. INDEPENDENT CONTRACTORS

It is GitLab’s preference to use contract workers through a third party agency rather than independent contractors to mitigate misclassification risks. It is expected that line managers engage contingent workers through one of GitLab’s preferred third party agencies whenever possible, rather than use independent contract agreements, unless there is truly an independent consulting relationship. There are several advantages: (1) the relationship is between GitLab and the third party vendor as opposed to the worker, (2) duration can be more easily tracked, (3) more assurance that a vendor meets security requirements, (4) accelerated approval and background screening, and (5) the vendor is responsible for the proper withholding (Federal, state & local taxes, FICA).

7. DURATION OF RELATIONSHIP

As noted above, the length of the relationship has a correlation with the level of risk. The duration limit for contingent workers who are considered “consultants” may be beyond the 24-month standard duration depending upon the need. The duration limit for contingent workers who are considered “staff augmentation workers” is 24 months. This duration limit applies even if the contingent worker changes vendors or changes to “consultant” classification. After 24 months, contractors must have a minimum 3-month unpaid break in service. During the break the contractor’s access to all GitLab systems must be removed. After the 3-month absence is completed, the contractor’s time limit is reset and may provide services for a new assignment. This 3-month break in service applies even if the contract labor changes vendors or changes to “consultant” classification.

8. CONTRACTOR EXTENSION PROCESS (FOR CONTRACT LABOR CONTINGENT WORKERS ONLY)

If there is a need to extend the engagement of a staff augmentation worker beyond the initial term, the following process must be followed:

1. Request budget approval for extension to your FP&A Business Partner
2. Provide justification for the extension, including the project or task that the worker will be completing.
3. Once approval is obtained, then submit a Change Request in Zip to the existing Agreement/PO which is when Procurement would be notified to review.

Refer to Section 7 outlining the duration of relationship.

9. CONTRACTOR BACKGROUND SCREENING

GitLab will complete or verify a background check for all contractors requiring single sign-on access (SSO). If a contractor is employed by a vendor, agency, professional services provider, or other entity GitLab will seek proof of a completed background check or a signed attestation stating a background check that meets GitLab’s background check requirements has been completed. GitLab will review all background checks and attestations provided by a contractor’s employer to ensure that it meets GitLab’s minimum background check standards based on what is available in accordance with local law. In the event a contractor’s employer has not completed a background check, or the background check does not meet GitLab’s minimum standards, GitLab will require the contractor to complete a background check with GitLab’s background check vendor Sterling, and will ensure background checks are completed in compliance with local laws and regulations and seek the appropriate consent as needed.

Contractors will be allowed to begin their assignment at GitLab while their background check is pending completion. However, continuation of assignment at GitLab is contingent upon satisfactory background check results. The Sr. Background Check Specialist will monitor these background checks for completion, accuracy, and satisfactory results. Should any results of concern return on a contractor’s background check, GitLab will review these results to determine if there is a security and/or safety related risk posed to GitLab’s team members, customers, vendors, and/or overall business. If necessary, GitLab may address these results with the contractor directly and in certain instances with the contractor’s employer to determine continued suitability for assignment with GitLab.

GitLab’s minimum background check standards include a criminal records search and/or an extended global sanctions search where allowed by local laws and regulations. GitLab may also request prior employment history, identity verification, work authorization, and various other searches as needed based on the contractor’s location and assignment.

If GitLab has completed an assessment on a contractor’s employer in accordance with our Third Party Risk Management (TPRM) program and has received favorable results, additional verification of a background check may not be required. If the security team identifies any discrepancies in an employer’s background check policy, GitLab may complete a background check for the contractor to meet internal standards or request the employer complete an additional background check in accordance with our standards. A current list of sub-processors and professional services providers that meet this criteria can be located on this GitLab Legal handbook page.

Contractors returning to service at GitLab within 90 days of completion of their contract and contractors that receive a contract extension will not require an additional background check or re-verification of background check results.

Any additional questions regarding GitLab’s background check policy for contractors can be directed to backgroundchecks@gitlab.com.

10. QUESTIONS

For any questions regarding Zip, purchasing and contracting process, please contact the Procurement team @procurement_team in the #procurement slack channel. For questions regarding this policy or the engagement of contingent workers, please submit a HelpLab ticket.