The GitLab Procurement Team

1. You are here:
2. Finance
3. The GitLab Procurement Team

On this page

• What is Procurement?
• What is the Procurement Process at GitLab?
  • Procurement Team Alignment
  • Shared Goals
  • Metrics
    • Vendor cost avoidance
    • Percent (%) of vendor spend on Purchase Order
• New Zip tool launched 2023-02-01 for all Purchase Requests!
• How do I start the Procurement Process?
• When does procurement negotiate my contract and how long does that take?
• How do I create a Purchase Request in Zip?
  • Step 1: Obtain Zip Access
  • Step 2: Submit your Zip Request
    • Purchase Request
    • General Information
  • Step 4: Monitor Progress in Zip
  • Step 5: Congratulations on your Purchase Order (PO)!
• How long does it take to approve my Zip Purchase Request?
  • New Supplier Onboarding: 2-3+ Days
  • Negotiation: 1-3 Weeks
  • Security Review: 4-14 Days
  • PeopleOps Review: 1-4 Days
  • Privacy Review: 4-14 Days
  • Legal Review: 3 Days - 3+ Weeks
• What if I have an Urgent Request?
• How do I increase the dollar amount for an existing PO?
• What are the exceptions to the PO Policy?
• Vendor lifecycle management
  • Summary
  • Selection
  • Contracting
  • Negotiation
  • Security Review
  • Privacy Review
  • Onboarding
  • Recurring management and vendor review
  • Vendor Renewal Process
• Termination
• Third Party Risk Management
  • When do we require a financial viability check?
  • How do we ensure terms to establish GitLab (and our Vendors) rights and responsibilities?
  • How do we prevent disruption in customer service?
• Helpful Documents and Templates
  • Contract Templates
  • Documentation
  • Other Services

What is Procurement?

Procurement is the process of selecting vendors, strategic vetting, selection, negotiation of contracts, and the actual purchasing of goods. Procurement acquires all the goods, services, and work that is vital to GitLab.

What is the Procurement Process at GitLab?

Anytime a purchase is being made on behalf of GitLab that does not qualify as a personal expense, or meet the list of exceptions, a Zip Request must be submitted and fully approved BEFORE a purchase and/or work can begin.

Exceptions to the PO policy include, but are not limited to, purchases under $5,000 USD.

Procurement Team Alignment

Division alignment for spend over >$25k USD:

• Marketing - Ashley Abbate
• Sales - Ashley Abbate
• Product - Adrienne Ruhaak
• Engineering - Adrienne Ruhaak
• People - Adrienne Ruhaak
• Finance - Adrienne Ruhaak

• Legal - Adrienne Ruhaak

• All division spend <$25k USD - Dasha Yarmusik

• Individual Software Purchases - Anam Shaikh

Shared Goals

Procurement is a cross-functional team that supports GitLab as a public company. We have four key objectives monitored in the following ways:

1. Risk Management and Compliance
   • Reported and monitored via internal and external audit which gets reported to our shareholders.
2. Digital Automation and Efficiency
   • Reported via annual cost avoidance and year over year savings
3. Strategic Partnership and Department Spend Reviews
   • Reported through the twice annual NPS survey
4. Responsible Sourcing and Diversity
   • Monitored via Coupa Supplier Onboarding

Metrics

Vendor cost avoidance

Monitor the cost avoidance achieved through the procure to pay process. Cost Avoidance is the savings achieved off of the initial vendor proposal price. Note this is not directly tied to budget.

Aligns with the following core business objectives:

• Control spend and build a culture of long-term savings on procurement costs.
• Streamline the purchasing process.
• Minimize financial risk.

Percent (%) of vendor spend on Purchase Order

Percentage of all vendor spend for any department that is purchased via PO.

Aligns with the following core business objectives:

• SOX Compliance.
• Streamline the purchasing process.

New Zip tool launched 2023-02-01 for all Purchase Requests!

• Reasons why we chose Zip and the Business Case can be found here.

