In order to minimize the risk associated with third party applications and services, the Security Risk Team has designed this procedure to document the intake, assessment, and monitoring of Third Party Risk Management activities.
The Third Party Risk Management procedure is applicable to any third party application or service being provided to GitLab. This includes, but is not limited to, third parties providing free or paid applications or software, professional services organizations and contractors, marketing service providers and field marketing, alliances and partnerships, and mergers and acquisitions.
|Security Risk team||Maintain a mechanism to intake and respond to Third Party Risk Management Activities|
|Provide complete and accurate responses within documented SLA|
|Document and report any risks or trends identified during Third Party Risk Management Activities|
|Business or System Owner||Complete the General Information section of the TPRM issue or
Complete the intake questions in Coupa
|Work with the Security Risk team to facilitate any follow up with the third party|
|Accept or Remediate any observations identified|
Regardless of the type of Third Party being requested, it is important to document the risk they might pose to GitLab. We calculate this by assessing the type of data they will store, process, view or transmit. This allows us to determine an initial risk score and ensure that the high risk Third Parties are reviewed more thoroughly and more often while lower risk Third Parties can be approved quickly. In order to centralize this process, the Security Risk has developed the following two-part procedure.
It is important to note that the Third Party Risk Management procedure is meant to function alongside of GitLab's procurement and contracting processes and is not a replacement for any other required reviews and approvals.
The purpose of the Risk Assessment Phase is to conduct an initial vetting of all Third Parties to determine their inherent level of risk. A Risk Assessment is conducted with every new procurement request. This may seem inefficient given the amount of repeat requests for certain Third Parties, however, it is critical that this is done to validate the data classification, applicable integrations and previously assigned inherent risk tier. Oftentimes scope may change between engagements and/or with software add-ons which could change the data classification or integrations. However, due to automation built into the process, the risk assessment actually takes less than 5 minutes to complete once all information is provided.
The Security Risk team uses the below methodology to determine the inherent risk of the Third Party.
|High||Red data is in scope and/or
A GitLab System that stores Red data is in scope
|Moderate||Orange data is in scope and/or
A GitLab System that stores Orange data is in scope
|Low||Yellow, Green or No data is in scope and/or
A GitLab System that stores Yellow or Green data is in scope
Third Parties with Moderate or High inherent risk will require a Security Assessment. The purpose of the Security Assessment Phase is to dive deeper into the Third Party’s security controls and ensure they can meet or exceed our Third Party Minimum Security standards. This process is done entirely by the Security Risk team and unless otherwise noted, there is no action from the business owner during this phase. This review is required annually or if the inherent risk tier elevates to moderate or high prior to the annual review. The Security Risk team has a 10 day SLA to complete the Third Party Security Assessment based on the documentation received.
If a Security Assessment is deemed as necessary, the Security Risk team conducts the following steps:
The Adhoc Risk Assessment process should be used when:
To request an Adhoc Risk Assessment, GitLab team members can open a Third Party Risk Assessment issue. The Security Risk Team will collect key information on the usage of the vendor or application, type of data and systems in scope, and the website for vendor.
The Security Risk Team will follow the Risk Assessment process as described above.
General InformationSection of the TPRM issue.
Inherent Risk Calculationsections are completed.
Draftstatus and the GitLab issue will remain open.
Residual Risk Score and Outstanding Observationssection of the TPRM issue.
Draftstatus and the Coupa request will remain open.
Documentation Requestquestionnaire in ZenGRC to the security contact for the third party and applies the label ~"Documents Requested". NOTE: The Audit will stay in
Draftwith no auditor assigned until the questionnaire is completed.
This is an example of the email template that is sent out via ZenGRC automatically. If the third party does not receive the automated email, this email template will be used by the Security Risk team to request the necessary information.
As part of GitLab's Third Party Risk Management program, our Security Risk team assesses Third Parties and their applications or services, as applicable, to ensure they meet our Third Party Minimum Security Standards. Please complete the linked Document Request as soon as possible so we can begin our Security Assessment. If you do not have these resources, please email firstname.lastname@example.org and we will send you a link to our Third Party Security Assessment questionnaire. We appreciate your partnership in helping GitLab complete its due diligence requirements.
Once the TPRM Issue is created, the Business Owner will complete the General Information section within 5 Business Days. If the Business Owner does not respond within that timeframe, the TPRM issue will be labeled as ~RA-BLOCKED and will be removed from the daily queue. It is the Business Owner's responsibility to complete the General Information section of a blocked issue, remove the ~RA-BLOCKED label, and tag @gitlab-com/gl-security/security-assurance/security-risk-team when it is completed.
Once the documentation is is received, the Security Risk will complete the Security Assessment within 10 business days. If the Third Party does not respond within that timeframe, any open items will be documented as Observations and presented to the requestor.
Exceptions to this procedure will be tracked as per the Information Security Policy Exception Management Process.