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 Third Party Risk Management (TPRM) Program helps guard against 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 risks 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 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|
At a minimum, third party suppliers are expected to adhere to the same measures required for GitLab.com. 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.
Generally, a third party's SOC 2 report, ISO 27001 certification, Standard Information Gathering (SIG) form or equivalent will provide reasonable assurance if the scope provides coverage over the services offered. In the event an attestation is not available, TPRM will provide third parties with a copy of our SIG for completion. See below for details.
|Vendor Type||Red Data||Individual Contractors outside of Assessed Agency||Software Subscription||Professional Service||Individual Contractors through Assessed Agency||Field Marketing||Partners||Yellow Third Parties||Green Third Parties|
|Application Security Review Required||Yes||N/A||Optional||N/A||N/A||N/A||N/A||N/A||N/A|
|ZenGRC Template||Red||N/A||Orange SaaS||Orange Svc||N/A||N/A||N/A||N/A||N/A|
|A. Enterprise Risk Management||SIG Core*||Contract requiring use of GitLab laptop||SIG Core*||-||Request DPA and NDA from Legal||Request DPA and NDA from Legal||Depending upon nature of relationship send either SaaS or Prof Svcs.||Request DPA and NDA from Legal|
|B. Security Policy||SIG Core*||-||SIG Lite*||-||-||-||-||-||-|
|C. Organizational Security||SIG Core*||-||SIG Lite*||-||-||-||-||-||-|
|D. Asset and Info Management||SIG Core*||-||SIG Lite*||SIG Lite*||-||-||-||-||-|
|E. Human Resources Security||SIG Core*||Clean background check and Contractor assigned Security Awareness Training||SIG Core*||SIG Core*||-||-||-||-||-|
|F. Physical and Environmental||SIG Core*||-||SIG Lite*||SIG Lite*||-||-||-||-||-|
|G. IT Operations Management||SIG Core*||-||SIG Lite*||-||-||-||-||-||-|
|H. Access Control||SIG Core*||-||SIG Lite*||SIG Lite*||-||-||-||-||-|
|I. Application Security||SIG Core*||-||SIG Lite*||-||-||-||-||-||-|
|J. Cybersecurity Incident Mgmt||SIG Core*||-||SIG Lite*||-||-||-||-||-||-|
|K. Operational Resilience||SIG Core*||-||SIG Lite*||-||-||-||-||-||-|
|L. Compliance and Ops Risk||SIG Core*||-||SIG Lite*||SIG Lite*||-||-||-||-||-|
|M. Endpoint Device Security||SIG Core*||Evidence of GitLab provisioned laptop||SIG Lite*||SIG Lite*||-||-||-||-||-|
|N. Network Security||SIG Core*||-||SIG Lite*||SIG Lite*||-||-||-||-||-|
|P. Privacy||SIG Core*||-||SIG Lite*||SIG Lite*||-||-||-||-||-|
|T. Threat Management||SIG Core*||-||SIG Lite*||SIG Lite*||-||-||-||-||-|
|U. Server Security||SIG Core*||-||SIG Lite*||-||-||-||-||-||-|
|V. Cloud Hosting Services||SIG Core*||-||SIG Lite*||-||-||-||-||-||-|
|Z. Additional Questions||SIG Core*||-||SIG Lite*||-||-||-||-||-||-|
|Amount of GitLab Team Member Data Shared with Processor||Names||Contact Information||Historical Activity|
|None||Inquiry Only||Inquiry Only||Inquiry Only|
|Some||TPRM to Consult Privacy||TPRM to Consult Privacy||TPRM to Consult Privacy|
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. Details on the level of review performed for this type of request are available in the Reviewing App Integration Requests runbook.
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 Assessment.
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.
Privacy review is required for vendors/applications interacting with personal data relating to GitLab team members, vendors, or customers. Inquiries related to privacy controls are included in the Orange/Red TPRM questionnaire template, and are available as a standalone template if needed.
Sign-off of the mapped Privacy Questions Assessment in ZenGRC must be provided by a member of the Privacy/Exports team prior to Security granting approval.
Exceptions to this procedure will be tracked as per the Information Security Policy Exception Management Process.