How do I start the Procurement Process?

• Before agreeing to any business, legal and/or pricing terms with a supplier, whether in conversation or email
• Immediately when you receive a contract and/or quote for new and/or recurring business
  • If you have received a contract from a supplier, tell them you will send to your procurement team for review
• When you have narrowed down your RFP to the final 1-2 suppliers
• Create a Purchase Request in Zip
• If unsure where to begin, tag the @procurement_team in the #procurement slack channel

When does procurement negotiate my contract and how long does that take?

• The procurement team negotiates SaaS contracts >$25K, and one-time contracts > $100K.
• Plan on the negotiation, review and approval cycle to take 3-4 weeks. Large and/or complex contracts can take longer to negotiate and finalize.
• If this step is not taken, purchase orders will not be approved until procurement is able to negotiate.

How do I create a Purchase Request in Zip?

If purchasing Home Office Equipment and/or Software for your individual work use <$5K USD, see Other Services Process since a Zip Purchase Request is not required in these instances.

Step 1: Obtain Zip Access

1. Login to Zip via your Okta home page.
2. If you need Zip access, submit an access request here.
3. Review Zip training materials:
   • Zip End Users Guide

Step 2: Submit your Zip Request

On the Zip homepage, click “New Requests” in the top right corner of the webpage. From there, you will have the option to request a Purchase, NDA, or Change Request, which will prompt you to fill in all the details about your purchase.

Purchase Request

General Information

1. Description & Category
   • Provide a brief description of your purchase and be sure to select the correct category and subcategories as needed.
   • “New” purchase would be any product or service that is brand new. “Renewal” would be any renewals or add-ons with an existing vendor.
2. Will a virtual card be used to pay this vendor?
   • This applies to instances where the supplier only accepts online credit card payments. More info on allowed uses here (link to new Virtual Card page)
   • If yes, select “Yes,” fill in the supplier contact information, and proceed with the request.
3. Vendor Name and Primary Contact
   • If an existing vendor or you are unsure, start typing the vendor name in Zip. If vendor exists, Zip will populate it in the dropdown. You can then select the existing Primary Vendor Contact or select ‘Add new contact’ and complete the the contact information
   • If New Vendor:
     • Review Vendor Selection Process and ping the #procurement slack channel if you would like support choosing a new vendor and/or executing an RFP.
     • When you fill in the details of your Zip request, you will be asked to fill in the supplier name. If this supplier is not already in our system, you will need to click the “add new” option once you type in the supplier name. Please be sure to fill in all details so that the procurement team can add the supplier to Coupa. While we use Zip internally now, Coupa will still be the tool used to pay our suppliers.
     • After you’ve submitted your request for a new supplier, the procurement and AP teams will review and approve within 1-2 business days.
     • If you need this escalated:
       • Tag the procurement team in the #procurement slack channel
       • Include link to the new supplier request and reason for escalation
       • Once the procurement team approves, the supplier will receive an onboarding email from Coupa requesting them to complete the onboarding process. This includes providing tax and banking information that only the supplier can provide.

Step 4: Monitor Progress in Zip

You can check the status of your Zip request at any time by looking at the approval flow chart in the “Overview” section of the request.

• Buyer Review: Procurement is checking to ensure all request details are complete and accurate. This will also include setting up any new suppliers in Coupa, which may take several days depending on the response time of the vendor.
• Security/Privacy/Legal/Buyer Negotiation: These steps can occur concurrently, and each team will conduct their review at the same time to reduce overall approval times.
• Final Buyer Review and Create Coupa Purchase Request (PR): Procurement will double check all request details and activate the Zip<>Coupa integration to create the Coupa request. Coupa requests now only require FP&A and management hierarchy approvals. The Zip requester will not need to take any action in Coupa.
• Coupa Approval and Execute Contract: Once Coupa approvals are complete, Procurement will send any relevant contracts for signature via DocuSign; signatories are determined by GitLab’s authorization matrix. Once the contract is fully executed by both parties, the procurement team will approve the Zip & Coupa Request, fully approving the Purchase Request and simultaneously releasing the Coupa Purchase Order (PO) to facilitate supplier payment.

