The GitLab Procurement Team

What is Procurement?

The Procurement team manages GitLab’s Supplier Lifecycle through the process of strategically vetting and selecting vendors, negotiating commercial terms, the purchasing of goods and services, and managing the renewal or vendor offboarding process.

Procurement Team Alignment

Division alignment for spend over >$25k USD / year:

• 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. Strategic partnerships with business stakeholders - meet on a quarterly basis to review new or renewing third party spend and supplier management opportunities
   • Metric(s): Supplier segmentation tiers
2. Achieving annual cost avoidance (soft) savings and year over year (hard) savings
   • Metric(s): Soft Savings (cost avoidance) is mitigating proposed cost increases or any negotiations for new purchases. Hard Savings (year over year) is a decrease in cost from last year and is only valid for renewals. This can include decreasing unit costs, removing users and/or scaling back services and scope
3. Third party risk management and ensuring we are getting the best commercial terms with the least amount of risk for GitLab
   • Metric(s): the number of active and new vendors each quarter, and reported and monitored via internal and external audit
4. Responsible sourcing/purchasing and supplier diversity - managed through the Zip and Coupa onboarding and purchasing process
   • Metric(s): Zip SLAs and diverse suppliers

Vendor Lifecycle Management

The Procurement team is responsible for ensuring there is a process for suppliers to be managed throughout their lifecycle of doing business with GitLab from initial selection and contracting to recurring reviews and renewals to cancellation.

1. RFP and Vendor Selection

All new spend, changing of vendors for existing services, and market reviews every 3 years for existing contracts should follow the RFP and Vendor Selection process, unless approved by your Procurement Category Manager, to ensure we are choosing the best partner for GitLab with the best commercial terms. This must be done prior to verbally agreeing to terms or contracting with any new or existing vendor.

• Follow the RFP process outlined in the internal handbook. You will find resources and templates for RFP events at any level, whether it is a quick bid or a full procurement-led RFP with 5+ vendors. Always reach out to your Procurement Cateogry Manager to notify them that an RFP is being conducted- they can assist in the process and can answer any questions.
  • As part of this process, create an issue with the RFP Intake template and tag your Category Manager.

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.

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).

2. Negotiation, Privacy and Security Review

Depending on the amount of spend, Procurement will assist or lead in negotiating the pricing and commercial terms of the contract.

Depending on the types of data shared with the vendor, Privacy and Security will need to complete a review of the vendor

For more information on these requirements and steps, see the Review Steps, Timeline, and Considerations section

3. Contracting

All work that is done with a vendor must have a completed contract to be compliant and work may not be started 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.

4. Vendor Onboarding

In order for vendors to be paid, they need to complete their onboarding in our systems. Please see the New Vendor Onboarding section for more details.

5. Recurring Vendor Reviews and Management

Procurement will work with you through the Quarterly Procurement & Business Spotlights to review upcoming renewals and cancellations, new spend projects, and identifying vendor’s segmentation tier: Strategic, Niche, Commodity, or Transactional.

Identifying the Segmentation Tier your supplier(s) falls within helps determine the right vendor management approach, e.g. renew the contract, RFP, business reviews on a recurring cadence, continuous improvement plans, etc.

If holding a business review with a vendor, the following topics should be discussed:

• Success criteria of the contract
• What is going well
• What can be improved
• Review of any issues and remediation expected
• Overview of the contract and its utilization

Vendor Renewals

On a quarterly basis, the Procurement team will meet with business stakeholders in each department to review a rolling 12 month list of renewals, focusing on the upcoming 2 quarters. This list is pulled from Zip and Coupa. 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?

6. Cancellation

The following methods will be used to capture cancellations (which include terminations and/or non-renewals):

1. Automated Notice: The DRI for the purchased item will receive notification of an upcoming renewal;
2. Procurement Led: The Procurement Team will review upcoming renewals, and active purchases, during the quarterly “Category Spotlight” meetings.
3. DRI Led: DRI’s and other stakeholders may determine that products, events and/or services are no longer needed.

For each of the above, if a cancellation is desired (which include terminations and/or non-renewals) please follow the “Cancellation Process” outlined below:

1. Submit a Termination/Non-Renewal Request through Zip by completing the intake form and providing copies of the existing contract(s) that you are canceling.
2. Through Zip, Procurement and Legal will work with the requester to provide instructions on how, when, and who should notify the vendor. For most non-renewal notices, the business owner will notify the vendor via Legal’s guidance.
   • Security and Privacy will also be added for awareness and review if data is being shared with the vendor to determine the requirements of returning or deleting the data.
3. For certain cancellation requests, like Software for example, IT will be included in the Zip workflow to determine and complete the proper deprovisioning and system offboarding requirements. This includes removal of the system from our Tech Stack.
4. If necessary, the requester and/or business owner will need to create and execute on a communication plan to notify all or impacted team members of the cancellation.

