Tips for Submitting a Zip Request

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

Getting Started with Zip

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 - Provides a step-by-step guide on how to submit different types of requests, how to review and approve requests for approver groups, how to check the status of your request, etc.

Tips for Request Types

Depending on the commodity type of your request, specific conditional questions will populate in the Zip request intake form to include the required approval groups in the workflow and provide them with the needed information to review your request. To help ensure your request is completed within the SLAs, follow these tips:

Description and Category

Provide a brief description of your purchase and be sure to select the correct category, subcategories, and type of purchase

• New purchase would be any product or service that is brand new.
• Renewal would be any renewals or add-ons with an existing vendor.

Submitting a request for a Contingent Worker

At GitLab we have a Contingent Worker Policy in place beginning March 2025. 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. After review you’ll need to identify which type of contingent worker you are interested in hiring. There are three categories of contingent workers at GitLab:

• Staff Augmentation Workers
• Consultancy Services
• Independent Contractors

Staff Augmentation Workers

Consists of supplemental, non-team member staff used temporarily to fill skill gaps or to provide additional project resources. Staff Augmentation Workers are always provided by an agency. If a Staff Augmentation Worker isn’t through an agency, they must qualify as an Independent Contractor. The Staff Augmentation Worker works within the GitLab organization under the general guidance of a GitLab hiring manager. GitLab maintains responsibility for work deliverables. Little or no responsibility is transferred to the vendor or their staff. Knowledge is solely contributed from the supplied worker. GitLab manages the duration of the assignment. In addition to “what” is delivered and “when”, GitLab maintains control over:

• “who” delivers the service
• “where” the service is delivered from
• “how” service is delivered

Services may be required on a full-time or part-time basis but invariably always temporary rather than permanent. Limited details of these Staff Augmentation Worker are to be held in Workday if the contract worker requires access to Okta and core GitLab applications.

Max duration for this worker type is 24 months. The assignment end date must be established up front as established in the Purchase Order. The same Staff Augmentation worker can not return to GitLab after ending an assignment for 3 months.

Consultancy Services

Consultancy Services are provided by a vendor that contracts with GitLab to provide professional services including expert advice within a particular knowledge domain. GitLab contracts with the third party for certain services and the contract is for the scope of work, i.e., the contract is for a product or service and not for an individual worker, for which GitLab is the customer. This arrangement is for non-core work that we trust an expert company to perform on our behalf and this arrangement is not for situations where we need supplemental labor to assist with the peaks of business. The third party has responsibility for the worker(s) and determines who will perform work and how work will be accomplished. Vendor assumes some or all responsibility for service delivery as detailed in a Statement of Work. In addition to providing staff, Vendor may be expected to provide access to its Intellectual Property to deliver service. Vendor manages its staff (e.g. turnover). GitLab maintains responsibility for “what” is delivered and “when”, but vendor maintains control over:

• “who” delivers the service (staffing)
• “where” the service is delivered from
• “how” the service is delivered

Limited details of these Contractor Personnel are to be held in Workday only if the contract worker requires access to Okta and core GitLab applications.

There is no limit on the length of contract, it will be the length of assignment necessary to fulfill the scope of work determined by the applicable contract and MSA. GitLab has the right to review and update the MSA as necessary.

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

An individual(s) who works for a company that they own (sole proprietorship) providing project deliverables incorporated into a Statement of Work (SOW). The individual must work truly independently, provided the freedom of action as to the details, methods, and means of performing services. Independent contractors typically perform services for more than one company. Independent contractors may work on outcome based/milestone arrangements in which the business pays the contractor based on the deliverable achieved or they may get paid on a time and materials basis. While this contingent worker type may be used in certain circumstances, its use is by exception only. All Independent Contractors must be contracted using the Independent Contractor Service Agreement (ICSA).

Independent contractors (also called consultants, freelancers, self-employed workers):