Step 5: Congratulations on your Purchase Order (PO)!

1. Once the PO is generated, GitLab has officially placed an order for your purchase!! You may now begin work and/or obtaining the products/services.
2. The supplier will receive a copy of the PO order and number at the email address they supplied for Accounts Payable.
3. The supplier will receive communication from Coupa indicating how to make payment one of two ways:
   • Directly in their Coupa portal
   • Send invoice to ap@gitlab.com with PO number included on the invoice
   • Failure to follow these instructions will delay payment
   • Invoices uploaded to Coupa by a GitLab team member are not routed for payment.
4. If your request was new software, update the tech stack after the Zip Request is fully approved and the contract signed.

Congratulations and thank you for following this process to support GitLab as a public company!

How long does it take to approve my Zip Purchase Request?

As a general rule, plan on 5 Business Days to approve your Purchase Request for an existing supplier with standard terms, conditions, and low risk.

If your request requires negotiation, a vendor security review, and/or legal revisions, this will take longer as noted below.

Please plan accordingly and open your Zip Purchase Request allowing the cross-functional teams enough time to complete the review

If your request meets any of the below criteria, add the additional time noted for the activity to the 5 day baseline above:

New Supplier Onboarding: 2-3+ Days

• This is entirely dependent upon the suppliers response time.
• Once supplier information has been submitted in Zip and the Procurement team sets the vendor up in Coupa, the supplier receives an email from Coupa requesting banking and tax information to facilitate payment.
• The procurement team cannot complete this on the supplier’s behalf since we do not know this information. If we did, it would be a violation of SOX Compliance guidelines.
• If your supplier isn’t onboarded after 2 days, contact your supplier directly requesting they do so ASAP since their contract cannot be reviewed or approved until this is completed. Carbon copy procurement@gitlab.com

In the event two or more of the below activities are required, they will happen in parallel to one another:

Negotiation: 1-3 Weeks

• Required for: SaaS contracts >$25K, and one-time contracts >$100K.
• Turn time is based on the level of negotiation required and the suppliers willingness to meet budget and benchmark indicators.

Security Review: 4-14 Days

• Security Third Party Risk Management reviews are required for vendors that collect, process, or store Orange / Red Data, software providers (SaaS and On-premise), and independent contractors / consultants. (Excluding field marketing events)
• This activity cannot begin until after the supplier completes the security questionnaire and supplies their security documentation. Oftentimes, it can take 1-2 weeks for the supplier to respond and complete the requested materials. The security review SLA begins once that is completed. Time before this activity can begin is entirely dependent upon the supplier's response time and maturity of security protocols.
• TIP: To increase speed of approval, upload any security compliance documentation (SOC-2 Report, ISO27001 Certificate) to the ZipHQ Request and notify your supplier contact they will be receiving a request from ZenGRC for completion ASAP.
• For any inquiries and questions, please tag @securityrisk in the #procurement slack channel.

PeopleOps Review: 1-4 Days

• PeopleOps serve as reviewers on all professional services requisitions to determine if a background screening is necessary.
• Per GitLab's People Policies contractors are subject to complete a background screening. GitLab will accept a completed background screening from a contractor's employer. However, if a background screening was never conducted GitLab will either complete one or ask that one be completed.
• Approval will occur once proof of a completed or an initiated background screening has been shared or once the contractor has submitted their background screening for processing.
• The Sr. Background Check Specialist will only follow up if a result of concern returns on the background screening.
• Questions and/or proof regarding background screenings on professional service requisitions in Zip can be sent to backgroundchecks@gitlab.com.

Privacy Review: 4-14 Days

