Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Third Party Vendor Security Review process

Process Overview and Guide for Procurement Requests

Security Compliance performs annual security reviews of vendors for corporate tools and services that may process non-public GitLab data. As part of New Vendor Evaluations and Vendor Contract Renewals, a security review is required if processing, storing, and/or transmitting non-public data, which is all data classified as Yellow or higher. This extra scrutiny is due to the fact that GitLab no longer controls our data when it is processed, transmitted, or stored by a third party.

Security Compliance identifies potential risks to GitLab with the introduction of the third party based on the vendor security reports and engagement details, and identifies any compensating controls that may be available. The output of the review is not meant to be a recommended "Yes" or "No" from Security Complaince. Instead, all risks identified are shared with the relevant stakeholders to enable them to make the best business decision. The goal of the vendor security review is to reduce the likelihood that GitLab data will be exposed or mishandled by raising awareness and providing consultancy. Security management approval is required for vendors with major risks and the business owner is subject to the risk acceptance process.

This vendor security review process is not meant to slow down the procurement process, but a certain amount of friction to this process is inevitable. Refer to the decision tree below to determine whether a security review is required.

graph TD; A[New Vendor or Contract renewal] --> B{"Will this vendor be used for
marketing purposes such as
events, programs, sponsorships
hotels, content, or creative
and professional services?"}; B --> |Yes| C["No Security Review is required
if non-public data will not be stored or
processed by the vendor as part of this contract
(i.e. any information not available in our
handbook). Right click this box and
open in a new tab to navigate to the
appropriate vendor contract approval
issue template."] B --> |No| D[A Security Review may be required.] D --> E{"Will non-public data
be stored or processed
by the vendor as part of
this contract? (i.e. any
information not available
in our handbook)"} E --> |No| F[A Security Review is
not required.] E --> |Yes| G["A Security Review is required.
Determine the type of data that
will be stored or processed per
our data classification policy
(red, orange, or yellow data).
Right click this box and open
in a new tab to navigate to
our data classification policy."] G --> H{Is an NDA already in place?} H --> |No| I[An NDA is required for any
vendor contract involving
non-public data. Right click this
box and open in a new tab
to navigate to the handbook
process for creating an NDA.] H --> |Yes| J[Complete the vendor contract approval
issue template by right clicking this box
and opening in a new tab.] J --> K[Reach out to the vendor contact and
request Security Documentation that
will be required for a Security Review.
Right click this box and open in a
new tab to navigate to an email
template that can be used.] click C "" "Vendor Contracts Marketing Events Issue" click G "" "Data Classification Policy" click I "" "Creating an NDA" click J "" "Vendor Contract Approval Issue" click K "" "Security Documentation email template" style A fill:#e6e6e6 style B fill:#e6e6e6 style C fill:#a2f2a9, stroke:#0000ff, stroke-width:2px style D fill:#e6e6e6 style E fill:#e6e6e6 style F fill:#a2f2a9, stroke:#0000ff, stroke-width:2px style G fill:#e6e6e6, stroke:#0000ff, stroke-width:2px style H fill:#e6e6e6 style I fill:#e6e6e6, stroke:#0000ff, stroke-width:2px style J fill:#e6e6e6, stroke:#0000ff, stroke-width:2px style K fill:#e6e6e6, stroke:#0000ff, stroke-width:2px

Email template for requesting security documentation

You can help expedite this process by sending the following message to the vendor:

Because the use of your tool or services requires the protection of GitLab data and/or there is a reliance on your tool or service to support various business/financial processes at GitLab, our Security Compliance team will need some additional information to ensure that controls in your environment provide reasonable assurance that processes we rely on are operating effectively and that our data is appropriately secured. If you have gone through an independent certification for a SOC1 Type 2 or SOC2 Type 2, and have undergone a recent PenTest, please provide a copy of all these reports or summary of results. Additionally, if there are bridge letters available to supplement your SOC reports, please provide these so that our Security Compliance team can determine that there have been no major changes to controls over your environment between certifications. If you have not gone through these certification processes, please complete the GitLab Information Security Questionnaire and answer only the applicable questions. We appreciate your partnership in helping GitLab complete its due diligence requirements.

Vendor Documentation Decision Tree

In the event that the vendor cannot provide the above information, the following shows what documentation is required in order to complete this vendor security review process:

Does the vendor have an external audit report that shows how controls were tested and those testing results? (e.g. SOC1 Type 2 and SOC2 Type 2 reports, ISO 27001 audit reports, etc.)

Is the vendor willing to fill out GitLab's information security questionnaire so we can assess the maturity of their information security program?

Recent Penetration Testing Report

Penetration testing reports have a very different scope and goal than audits of an information security program audit, but they are very useful when assessing the maturity of a vendor's information security program. The fact that a vendor has completed such a test indicates that they are operating a mature security program and are reducing the likelihood of a vulnerability existing in architecture or software. For this reason we request a copy of a recent penetration testing report as a part of all documentation requests as well as a current state of the remediations associated with any findings in that report. If the vendor has policies that don't permit sharing of the report, a summary of the findings and their status confirmed by the vendor is acceptable. In cases where only PCI Atetstation of Compliance is available for sharing, we will accept that for our records.

What if a vendor is providing a security whitepaper instead?

Unfortunately, security whitepapers rarely give us all of the information we need. When a company generates these whitepapers they are always from the perspective of everything the vendor feels like they are doing well, but won't have any information about what controls are not in place or not yet mature. For this reason we won't accept whitepapers in place of audit reports or the GitLab Information Security Questionnaire, but the vendor can absolutely attach the whitepaper and reference any information in there when completing our questionnaire if that makes the process easier for the vendor.

Third Party Vendor Hardening Guide

This helpful guide is for business owners and third parties who wish to know more about complying with GitLab's best practices for sensitive data. As specifications and requirements are identified by stakeholders, those will be added to this page as security guidance for sourcing.

Vendor Security Review Process

Finance Issue

Third Party Vendor Security Management Issue

Completing the Review


Security reviews are largely operating on a guidance basis where Security Compliance provides recommendations for risks identified as having the probability of impacting GitLab. This is based on the vendor's score which is determined by the data types processed, the intergration and access levels and any reported deficiencies from the security reports or questionnaire. The DRI consults with the STORM scoring methodology to identify the score and treatment plan.


Security Compliance commits to a 3-business day SLA for completion when not waiting on input from the vendor. The scoped lables will be used to audit SLAs.

Accepting risks identified during the procurement process

If the result of a vendor security review is either:

  1. We were not able to get any security documentation from the vendor; or
  2. We identified 1 or more findings that indicate the vendor's security program is not appropriately mature or has known flaws then our findings will be presented to the Senior Director of Security for a final determination on whether or not that vendor can be approved from a security perspective.

If a GitLab team wants to move forward with a vendor without security approval, then a risk exception is required.

The purpose of this risk exception is to ensure that when GitLab leadership is approving of these risks, they do so with full context and insight into the tangible dangers presented by that risk to our team-members and customers. The output of this process also gives us a record to track organizational risk which is required in external audits.