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.
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.
Division alignment for spend over >$25k USD:
Legal - Adrienne Ruhaak
All division spend <$25k USD - Dasha Yarmusik
Procurement is a cross-functional team that supports GitLab as a public company. We have four key objectives monitored in the following ways:
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:
Percentage of all vendor spend for any department that is purchased via PO.
Aligns with the following core business objectives:
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.
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.
TIPS to streamline approval process
To help expedite the review and approval of your purchase request, be prepared to provide the following information in your Zip Request. If you don't know all of this information yet or are wanting support to negotiate that's ok!
Complete the Data Information section. Depending on your selection(s), additional required questions will appear.
If any data will be shared, a Vendor Security Review will be completed. The vendor will receive an email communication from ZenGRC requesting information regarding their security protocols.
If any personal data will be shared or accessed, a Privacy Review may be required. The vendor will receive communication from Zip requesting information regarding their data privacy practices.
Be as specific as you can about the type of data the vendor and/or system will have access to, and specifics about how they will receive that data. Failure to complete this section accurately will delay the review and approval of your request.
If any personal data will be shared, the Vendor will need to sign our DPA and SCC’s as directed by state and/or country statutory requirements.
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.
Congratulations and thank you for following this process to support GitLab as a public company!
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:
In the event two or more of the below activities are required, they will happen in parallel to one another:
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
Types of Vendors
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.
If you are unable to plan and have a legitimate reason to escalate a purchase request, follow the process below.
Exceptions to the PO Policy are:
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
Please review the below guidelines:
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.
Procurement team can assist you in your negotiation. The goal is to get the best price inline with benchmarks.
All vendors require a security review. Please see the details of SLA and how to complete this process in our Zip documentation section.
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
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.
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
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?
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.
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 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
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.
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