• This activity begins after the supplier completes a Privacy and Trade Compliance Assessment form and a Transfer Impact Assessment Form (where personal data is transferred from the EU to the U.S.) Oftentimes, it can take a week for the supplier to respond and complete the requested forms. The SLA begins once that is completed.
• Time before this activity can begin is entirely dependent upon the supplier's response time and whether a DPA/SCCs are required.
• A Privacy Review is required for all SaaS purchases and other purchase types where the supplier will receive from GitLab or collect on GitLab's behalf red/orange data.
• A DPA/SCCs are often made part of the agreement with the supplier. Generally, Privacy would prefer to use our DPA/SCCs but if the the supplier provides their DPA/SCCs as an exhibit to the main agreement, Legal and Privacy may use the supplier's version to arrive at a final agreed upon version. Procurement will obtain executed versions of DPA/SCCs in the Final Buyer Review stage.
• TIP: To increase speed of approval, add a link to the suppliers privacy notice; upload the suppliers Transfer Impact Assessment Guide; and upload a word version of their DPA/SCCs if the supplier requuests us to use their version.

Legal Review: 3 Days - 3+ Weeks

Note: The amount of time for review, and to reach execution, is based on the details below. Use these SLA's as guidelines, noting that each contract review process is unique and if additional terms, requirements, and/or risks are identified the timeline for completion may be extended

• Existing Vendors: 3-5 Days
  • If new terms, and/or risks are introduced or required, this may take longer.
  • Any delays from the supplier, will delay final approvals.
• New Vendors: 1-3+ weeks
  • If vendor doesn't readily accept the GitLab standard terms, additional rounds of red-lines and negotiations may be required, extending this SLA.
  • Whenever possible, the legal team hopes to achieve red-lines–to be provided back to the vendor–no later than five (5) business days after being assigned.

Types of Vendors

• Net New:
  • These require the most amount of time as GitLab will be establishing (for the first time) terms and conditions which will govern the use of the products and/or services being procured.
  • Negotiations can vary from 1 week to multiple months based on the level of detail and modifications required to reach executable terms.
• Renew / Upsell:
  • These generally require much less time as existing terms are in place which will underline the products and/or services being offered.
  • That being said, in the event GitLab where to add a new product and/or service (from an existing Vendor) additional cycles may be required in order to create amendment(s) to the existing agreement.
• One-time Transaction:
  • These generally require much less time as existing terms are in place which will underline the products and/or services being offered.

Types of Agreements (generally broken into three (3) categories)

• Software (SaaS & On-Prem): Requires the most rigorous review to ensure the rights and obligations placed upon GitLab are, (i) reasonable given the Software being provided, and (ii) align with GitLab contracting and industry standards.

• Professional Services / Training: Requires detailed review to ensure intellectual property ownership aligns with our intentions, as well as, reasonable obligations being placed upon GitLab.

• Marketing / Events: Generally, requires the least amount of time to review as the obligations are standardized given the event in question and program provided. Details regarding events may include negotiations with regards to Force Majeure, cancellation (including penalty), and ensuring the terms of the Agreement align with those of the requesting GitLab Team Members.

• Data Processing Agreement (DPA)/Standard Contractual Clauses (SCCs): Required when personal data is shared with, accesssed, or collectd by the supplier on behalf of GitLab. DPA/SCCs are generally affixed to an agreement but may be required as a separate agreement upon the determination of Privacy.

Additional Details

• As discussed above, the turnaround time for the review of an Agreement is contingent on many factors. The goal of the legal team is to review and provide red-lines as thoroughly and promptly as possible.

• The ability for GitLab to process and work efficiently through an agreement negotiation relies on the vendor, and vendor counsel, to respond promptly to GitLab red-lines and comments.

What if I have an Urgent Request?

If you are unable to plan and have a legitimate reason to escalate a purchase request, follow the process below.

• Post in #procurement slack channel request for escalation with:
  • Link to your Zip Request
  • Date needed
  • Specific and quantifiable impact to the business if date is missed.
    • "Supplier wants it signed today" does not qualify as a reason for escalation and these requests will be denied.
    • "Price will increase $45K if not signed by Friday" or "Material negative brand impact if not signed by Friday due to missed PR deadlines" are specific, tangible, business impacts that will be reviewed.