Upcoming terminations/non-renewals should be discussed with Procurement during the Quarterly Category Spotlight meetings that Procurement holds with category leads/budget owners. As Procurement is made aware of upcoming cancellations during these meetings, Procurement will review on a quarterly basis any known cancellations with Legal to ensure notification requirements are met. Procurement and Legal will then work with the business owner on completing the above process. If a cancellation is determined outside of this quarterly cadence, notify your Procurement Category Manager and complete the above process as soon as possible.

The Procurement Process

Anytime a group of suppliers are being evaluated for services/goods or a purchase is being made on behalf of GitLab that does not qualify as a personal expense or meet the list of exceptions, Procurement must be engaged BEFORE a purchase and/or work can begin. Start the Procurement Process

1. Before agreeing to any business, legal and/or pricing terms with a supplier, whether in conversation or email
2. 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
3. When evaluating a group of suppliers and/or starting the RFP Process.
4. If unsure where or when to begin, tag the @procurement_team in the #procurement slack channel for support. You can also reach out to your Procurement Category Manager directly.

How to start the Procurement Process

Majority of the Procurement Process lives within our Procurement system called Zip. You can access Zip via your Okta home page, or if you need Zip access, submit an access request here.

For more Zip training materials, review the Zip End Users Guide and the Tips for Submitting a Zip Request page.

Depending on a few factors of your purchase, there are different ways to engage Procurement and start the Procurement process:

1. Submit a Zip Request for
   1. Purchase Requests for renewals of existing vendor’s services
   2. Purchase Requests for new spend under $25k
   3. Change Requests to existing POs
   4. $0 contract reviews including demos and trials
   5. Partner Revenue Payments
   6. Individual Use Software
   7. Providing Termination or Non-Renewal Notice
2. For new spend, changing vendors for existing services, or after 3 years of renewing a service, follow the RFP Process
   1. Over $250K: Procurement led RFP, typically 5+ vendor bids
   2. $100K - $250K: Business led RFP, 2-3 vendor bids required
   3. $25K - $100K: Business led quick-bid, 2 vendor bids required
   4. Under $25K: no bid required

Review Steps, Timeline, and Considerations

Requests can take 5 days to 3+ weeks for processing depending on a number of factors that will impact the time for review of a Purchase Request including, but not limited to:

1. New or existing vendor
2. If negotiation is required
3. Types of data being shared with the vendor and if Security and Privacy need to review
4. Contract complexity and alignment with GitLab’s Vendor Terms and Conditions
5. Vendor’s response time and willingness to negotiate

Each review’s targeted approval time is outlined below, but as mentioned above, this is dependent on many factors and the accuracy and completeness of information provided by the requester. If your request meets any of the additional approval criterias outlined below, please plan accordingly and submit your Zip request allowing each cross-functional team enough time to complete their review. Please follow the steps outlined for urgent requests that cannot meet the below timeline and have specific and quantifiable impact to the business.

1.A. Buyer Review (Procurement): 2 days

• Ensure you have the approprate contract documents uploaded when you submit your request
• The $ amount of the req matches the contract value and the correct billing codes are selected

1.B. New Supplier Onboarding: 2-3+ Days, if required

• 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

2.A. FP&A Review: 2 days

• FP&A is included as an initial reviewer to ensure the requested spend is within budget and that the Billing Code entered in Zip is correct so it can be pushed to Coupa when ready for final approvals.

2.B. IT Review: 2 days if purchasing new software or for contractors

• Requester should have vendor complete the IT New Software Questionnaire and submit with the purchase request so IT can complete their review

3.A. Legal Review: 3 to 21 days

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. 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.

Types of Vendors and Review Times

• Existing Vendors for renewals or upsells: 3-5 Days
  • 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 is adding 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.
  • Any delays from the supplier, will delay final approvals.
• New Vendors: 1-3+ weeks
  • 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.
  • 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 Agreements

• 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.

Negotiation, Security, Privacy, and PeopleOps reviews are only required if the purchase request meets certain criteria, as described below. In the event two or more of these activities are required, they will happen in parallel to one another and Legal’s review.

3.B. Negotiation: 12 days

• The Procurement team negotiates SaaS contracts >$25k and one-time contracts >$100K
  • If this step is not taken, purchase orders will not be approved until Procurement is able to negotiate
• SLA can extend based on level of negotiation required for large and/or complex contracts, and the suppliers willingness to meet budget and benchmark indicators. For larger spend purchases, it is beneficial to engage Procurement prior to submitting the request in Zip so negotiations can start earlier.
• For communicating Legal’s redlines to the vendor,
  • If the contract value is >$100k or Procurement is already actively negotiating or communicating with the vendor, Procurement will take responsibility for sending any legal redlines to the vendor. Procurement will comment in the req if/when they have sent redlines to the vendor for visibility. Otherwise the Stakeholder/Requester will be responsible.
  • Review here for more details on when and who is responsible

3.C. 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 GitLab’s Security Risk Team for completion ASAP.
• For any inquiries and questions, please tag @securityrisk in the #procurement slack channel.

3.D. 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.
• A background screening can be requested by opening an issue in the Lifecycle Management project by using the background_check_request template.
• 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.

