This is a Controlled Document
Inline with GitLab's regulatory obligations, changes to controlled documents must be approved or merged by a code owner. All contributions are welcome and encouraged.
GitLab's Security Third Party Risk Management (TPRM) Program helps guard against security threats posed by third parties who have direct or indirect access to GitLab and/or Customer/Client data. Risks include data breaches, unauthorized use or disclosure, and corruption or loss of data. Adequate TPRM is a best practice that helps mitigate security concerns and enables GitLab to meet our contractual obligations. TPRM also enables GitLab to meet regulatory requirements and standards related to ISO, SOX, GDPR and other state and federal laws requiring vendor oversight.
GitLab's Security TPRM program involves three components which are integrated in to our Procurement processes:
This procedure applies to all third party providers that access, store, process or transmit GitLab data.
|Security Risk Team||* Maintain a mechanism to intake and respond to TPRM Activities
* Assess Third Party inherent and residual security risk
* Inform business owners of the result of TPRM assessments
|Business or System Owner||* Describe the nature of the Third Party Relationship
* Work with the Security Risk team to facilitate the TPRM review, to include remediation activities
* Ensure the responsiveness of the thrid party as part of the security review requirements
|Security Assurance Management (Code Owners)||Responsible for approving significant changes and exceptions to this procedure|
TPRM utilizes a risk-based approach when assessing third parties. Specific procedures used to assess different vendor types / risk profiles can be found below.
Additionally, effective FY23 Q3, all third party applications that house GitLab data are required to authenticate via Okta inline with GitLab's approach to centralized authentication and authorization. Risk acceptances will be required in all cases where Okta is not supported regardless of security status.
The diagram below depicts TPRM procedures dependent upon the Data Classification of data shared with the third party.
The following table describes the procedures followed by TPRM engineers for vendors storing/processing different classifications of GitLab data. These procedures are initiated by the Procurement process and are followed in all instances where vendors have not been reviewed in the past 12 months.
If a vendor has been reviewed and approved within 12 months of a new procurement request, GitLab TPRM Engineers must review the request to determine that no material changes have occurred which may require a new assessment before approving. Material changes include:
GitLab TPRM Engineers reserve the right to perform additional procedures at their professional discretion.
|Data Classification||Request||Supplemental Questionnaire in Zen?||CUEC Mapping?||Okta SSO?||New BIA / Tech Stack Entry?||BitSight Score Review?||Evidence of PenTest and BCP Testing|
|Red*||3rd Party Attest & SIG Lite Plus (or equiv)||Yes||No**||If applicable||Yes||If applicable||Yes|
|Orange SaaS System||3rd Party Attest & SIG Lite Plus (or equiv)||Yes||No**||Yes||Yes||Yes||Yes|
|Orange GL/GL Team Member-hosted System||3rd Party Attest or SIG Lite Plus (or equiv)||No||No||No||Yes||No||No|
|Professional Services||3rd Party Attest or SIG (See Below)||No||No||No||No||No||No|
*Law Firms may have legal obligations requiring limited access to red data. As such, Law Firms will be treated as Orange vendors.
**Orange SaaS SOX systems will have SOC 1 CUEC mappings facilitated by TPRM drafted and handed off to Internal Audit annually during Q1. If SOC 1s are not available SOC 2s will be mapped.
The Security Risk Team leverages a Standard Information Gathering (SIG) Questionnaire to gain a more in-depth understanding of a vendor's Security environment beyond what is attained by reviewing a Third-Party Attestation (such as an ISO certification or SOC-2 report). Responses within the SIG questionnaire, or an equivalent document such as a CAIQ, should be reviewed alongside the vendor's third-party attestation (if available) and their responses to our Security Questionnaire when assessing the Security environment in place within the service organization.
Security Risk maintains multiple templated versions of the SIG questionnaire for use depending on the product or service being assessed, as some vendors may not have a SIG questionnaire or equivalent to provide. Note that these SIG templates include multiple tabs which are not required for our procedures to gain assurance over a vendor's environment. When distributing these templates, the vendor should be instructed that we only require Inquiry responses within Columns D and E of the main questionnaire tab, as additional requests for information or documentation within the SIG are generally not required. Note that potential fringe cases could exist wherein professional discretion may dictate the necessity for additional documentation requests to supplement vendor responses. These scenarios should be discussed with the Security Risk Manager to determine what is needed. Further, professional discretion should be applied when making decisions as to which version of the SIG questionnaire should be sent. For cases in which the level of review required is unclear, engineers are encouraged to send the full SIG Lite Plus questionnaire or discuss with the @Security-Risk team in the #Sec-Assurance-Team channel to come to a decision.
SIG questionnaires (or equivalent) provided by a vendor not utilizing a GitLab-provided template should be reviewed to ensure they meet our due diligence standards. Domains not sufficiently addressed by a vendor-provided questionnaire should be identified, with additional inquiries performed to gain assurance over all in-scope domains.
Vendor responses documented within the SIG questionnaire should be reviewed in the context of the services provided by the vendor, with care taken to understand the broader control environment and how certain insufficient controls may be mitigated by other existing controls. For example, a vendor that does not rely on 3rd party service providers in the provision of services would be unlikely to maintain a Third Party Risk Management program, which is unlikely to pose a risk to GitLab in the broader context of services being provided. Cases such as this should be flagged during the review and noted within the SIG questionnaire with an explanation on why the deficiency does not present a risk to GitLab data. Mitigating controls, if identified, should be defined within these notes as well. Engineers are encouraged to perform follow-up inquiries with vendors as necessary to determine whether a control deficiency exists. These inquiries should be further noted within the SIG document or within the TPRM Assessment Report.
Deficiencies noted presenting a material risk to GitLab data should be noted within the TPRM assessment report and presented to the business owner via the Risk Acceptance Process detailed below.
Change requests relating to previously-approved requisitions in Coupa will be reviewed by the on-call Engineer to determine whether a material change is being requested to (1) the scope of services provided, (2) the data elements transmitted to the vendor, or (3) the timeframe of the services provided. If material changes occur as defined here or that are otherwise identified resulting in a change to data classification or movement outside of the 12-month approval window from the previous review, a security assessment should be launched according to the TPRM assessment requirements detailed above. Changes requested specific to the cost of services and that do not present a material change impacting Security can be approved based on inheritance of approval from the parent requisition.
For example: We performed a TPRM assessment for Vendor X which was completed on December 31, 2021, resulting in a 12 month coverage period lasting to December 31, 2022. A change request was created in January 2023 (outside of coverage period) related to overage charges for services provided during November 2022 (within coverage period). This example change request can be approved without a new TPRM assessment.
Engineers are advised to use professional judgment in determining the scope of changes and are encouraged to perform additional review prior to approving the Change Request if there is potential for introduction of additional risk. For other non-material adjustments not defined here that may not warrant additional review, Engineers should ping the Security Risk team or discuss with the Security Risk Manager prior to moving forward to ensure alignment with GitLab's due diligence requirements. Rationale should be documented when approving the Change Order in alignment with the low-risk approval language in the TPRM README.
Independent Contractors requiring access to Orange or Red data in the provision of services must be vetted by Security prior to being granted system access. The below items are required prior to granting Security approval:
Third party integrations with GitLab's current tech stack are also subject to a TPRM assessment process for instances where an integration that is provided by a vendor has not gone through the standard TPRM Procedure. The Team Member Enablement team will not enable third party integrations prior to an assessment being completed as mentioned on the App Integrations handbook page.
Want to vet a third party before contract renewals hit Coupa? Would you like to obtain approval for software/services we may purchase at a later date? Click here to open a new Third Party Risk Intake Request.
Risk acceptance can be pursued when the business acknowledges that potential loss from a risk is not great enough to warrant spending the resources necessary to avoid it. When Risk Acceptance is a viable option TPRM will fill out the Risk Acceptance Issue template and assign it to the Business Owner. Note that business justification and approvals are required.
There are two TPRM Risk Acceptance types:
If business needs dictate that the Security Assessment process be delayed or bypassed, Security Risk will walk the Business Owner through the following Risk Acceptance Process:
The Business Owner will receive the following prompt:
Once associated information is submitted, the Security Risk team will review this request.
Security Risk will create a Risk Object in ZenGRC that is mapped to the corresponding Vendor Security Review and Vendor Object for the Risk Acceptance, that will be followed up on towards the end of the Risk Acceptance Period. This Risk Acceptance will follow the acceptance requirements established by the Security Operational Risk Management Methodology.
If the TPRM Security Review concludes with the disclosure of a finding (Observation) due to ineffective control(s) this will be disclosed to the Business Owner. GitLab can then either ask the vendor to remediate prior to onboarding or the GitLab Business Owner can formally accept the associated risk.
Once a risk treatment plan is communicated, Security Risk will create an Issue Object within ZenGRC and assign the Business Owner as the Issue Owner.
Formal risk acceptance's require approval based on the approval matrix established by the Security Operational Risk Management Methodology. These vendors will be tracked on GitLab's risk register and flagged for review on an annual basis. The Business Owner owns this risk.
If moderate or low risk observations are noted during the review process the Business Owner will be informed via the TPRM report and will be responsible for making the decision to move forward with the vendor. These observations will be managed as per the Observation Management Procedure.
Please refer to our StORM Methodology Handbook for required approvals based on risk rating (High/Medium/Low) and responsibilities of Accepted Risk Owners and Risk Acceptance Approvers.
Exceptions to this procedure will be tracked as per the Information Security Policy Exception Management Process.