• Truly urgent and business critical requests will be evaluated, please note these are disruptive to our workflow and our ability to meet SLA's for requests opened on time.
• We may or may not be able to accommodate your urgent request based on the risk and bandwidth available.
• When you know you have a critical request with a deadline, enter the request into Zip 1-2 weeks prior to needing approval to avoid needing escalation. Do this even if the contract isn’t final yet to help expedite the process.

How do I increase the dollar amount for an existing PO?

• If you have a PO with an existing supplier and the cost has increased, you can update the existing PO for the new dollar amount.
• When you log into Zip and select “New Request,” you will see an option to “Request a Change (amend contract or PO change)”
• Fill in all the required information and the Procurement team will amend the PO in Coupa on your behalf.
• Attach supporting documentation from the supplier for the change in amount. This could be a SOW, Change Request, and/or Order Form based on the purchase type.
• This will require the same approvals as a net new request.

What are the exceptions to the PO Policy?

Exceptions to the PO Policy are:

1. Purchases under $5K
2. Charitable Contributions (Donations)
3. Computer/Hardware Advances (if unable to be paid through Payroll Dept)
4. Interview Candidate Reimbursement
5. Legal Fees
6. Audit, Tax, and Insurance Fees
7. Benefits, PEO Providers and Payroll
8. AR/Customer Refunds
9. Board of Director Payments
10. Financing, Banking and Investing (incl interest, debt, FX, fees)
11. Corporate Credit Card
12. Urgent Payments not included on list above (approval required from VP, Corporate Controller and/or PAO)

Vendor lifecycle management

Summary

The procurement team is responsible for ensuring there is a process for vendors to be managed throughout the lifecycle from: - Selection - Security Review - Contracting - Negotiation - Onboarding - Recurring management and vendor review - Vendor Renewal - Termination

Selection

Please review the below guidelines:

1. Review the market capabilities defined by your overall spend before selecting your vendor.
2. Before sharing details and/or confidential information regarding GitLab business needs, obtain a Mutual Non-Disclosure Agreement from the potential vendor (s). Refer to the Signature Authorization Matrix for signing authority.
3. Use a scorecard to compare vendor capabilities and/or response to RFP.
   • Supplier Evaluation Scorecard Template
4. All vendors must adhere to the GitLab Partner Code of Ethics. It is mandatory all vendors contractually adhere to this if they would like to do business with us. (Note these are typically not required in event related agreements unless the vendor is providing services).
5. Identify your bid requirements based on your estimated spend. This applies to all new vendor spend, not existing suppliers:
   • $0 - $100K: No Bid
   • $101K - $250K: 2 -3 Bids
   • Greater than $250K: RFP

Contracting

All work that is done with a vendor must have a completed contract to be compliant and work may not be completed until a contract is in place. Contracts include NDAs, Master Service Agreements and Statements of Works. Our legal team assists with this step in the process. Please see the legal review process for more details. Additionally, please note that a small number of team members can sign agreements on behalf of GitLab - please see the authorization matrix for more details.

Negotiation

Procurement team can assist you in your negotiation. The goal is to get the best price inline with benchmarks.

Security Review

All vendors require a security review. Please see the details of SLA and how to complete this process in our Zip documentation section.

Privacy Review

All vendors processing Personal Data require a privacy review. A full privacy review is only required every 24-months, provided the Vendor completed a full and satisfactory privacy review during the prior procurement cycle. Please see the details of SLA and how to complete this process in our Zip documentation section

Onboarding

In order for your vendor to be able to be paid they need to be onboarded into our systems. The details are in our Zip documentation section.

Recurring management and vendor review

The business owner must run an annual business review with vendors who meet the following criteria: - Over $100K in annual spend - Is up for renewal

The business owner must run a bi-annual business review with vendors who meet the following criteria: - Over $500K in annual spend - Is mission critical software

