Security Third Party Risk Management

1. You are here:
2. Handbook
3. Security at GitLab
4. Security Assurance
5. Security Risk Team
6. Security Third Party Risk Management

Maintained by:

On this page

• Purpose
• Scope
• Roles & Responsibilities
• Third Party Minimum Security Standards
• Procedure
  • TPRM Assessment Requirements
    • The Standard Information Gathering (SIG) Questionnaire
  • Other Types of Third Party Assessments
    • Change Requests
    • Independent Contractors
    • Third Party Application Integrations
    • Independent Assessments
  • TPRM Risk Acceptance Process
• Exceptions
• References

Purpose

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:

1. Performing due diligence to ensure the third party implements safeguards to enforce data privacy and security.
   • This activity is performed via our Security Assessment Process.
2. Contractually obligating the third party to implement these safeguards.
3. Monitoring third party safeguards and compliance with these contracted provisions.
   • Certain high risk Third Parties are reviewed annually while those posing lower risk are reviewed at the time of contract renewal unless the contract renewal occurs within 12 months of that vendors most recent review.

Scope

This procedure applies to all third party providers that access, store, process or transmit GitLab data.

Roles & Responsibilities

Third Party Minimum Security Standards

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.

Procedure

The diagram below depicts TPRM procedures dependent upon the Data Classification of data shared with the third party.

TPRM Assessment Requirements

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:

1. Change in data classification (e.g., going from Yellow to Orange data classification)
2. New system from vendor not previously reviewed (e.g., we've reviewed Zuora for the purchase of its Billing system, but a new request has come in for the purchase of its Revenue system)
3. Change of location where data is stored or accessed from (e.g., moving data from GitLab-hosted app to vendor-hosted SaaS)
4. Added contractor from vendor not previously reviewed (e.g., we've reviewed Upwork and a freelancer from Upwork service to support Marketing, but a new request has come in for a new freelancer to support the People team)

GitLab TPRM Engineers reserve the right to perform additional procedures at their professional discretion.

*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 Standard Information Gathering (SIG) Questionnaire

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 Lite Plus
  • The SIG Lite Plus questionnaire is leveraged most commonly and should be utilized for all Red vendors and Orange SaaS systems. We refer to our SIG Lite as the "SIG Lite Plus" as it includes full scope SIG questionnaires for domains "A. Enterprise Risk Management" and "E. Human Resource Security". All other domains include standard SIG Lite content. Our objective here is to obtain additional information related to personal computers and background checks.
  • The following 18 domains are included within the scope of the SIG Lite Plus questionnaire:
    • A. Enterprise Risk Management (Full SIG Content)
    • B. Security Policy
    • C. Organizational Security
    • D. Asset and Info Management
    • E. Human Resources Security (Full SIG Content)
    • F. Physical and Environmental
    • G. IT Operations Management
    • H. Access Control
    • I. Application Security
    • J. Cybersecurity Incident Mgmt
    • K. Operational Resilience
    • L. Compliance and Ops Risk
    • M. Endpoint Device Security
    • N. Network Security
    • P. Privacy
    • T. Threat Management
    • U. Server Security
    • V. Cloud Hosting Services
• Professional Services SIG
  • The Professional Services SIG Lite Plus questionnaire features a reduced scope and can be leveraged for scenarios in which an Orange vendor is only providing contracted services or services not otherwise resulting in the introduction of a new system being transmitted sensitive GitLab data. In these cases, it may not be necessary to perform a full-scope review of the vendor's Security environment, as many controls within the full SIG Lite questionnaire may not apply or present a material risk to GitLab data. Please note this guidance applies only to Orange professional services providers. Service providers being granted access to Red data in the provision of services should be assessed utilizing the SIG Lite Plus questionnaire defined above due to the greater obligation for Data Security with these providers.
  • The following domains are included within the scope of the Professional Services SIG Lite Plus questionnaire.
    • D. Asset and Info Management
    • E. Human Resources Security (Full SIG Content)
    • F. Physical and Environmental
    • H. Access Control
    • L. Compliance and Ops Risk
    • M. Endpoint Device Security
    • N. Network Security
    • P. Privacy
    • T. Threat Management

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.

Other Types of Third Party Assessments

Change Requests

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

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:

• Evidence of initiated background check, which will be monitored and adjudicated by the Sr. Background Check Specialist.
  • This helps ensure that personnel with criminal backgrounds that may pose a threat to GitLab assets, customer relationships, and sensitive information are identified.
  • Note: Background check requirements are subject to change at the discretion of the People Operations team. Please refer to the background screening entry within the People Policies handbook to ensure alignment with current requirements. If further guidance is needed, contact the Sr. Background Check Specialist at backgroundchecks@gitlab.com.
• GitLab Laptop Request Issue OR Assignment of VDI Environment Access
  • Controls related to the security of hardware utilized by personnel are an important piece in ensuring the security and privacy of GitLab data. In order for GitLab to maintain oversight over this critical function, contractors are required to be issued a GitLab laptop or access to a VDI (Virtual Desktop Interface) environment to be used for all work performed on GitLab's behalf.

Third Party Application Integrations

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.

Independent Assessments

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.

TPRM Risk Acceptance Process

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:

1. When business needs dictate that the Security Assessment process is delayed or bypassed (Delay or Bypass TPRM Review)
2. When Observations are identified during a Security Assessment (Accepting Risk Associated to a Known Control Failure)

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

Exceptions to this procedure will be tracked as per the Information Security Policy Exception Management Process.

References

• Parent Policy: Information Security Policy
• SCF Compliance Controls
• Data Classification Standard
• Current listing of controlled documents
• App Integrations (Team Member Enablement)
• Observation Management Procedure
• STORM Methodology
• Professional Services