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

Risk Management

Risk Assessments

Risk assessments help GitLab identify, prioritize, and manage security risks. They're important to help protect customer data and meet GitLab security compliance controls, which are important for compliance standards such as SOC2 and PCI-DSS. A risk assessment should ideally be completed for every service in the Tech Stack Applications table and reviewed either quarterly or as substantial changes are made, whichever is most feasible. Additionally, risk assessments are used as part of Data Protection Impact Assessments (DPIAs).

At GitLab, our risk assessment framework is based on a combination of NIST SP 800-30 Rev. 1 and the Mozilla Rapid Risk Assessment (RRA), but customized to be collaborative, asynchronous, and done within GitLab itself. All risk assessment work is done within the Risk Assessment repository.

Creating a New Risk Assessment

Internal & External Risk Considerations

Risk assessments should consider both internal and external risks. This is important because the Verizon 2019 Data Breach Investigation Report (DBIR) found 39% of breaches involved internal actors (whether intentional or accidental). By considering both internal and external risks, we can more accurately define and work to mitigate GitLab's risk surface.

Fraud & Abuse Considerations

Risk assessments should specifically consider risks related to fraud and abuse. This is important because fraud and abuse results in millions of lost dollars from victims every year. Fraud and abuse can also directly impact GitLab's product and service offerings. For those reasons, every risk assessment should explicitly address fraud and abuse related risks.

Risk Remediation and Tracking

Accepting Risk

There may be instances where a risk cannot or won't be remediated. In such cases, follow the Risk Exception process.

Contributing to a Risk Assessment

Review and Revision of Risk Assessments

Risk assessments should be continually reviewed and revised to keep the information in risk assessments current and relevant. At a minimum, every risk assessment should be reviewed once per year or as significant changes are made to the system, whichever comes first.

To conduct a risk assessment review:

Upcoming risk assessment reviews are tracked in the Risk Assessment Review document. A risk assessment should be added after the initial MR has been merged.

Closing a Risk Assessment

Sometimes it may be appropriate to close a risk assessment. Some reasons a risk assessment may be closed are the vendor is no longer used or the type of data stored or processed changes. To close a risk assessment, open an MR and:

This MR can be used as an example of this process.

Risk Exceptions

Risk management is a way to identify and document most of the risks associated with how we perform our work as GitLab team-members. Every decision we make as a company involves risk and the purpose of documenting that risk is not to influence decision making or slow down processes unnecessarily, but rather to give GitLab decision makers as much information about that decision as possible so the best possible decision can be made.

Risk exceptions are a way to document when the business benefits outweigh the risks associated with a particular decision. In order to gather the evidence we need to show auditors we are making these decision with security risks in mind, we are processing exceptions through risk exception issues.

The goal with these exceptions is to make a "steel man" case for why a particular decision might increase the overall risk to the organization. This is not meant to deter the appropriate exception approver from accepting that risk, but rather to make that decision as informed as possible. There will always be times when a process meant to reduce risk in 80% of cases simply won't apply to a particular decision and this exception process will help guide all parties involved through that decision making process.