• are used for subject matter expertise that is outcome or project based
• GitLab maintains responsibility for “what” is delivered, “who” delivers the service and “when”, but Independent Contractor maintains control over:
  • “where” the service is delivered from
  • “how” the service is delivered

The relationship is defined in the contract between GitLab and the independent contractor.

Limited details of these Contractor Personnel are to be held in Workday if the contract worker requires access to Okta and core GitLab applications.

Max duration for this worker is 24 months, with a 3 month break. End date must be established up front.

How to Submit a Zip Request for a Contractor

1. Before submitting a Zip request for a Contingent Worker:

   • Confirm you have internal approval from FP&A and your management to hire a contingent worker and that this role is (i) not currently being performed by a GitLab Employee or (ii) there is not an open headcount position for this role.
   • If the Contingent Worker requires access to Okta and/or core GitLab core applications, a GitLab laptop must be issued followed by a Zip approval from IT Ops validating laptop issuance.
   • If the Contingent Worker requires GitLab equipment (i.e. access to Orange or Red data), which will require a Security Review, the Zip purchase requisition will need to be submitted 10 days in advance of the normal approval timeline to account for ordering and shipping of the equipment. Certain locations will require IT Approval before providing the equipment. If you are unsure if the IC will require GitLab equipment, please reach out to the #it_help channel in slack.
     • Lead times start once the purchase requisition has been fully approved and the PO is released. Please account for this time and the Zip approval times to determine how far in advance your Zip Request needs to be submitted prior to the IC’s start date.

2. Open Zip to submit your request for a contingent worker by selecting “New Request” and then “Request a Purchase - Contingent Worker or Consultancy Services”

3. In the “General Information” section, you’ll need to fill out the following information:

   • Who is the requester? * (most likely this is yourself)
   • Provide a Title for this request * (Best practice: “Vendor Name - FYXX Services Name/Description”)
   • Which detailed category best describes your purchase? * (select either Staff augmentation, Consultancy Services, or Independent Contractor)
   • What type of purchase is this? * (select new, renewal, or extension)
   • Will a virtual card be used to pay this vendor? *
   • What is the vendor’s name (look first to see if the vendor has been used previously at GitLab, if not you’ll need to create a new vendor)
   • In which country is the contingent worker working from? *
   • Will you be onboarding multiple contingent workers for this engagement? *
   • Do you have the contact information and personal email address(es) of the requested onboardee(s)? * (this will be needed to track contingent workers in Workday, note: this information can come at a later date but not before everything is finalized)
   • Who is the Manager for the Contingent Worker? *
   • What is the Business Title for this Contingent Worker? *
   • What is the Contingent Worker’s Non-GitLab email address? *
   • What is the Contingent Worker’s Legal First Name? *
   • What is the Contingent Worker’s Legal Last Name? *
   • What is the Contingent Worker’s Preferred First Name? *
   • What is the Contingent Worker’s Preferred Last Name? *
   • What is the Contingent Worker’s Address *

4. In the “Spend Information” section, you’ll need to fill out the following information:

   • What subsidiary is this purchase for? * (FP&A can help you answer this?)
   • What is the desired start and end date for this purchase/contract? * (Note: If this is a Staff Augmentation - the Start/End date should not be longer than 24 months)
   • How much budget will you need for this purchase? *
   • Line type (select “amount”)
   • Coupa Subsidiary (this is typically your entity like GitLab Inc for US)
   • Coupa Department (this is typically the org you sit in)
   • Coupa GL Account (select 6017 Consulting Fees)
   • Do you have any of the below supporting documentation? * (MSA, SOW, etc)

5. In the “IT, Security, and Privacy Information” section, you’ll need to fill out the following information:

   • What type of access will the vendor need to data and information? *
   • Access to GitLab resources via personal devices is not permitted. Is the contingent worker issued a vendor-managed laptop? *
   • Does this request involve the use of a web application, web portal, or software system? *

