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:

• Agency/Staff Augmentation Workers
• Vendor Managed Services
• Independent Contractors
• Professional Services Partners

Definitions:

Agency/Staff Augmentation Workers:

Definition: A staffing agency for staff augmentation is a third-party company that employs workers and assigns them to work at GitLab to supplement GitLab’s existing workforce on a temporary basis. The agency serves as the legal employer, handling all employment responsibilities, while the workers perform their duties under the direction and control of the client organization.

Key Characteristics:

Legal employer relationship: Agency employs the workers as employees

• Client direction: Workers take day-to-day direction from GitLab
• Temporary placement: Workers are assigned to fill specific roles or projects
• Full employment services: Agency handles payroll, benefits, taxes, and HR functions
• Scalable solution: Allows GitLab to quickly add or reduce workforce capacity

Agency Responsibilities:

• Recruiting and screening candidates
• Employment compliance and legal obligations
• Payroll processing and tax withholdings
• Workers’ compensation and unemployment insurance
• Benefits administration (health insurance, vacation, etc.)
• Performance management coordination with client

GitLab Responsibilities:

• Providing work direction and supervision
• Setting work schedules and performance expectations
• Providing necessary equipment
• Coordinating with agency on performance issues
• Paying agency fees (which include worker hourly wages plus markup)

Employment Classification Risks:

• Medium risk - Co-employment concerns if GitLab exercises too much control over employment terms
• Risk of joint employer liability for wage/hour, benefits, and discrimination claims
• Agency responsible for payroll taxes,
• If the worker ultimately is converted to a GitLab employee, the time spent serving as a contractor is often included in the worker’s employment tenure for certain statutory rights, such as FMLA.

Vendor Management:

• Manage agency relationship, not individual workers; performance managed through agency
• Payment Flows: GitLab pays agency, agency pays workers as W-2 employees

What GitLab CAN Do:

• Direct daily work activities and tasks
• Set work schedules and hours
• Provide equipment
• Give detailed instructions on how to perform work
• Include in team meetings and collaboration as necessary, but not in any meetings where the information must follow SAFE guidelines
• Manage performance directly
• Control work methods and processes
• Assign supervisors from GitLab staff
• Require time tracking and attendance

What GitLab CANNOT Do:

• Hire or fire the worker directly (must go through agency)
• Set compensation rates directly
• Provide employee benefits (agency’s responsibility)
• Handle disciplinary actions without agency involvement
• Make employment decisions (promotions, raises) directly
• Control worker’s other employment relationships
• Direct training on employment law/HR matters

Length of Service Considerations:

Varies by jurisdiction and agency policies

Common Industry Practices:

• 12-24 months typical maximum before conversion consideration
• Some agencies cap at 12 months to avoid co-employment risks
• Regional laws vary - some regions and US states have specific timeframes triggering benefits eligibility

Risk Factors with Extended Placements:

• Co-employment liability increases with duration
• Benefits obligations may be triggered by state law
• Equal treatment expectations - long-term staff aug workers may expect employee-like treatment
• Conversion pressure - agencies often push for conversion to permanent placement

Best Practices:

• Check agency policies - Many have built-in conversion requirements
• Regional law compliance - Review local country/state regulations on temporary worker rights
• Conversion planning - Have clear criteria for when to convert to FTE
• Regular reviews - Assess business need and classification appropriateness quarterly

Vendor Managed Services

Definition: Companies under Master Service Agreement (MSA) that deploy their own employees to deliver services to GitLab.

Employment Classification Risks:

• Lowest risk - Vendor is the employer, handles all employment obligations
• Risk limited to ensuring the vendor has proper worker classification
• Should verify vendor’s employment practices and insurance coverage

Vendor Management: Strategic partnership management, SOW development, deliverable oversight

Payment Flows: GitLab pays the vendor (typically fixed fee with payments based on mutually agreed upon deliverables or milestones), the vendor pays workers

What GitLab CAN Do:

• Define project requirements and deliverables
• Set project timelines and milestones
• Approve or reject vendor’s proposed team members
• Request specific skill sets for assigned workers
• Provide project direction and feedback
• Monitor project progress and quality
• Require status reporting from vendor
• Set performance standards for deliverables
• Request team member replacements through vendor

What GitLab CANNOT Do:

• Directly supervise individual workers daily
• Set individual work schedules for individual workers
• Provide HR direction to individual workers
• Handle performance reviews of individual workers
• Direct training unrelated to project requirements
• Control vendor’s employment decisions
• Manage payroll or benefits for individual workers
• Exercise disciplinary authority over individuals