3.E. Privacy Review: 4-14 Days

• 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. For existing vendors, a full privacy review is required every 24 months, provided the vendor completed a full and satisfactory privacy review during the prior procurement cycle
• 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 DPA/SCCs are often made part of the agreement with the supplier. Generally, Privacy would prefer to use our DPA/SCCs but if 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.

4. Final Buyer Review and Coupa Req Creation: 2 days

• Procurement completes a final check that all information is accurate and agreement(s) have been stamped before creating the req in Coupa for final approvals.

5. Coupa Approvals and Execute Contract: 4 days

• At this point, the req has been created in Coupa for final FP&A, Functional, and Executive approvals (as applicable).
• Once these approvals are received, Procurement will route the contract for GitLab and vendor signatures and will comment in the Coupa req when it is routing. After both parties have signed the Agreement(s), Procurement will attach a copy of the executed agreement in Coupa, approve the Purchase Req, and release the PO.
  • Note: only certain GitLab team members can sign contracts based on the Authorization Matrix
• To see how to check approval status in Coupa, visit the Zip End Users Guide.
  • Note: the completion of this step is dependent on how quickly the required approvers approve in Coupa and the contract is signed

6. Finalize Request Details

• Your purchase req has been approved! The supplier will receive a copy of the PO and a communication from Coupa indicating how to submit invoices, one of two ways:
  • Directly in their Coupa portal (preffered)
  • Sending invoices to ap@gitlab.com with the PO number included on the invoice
  • Failure to follow these instructions will delay payment and invoices uploaded to Coupa by a GitLab team member are not routed for payment.
• During this approval step, Procurement is finalizing any request details, such as final contract term dates based on signature effective date, and setting up Zip renewal alerts for the request if needed.
• Since the contract has been signed and PO is released at this point, you may now begin work and/or obtaining services from the supplier.

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 standard approval times to avoid needing escalation. Do this even if the contract isn’t final yet to help expedite the process.

What are the exceptions to the PO Policy?

Exceptions to the PO Policy are:

1. One time purchases under $5K (or less than $5K annually)
2. Charitable Contributions (Donations)
3. Interview Candidate Reimbursement
4. Confidential outside counsel legal fees
5. Statutory Tax fees
6. PEO Providers
7. AR/Customer Refunds
8. Board of Director Payments
9. Financing, Banking and Investing (incl interest, debt, FX, fees)
10. Corporate Credit Card
11. Urgent Payments not included on list above (approval required from VP, Corporate Controller and/or PAO)

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 any of the following is met:

1. Vendor is a private company, LLC or self-employed
2. Services provided are required for continued operations
3. Cloud hosting services
4. Services directly related to servicing customers with an uptime requirement
5. Storage of data that is not recoverable if vendor goes out of business
6. 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:

1. Terms and conditions which are fair and reasonable given the type(s) of products and/or services being procured; and
2. Adequate obligations on behalf of GitLab vendors to ensure compliance with
   • GitLab’s Code of Conduct and other company policies,
   • applicable laws, rules and regulations (including protection of personal data), and
   • 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?

As GitLab does with its own customers, agreements with third parties include obligations that vendors have to GitLab. These can include, but are not limited to:

1. Uptime / downtime commitments (for SaaS providers)
2. SLAs (for support)
3. Termination rights
4. And other commercial contract provisions which would enable GitLab to seek relief in the event of disruption

Large Internal Events Process

For any large internal events with a total cost greater than $1M, such as SKO, President’s Club, Commit, etc, the following should be completed before any contracts are executed or any work is conducted.

The planning stages for events of this size should be completed at least 18-24 months prior to the actual event. This allows for ample time to get the necessary internal approvals, run any RFPs needed, and book large hotel blocks or buyouts.

1. Connect with your Procurement Category Manager and FP&A Business Partner to determine the various vendors needed to run the event and line item detail in the total event budget. This would include lodging, food & beverage, event planning, on-site support, excursions, travel, etc.
2. Determine with your Procurement contact how these vendors will be selected and the timeline to run any necessary RFPs. RFPs should be conducted at least 20 months prior to the event dates.
3. Upon completion of RFPs, the top 2-3 location options and their total pricing will be presented to the E Group DRI (CRO/CMO) and VP of Finance to determine the preferred location choice and corresponding budget. All information should be summarized in an issue where these approvals may be documented.
4. Once preferred location and budget are tentatively chosen, this information will be presented to the CFO for approval, and will then be presented to the Board for approval at their quarterly meeting, or via email as necessary. Please note that Board approvals may take multiple weeks. CFO and Board approvals should be obtained no less than 18 months prior to the event dates.
5. After all executive approvals are received, the Zip request(s) should be created to document official approvals, obtain signatures on contracts, and release PO(s).

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
• RFP and Vendor Selection Process
• Vendor Terms and Conditions
• Non-Disclosure Agreement (NDA)
• Charitable Contributions
• Non-Cost Related Agreements (Including Trials/Demos)

View page source - Edit this page - please contribute.