6. The Zip Request will be reviewed by the applicable stakeholders

7. Once the Zip Request is approved, open and complete the Individual Contributor Onboarding Issue

• If you need to extend the contract term of an IC, submit a Zip Change Request

• If you need to cancel / terminate the Contractor’s agreement earlier than the specified term, review the Cancellation process and reach out to the Procurement Team in the #procurement slack channel

*Contingent Workers that require Orange and Red Data access, that will be processed or stored outside GitLab’s systems, are considered “Professional Services” and are subject to a full security review. Please see the Security Third Party Risk Management Handbook for more details.

Submitting a request for New Software

1. All new software purchases also need reviewed by IT
2. New software vendors will need to complete the IT Questionnaire tab.
   • IT requests this information to perform a comprehensive assessment of applications against GitLab technology requirements.
   • Please make a copy of this tab (if not filled out during a formal RFP), have the vendor complete, and attach in the documents section of your Zip Request for IT review.
3. If you have any questions regarding the IT Questionnaire, please contact the Enterprise Applications team in the #enterprise-apps slack channel.

Other Tips for Submitting Requests

1. Will a virtual card be used to pay this vendor?
   • This applies to instances where the supplier only accepts online credit card payments or for one-time vendor use such as events. More info on allowed uses here
   • More information in the Zip End Users Guide on how to submit a request using for a virtual card
2. 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 contact information
   • If New Vendor:
     • Review the Vendor Selection Process and the RFP guidelines or reach out to your Procurement Category Manager if you have questions or need support
     • 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 complete the New Vendor Onboarding step. While we use Zip internally now, Coupa will still be the tool used to pay our suppliers.
3. Spend Information
   • Provide all of the spend details including required budget amount, contract term, and line item details.
   • The Line Item Breakdown should match the line items on the Order Form/Contract and should be entered separately for each year of the contract if a multi-year term.
   • The sum of the Line Items must equal the amount entered for budget.
   • Check the boxes of the supporting documentation received. You will upload these in the Documents section at the end of the request process
4. IT & Security Information:
   • 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 GitLab’s Security Risk Team 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.
   • TIP: To increase speed of approval, send your supplier contact GitLab’s DPA/SCCs for review right away. For the DPA, please inform the supplier contact that Schedule 1 and Schedule 3 must be completed by the supplier. Also alert them to the request from GitLab’s Security Risk Team for security completion and Zip for privacy review completion. Let them know review and approval can’t begin without these pieces.
5. Documents & Surveys:
   • For any software renewal/add-on that is based on usage (e.g. user quantities), a usage report is required for Procurement’s review. This can be uploaded in the Documents section under ‘Please attach any additional files for reference’ at the end of the request process.
     • Based on the usage report, Procurement will review the request to increase, decrease, or hold quantities flat.
   • Upload any contracts and/or quotes you’ve received.
     • Draft contracts are okay. Make note of any terms and/or pricing still being finalized- this can be done in the Comments section once you submit your request.

Zip Change Requests

If you have a PO with an existing supplier and the costs have increased, end date has changed, and/or the scope or terms and conditions need to be amended, a Zip Change Request can be submitted.

By submitting a Zip Change Request, the applicable approvers will be added to the Zip workflow for review, and the Procurement team will amend the PO in Coupa on your behalf. Note, changes to an existing PO also must be approved by Finance, Functional, and Executive (if applicable) team members in Coupa like a new Purchase Request.

Once your Purchase Request is approved

1. Once the Purchase Request in Zip and Coupa is approved, a PO is generated, and 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 [email protected] 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.

Procurement Office Hours

If you have any questions or concerns that may not be addressed in the Handbook, we invite you to join us for Procurement Office Hours every Wednesday. During this dedicated time, our Procurement Team will be readily available to assist you and provide answers to your inquiries. If you’re unable to join a call, please feel free to submit your questions in our Agenda, and we’ll ensure a prompt response.