Independent Contractor (option not preferred, used by exception only)

Definition: Self-employed individuals providing services under direct contract with GitLab.

Employment Classification Risks:

• Highest risk - Direct misclassification exposure if the worker is deemed an employee
• Must pass the IRS 20-factor test and behavioral/financial/relationship control tests
• GitLab bears full responsibility for proper classification
• Violations can result in back taxes, penalties, and benefits obligations

Vendor Management: Direct relationship management, contract negotiation, performance oversight

Payment Flows: GitLab pays contractors directly, issues 1099-NEC

What GitLab CAN Do:

• Define the outcome/deliverable required
• Set deadlines for completion
• Provide project specifications and requirements
• Request status updates and progress reports
• Reject work that doesn’t meet agreed specifications
• Terminate for non-performance per contract terms
• Set quality standards for deliverables

What GitLab CANNOT Do:

• Control how the work gets done (methods, processes, tools)
• Set daily work schedules or require specific hours
• Mandate where the work is performed
• Require use of GitLab’s equipment/software (unless industry standard)
• Provide detailed step-by-step instructions
• Require regular check-ins or micromanage progress
• Control who else the contractor works for
• Direct training on how to perform the work
• Include the contractor in employee meetings/activities
• Provide employee benefits or perks

Length of Service Considerations

• No legal cap, but practical risk increases over time
• Risk Factors with Long-term Relationships:
  • Economic dependence - If the contractor becomes financially dependent on GitLab (primary income source)
  • Integration patterns - Extended relationships can blur into employee-like arrangements
  • Government scrutiny - Multi-year relationships draw more attention during audits
  • Behavioral drift - Tendency to treat long-term contractors more like employees over time

Best Practices:

• Project-based renewals - Structure as discrete projects rather than ongoing retainers
• Regular relationship audits - Review every 12-18 months to ensure compliance
• Clear project boundaries - Each renewal should have a defined scope and deliverables
• Avoid automatic renewals - Each extension should be intentionally evaluated

Professional Services Partners

Definition: Third-party companies providing specialized services related to GitLab implementations/projects, with flexible payment models.

Employment Classification Risks:

• Low to Medium risk depending on payment model
• GitLab-paid: Similar to vendor model but may have less control over worker selection/management
• Customer-paid: Minimal direct employment risk to GitLab, but potential liability if GitLab exercises significant control

Vendor Management:

• GitLab-paid: Full vendor management including contract terms, performance metrics
• Customer-paid: Lighter touch - certification, enablement, relationship management

Payment Flows:

• Model A: GitLab pays partner directly under MSA/SOW
• Model B: Customer pays partner directly, GitLab manages relationship/standards

What GitLab CAN Do:

• For GitLab-paid partners:

  • Set project scope and deliverables
  • Define quality standards and requirements
  • Provide technical specifications
  • Request progress updates
  • Approve project milestones
  • Require certifications or qualifications

• For Customer-paid partners:

  • Provide product training and certification
  • Set partnership standards and requirements
  • Offer technical support and resources
  • Monitor customer satisfaction
  • Manage partnership relationship

What GitLab CANNOT Do:

• For GitLab-paid partners:
  • Directly manage individual consultants daily
  • Control internal business operations
  • Set employment terms for partner’s staff
  • Require exclusive relationship (unless contracted)
• For Customer-paid partners:
  • Control project execution directly
  • Direct individual consultants
  • Set billing rates to customers
  • Exercise supervisory authority
  • Guarantee payment (customer’s responsibility)

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

Contingent workers must have a completed or verfied background screening before onboarding with GitLab. Background screenings will be monitored for completion, accuracy, and satisfactory results. Should any results of concern return, 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 contingent worker directly and in certain instances with the contingent worker’s employer to determine continued suitability for assignment with GitLab.

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

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

Contingent worker’s returning to service at GitLab within 90 days of completion of their contract and contingent workers that receive a contract extension will not require an additional background screening or re-verification of background screening results.

Any additional questions regarding GitLab’s background screening policy for contractors can be submitted in HelpLab.

10. QUESTIONS

For any questions regarding this policy, the Zip tool, or the purchasing and contracting process, please contact the Procurement team @procurement_team in the #procurement slack channel.

For additional information, see this Information Guide for an overview and frequently asked questions.