Procurement Guide: Collaborating with GitLab Legal

Thank you for visiting! The purpose of this resource is to provide GitLab team members with information on how legal assists and supports with the procurement of products and services at GitLab.

For information on the GitLab Procurement Team, policies and process, visit The Procurement Handbook Page.

For general questions that do not require legal advice, deliverables, or any discussion of confidential information, you can reach out to the GitLab Legal Team in slack at #legal or the GitLab Procurement Team in slack at #procurement.

You don’t need to reach out to GitLab Legal directly. The GitLab Legal Team will be engaged directly by the Procurement Team, as applicable.

GitLab Legal will review any and all purchases made to ensure adequate legal terms are present for GitLab to ensure alignment with GitLab’s risk standards. Examples of types of purchases include, but are not limited to:

  • Software Agreements;
  • Professional Services Agreements;
  • Sponsorship Agreements;
  • Event Contract;
  • Hotel Contracts; and
  • Subcontracting Agreements (staff augmentation or providing services/resources to GitLab and/or GitLab customers)*.

*Note: Additional policies regarding some purchases may apply. Please ensure that you work with the GitLab Procurement Team to ensure that your purchase is in compliance with policies and process. For more information, please visit The Procurement Handbook Page.

Signing Contracts

DO NOT SIGN ANY CONTRACTS

  • Only authorized individuals can execute contracts on behalf of GitLab. Please view the Signatory Matrix for who may sign.
  • In order to be executed, all Contracts must include the GitLab Legal stamp. This stamp confirms that the Contract has been reviewed and approved by a Legal Team Member. If you do not receive a GitLab Legal stamped version of the Contract, please ask the Procurement Team Member for assistance.
  • If you accidentally sign a contract or become aware of a contract that was signed by someone without authority, please immediately report it to the GitLab Procurement Team so that GitLab Legal can be engaged.

Vendor Requirements

Procurement Requests & Additional Information

NDA Request(s): NDA Process

Negotiating Terms and Conditions: Negotiating Terms

Use of competitors’ services: Guidelines (Internal only)

NDA Process

  • Prior to exchanging any confidential information, GitLab and a potential Vendor should execute a Mutual Non-Disclosure Agreement. This will ensure the adequate protection of any / all information shared.
  • Follow the Non-Disclosure Agreement process to send an NDA via DocuSign or request one if you do not have DocuSign access.
  • NOTE: GitLab should push to have the vendor accept or use GitLab’s template as the purchasing party. If a potential vendor requires the use of their NDA template after seeking use of the GitLab template, please follow the process located on the Procurement Page which will initiate the legal review process.

Negotiating Terms

  • For any purchases made by GitLab, there must be executed terms and conditions in place before a purchase can be made or before services can be provided.
  • Making a purchase and/or receiving services without executed terms and conditions in place is prohibited by GitLab procurement policies and could expose GitLab to substantial and unintended risk.
  • In the event a vendor is providing services which include accessing, processing or controlling GitLab data, the GitLab Legal team may require the vendor to provide the list of sub-processors relevant to the services provided to GitLab. In addition, based on the data made available to the vendor, a DPA may be required, which will be engaged by the Privacy team.
  • For more information regarding purchase requests, GitLab Templates and our negotiation thresholds, please visit the Procurement Handbook Page.

GitLab Legal Engagement & Best Practices

  • Detailed instructions on how to start the procurement process can be found on the Procurement Handbook Page.

  • When a request has been properly submitted there are a number of different approvals that are required before it is ready for legal review.

  • Once a request has been approved by the various procurement stakeholders, it will be assigned to a Legal Procurement team member (This member’s name will be attached to the ‘Legal review’’ node, and this member will assist with the r review and approval for that specific request. When submitting a request in Zip, please keep in mind the following:

    1. The request will sit under the status “Ready to Start” within the legal review node once it has been approved by the various procurement stakeholders, as applicable;
    2. A Legal Team Member will be assigned to the request, and change the status to “In Progress”.
    3. GitLab Procurement Legal monitors the queue throughout the day and the request will automatically be assigned and prioritized by on submission time and urgency. Please avoid tagging individuals or posting in slack that an agreement is “Ready to Start” as the queue is continuously monitored.
    4. The request may have additional review nodes, including ‘Privacy’, ‘Security’ and ‘Buyer Negotiation’, The Legal Procurement team has no control or approval authority within these additional nodes, as separate Team Members and SMEs own these review and approval nodes.
    5. The requester should ensure all relevant documents are attached to the documents tab within the request, and any relevant information added as a comment within the request, otherwise, this may cause delay or issue with the timely processing of the request.
    6. When the status is set to “In Progress” by the Legal Procurement team member, the requester will know the request is under active review.
    7. Redlines (amended review applied by the Legal Procurement team member) to the documents attached to the request (if applicable) will be attached and saved under the original version of the document(s) provided by the Legal Procurement team member in the Request.
    8. Legal Procurement team members will notify the requestor through a tag and comment within the ZIP when (i) a review is completed or (ii) redlines are ready to be sent by the team member who created the request to the potential contracting party.
    9. It is the responsibility of the team member who created the request to establish communications and relevant documents with the Legal Procurement team member and the potential contracting party.
    10. Once agreeable terms are achieved, the Legal Procurement team member will attach a clean PDF version (named “Executable” to start) with the GitLab Legal stamp of approval.
    11. Once the ‘Legal review’ node is approved, the Legal Procurement team have no further actions and the request will continue through other approvals.

  • Contact the Legal Procurement team member by tagging them directly in the GitLab Procurement Tool, the Legal Procurement Team member must be directly tagged in order to receive a notification on the request.

  • Please avoid tagging the Legal Procurement team member in Slack unless an urgent matter arises, the team work on many high volume requests at any one time, and the GitLab Procurement Tool should be used as the single source of truth.

Requesting a Certificate of Insurance

  • To request a COI, please use your existing procurement request and tag the Legal Team member assigned (if applicable), or not active request exist, open an issue in the Legal and Compliance project using the general legal template. Be sure to apply the legal-procurement::to do label and tag @dcolesjr, @chilling32, and @ndjohnson in your request.
  • For requests related to a customer or partner, open a Legal Request in SFDC.

Helpful Resources

  • Many Vendors require basic information about GitLab to be setup as a Customer, visit Company Information for general information about each GitLab legal entity
  • GitLab’s W9 can be found on the Finance Page
Last modified August 14, 2025: Links to Internal HB corrected (dd0db567)
View page source - Edit this page - please contribute. Creative Commons License