The business review must cover: - Success criteria of the contract - What is going well - What can be improved - Review of any issues and remediation expected

Vendor Renewal Process

The procurement team should pull a list every quarter of a rolling 12 month renewals. The source system for this pull is XXX. The list should be reviewed and prioritized with the business owners. The renewal process should start at least 90 days ahead of the renewal date providing ample time to review the terms and decide: - Are there any additional security requirements for the vendor? - Has the vendor had an RFP for pricing in last 3 years? - Do we want to terminate or reduce spend and need to proactively notify per the contract? - Do we want to change any terms of our contract?

Termination

As part of the renewal process if it is deemed necessary to terminate an agreement that is not Statement of Work based such as a contractor or professional service engagement. The following steps should be taken.

1. Termination questionnaire should be filled out by the business a. Reason for termination (i.e. no business need, vendor underperformance, new system, etc) b. Data management such as data migration, data retention and deletion c. Timing for the termination d. Notification requirements for the termination e. Costs related to termination f. Communication plan to team members (if necessary)
2. The legal team should be notified and the existing contract should be reviewed to be able to understand our obligations to cleanly terminate
3. The procurement team should be engaged to handle any notifications or vendor communications

Third Party Risk Management

The procurement team from a compliance and risk perspective has developed a process to handle third party risk to reduce the risk of the following: - Financial Fraud or exposure created by third party behavior such as data leakage, security breach, business continuity, etc - Failure of financial viability of third party impacting delivery - Reputational damage arising from third party behavior - Breach of regulation or law through third party action - Disruption in customer service due to third parties

When do we require a financial viability check?

When all of the following is met: - Vendor is private company, LLC or self-employed - Services provided are required for continued operations - Cloud hosting services - Services directly related to servicing customers with an uptime requirement - Storage of data that is not recoverable if vendor goes out of business - Software or services where it would take over 1 week to replace or swap

How do we ensure terms to establish GitLab (and our Vendors) rights and responsibilities?

Any time GitLab engages with a third party for the procurement of goods and/or services, which require GitLab to engage in a contract, the GitLab Legal Procurement team will review the terms and conditions. The purpose of this team is to review the contract which GitLab will enter into, and ensure the following: - Terms and conditions which are fair and reasonable given the type(s) of products and/or services being procured; and - Adequate obligations on behalf of GitLab vendors to ensure compliance with, (a) GitLab’s Code of Conduct and other company policies, (b) applicable laws, rules and regulations (including protection of personal data), and (c) the delivery, support and provision of goods and/or services In addition to ensuring terms and conditions, the GitLab Legal Procurement team collaborates frequently with procurement and business stakeholders to ensure any (and all) contracts align with the needs of the team. The GitLab Legal Procurement team addresses the needs of stakeholders ranging from complex technical application and platform services, to creating and drafting event contracts to meet the needs of GitLab events.

How do we prevent disruption in customer service?

Agreements, as GitLab does with its own customers, include obligations that vendor’s have to GitLab. These can include uptime / downtime commitments (for SaaS providers), SLAs (for support), termination rights, and other commercial contract provisions which would enable GitLab to seek relief in the event of disruption

Helpful Documents and Templates

Contract Templates

• GitLab Vendor Terms and Conditions
• Logo Authorization Template
• Data Processing Addendum (unlocked for editing)
• EU Standard Contractual Clauses
• US Contractor Agreement
• SOW Template
• Change Request Template

Documentation

• Non-Disclosure Agreement (NDA) Process
• Certificate of Insurance Request Process
• Uploading Third Party Contracts to ContractWorks
• Company Information - general information about each legal entity of the company
• Trademark - information regarding the usage of GitLab's trademark
• Authorization Matrix - the authority matrix for spending and binding the company and the process for signing legal documents

Other Services

• Home Office and Supplies
• Individual Use Software
• Vendor Selection Process
• Vendor Terms and Conditions
• Non-Disclosure Agreement (NDA)
• Charitable Contributions
• Non-Cost Related Agreements (Including Trials/Demos)