This handbook page details the specific Security Operational Risk Management (“StORM”) Methodology that is used at GitLab in order to assess Risk Appetite, Risk Tolerance, as well as scoring risks based on their likelihood, impact as well as explicit inherent vs residual risk levels.
The annual StORM assessment is conducted on a predefined schedule from year to year.
| Timing | Activities |
|---|---|
| March | Risk Appetite Survey is sent out to Senior Leadership to establish GitLab's Annual Risk Appetite |
| April-May | Annual StORM information gathering is kicked off for risk identification. Once completed, newly identified risks will be documented and quality reviewed. |
| May-June | The annual StORM reports are prepared, reviewed, and approved. |
| June-July | Risk treatment plans are developed for risks identified during the ARA and a retrospective is held to capture improvement opportunities for StORM. |
On an annual cadence, the Security Risk Team reassesses GitLab's overall Risk Appetite. This is a key activity that drives risk treatment decisions for risks identified as part of the Annual Risk Assessment. While significant changes to risk appetite are not anticipated, this activity provides a mechanism to ensure GitLab's appetite and tolerance for risk align with changes to threat sources and events.
GitLab’s risk appetite is determined based on the total average priority order determined by senior leadership on the following risk strategy statements:
Each risk strategy statement is ranked in order of priority from Highest priority risk strategy to Lowest priority risk strategy by senior leadership. GitLab utilizes the following risk appetite matrix:
| RISK APPETITE APPROACH |
RISK SEEKING | RISK TOLERANT | RISK NEUTRAL | RISK AVERSE |
|---|---|---|---|---|
| RISK TAKING vs RISK TRANSFER |
Aggressive risk taking is justified |
Seek opportunities to transfer risks with pre-existing vendors as applicable (e.g. don't bring in a new vendor to transfer risks) |
Take a balanced approach to risk taking vs risk transferring |
Exercise caution and accept as little risk as possible by identifying risk transfer solutions |
| ORGANIZATIONAL OBJECTIVES |
Willing to accept a large negative impact to the organization to pursue opportunities that align with objectives |
Willing to accept some negative impact (e.g. LOW risks) to pursue opportunities that align with objectives |
The potential for a negative impact vs objectives are given equal consideration when making a decision |
The potential for a negative impact vs objectives are given equal consideration when making a decision |
| RISK RESPONSE APPROACH |
All risks are acceptable as long as they do not impact our legal and regulatory obligations |
Determine risk treatment options to help accept or reduce risk levels through internal initiatives |
No explicit preference towards how risks should be approached |
Risks that cannot be effectively treated or transferred are avoided |
| RISK RESPONSE DRIVERS |
No response action required for risks | Respond to risks which make sense when a case can be made for the cost effectiveness of potential outcomes |
Risk response actions take into consideration cost effectiveness, management priorities, and return on investment |
Risk response actions are always taken, regardless of cost effectiveness, management priorities, return on investment, and overall organizational objectives |
GitLab's Risk Appetite Matrix was formed through consideration of guidance set forth in NIST's SP 800-39 and SP 800-30 Rev. 1.
Scoring is performed by individuals operating in at least Senior Leadership capacity within GitLab and spans across multiple departments.
| Fiscal Year | Departments | Risk Appetite |
|---|---|---|
| FY23 | Engineering, Finance, and Legal | Risk Neutral |
| FY22 | E-group, Engineering, Finance, and Legal | Risk Neutral |
| FY21 | Engineering, Finance, and Legal | Risk Neutral |
The identification of threat sources and events in relation to operational risks includes multiple considerations. These threat sources and events have been identified based on their potential to have an impact on mission critical objectives in relation to GitLab's operations.
| Threat Source | Example Threat Events |
|---|---|
| Adversarial | Fraud and theft, insider threat, malicious hacker, and malicious code |
| Non-Adversarial | Errors and omission, loss of physical and infrastructure support (e.g. a natural disaster), exposure of sensitive information, changes to systems used to support the business, changes to external environments supporting GitLab, changes to GitLab's business model, or even changes in leadership |
A scoring model is used to score each risk and is based on the Likelihood of the risk event occurring and the Impact to GitLab if the event occurred. Likelihood and Impact scores directly determine the overall inherent risk to GitLab.
| Qualitative Score |
Risk Level | Scoring Guidelines |
|---|---|---|
| 6 | CRITICAL | Easily initiate a threat event; no expertise required |
| 5 | VERY HIGH | Minimal difficulty to initiate a threat event |
| 4 | HIGH | Some expertise required to initiate a threat event |
| 3 | MODERATE | Difficult to initiate a threat event, even with expertise |
| 2 | LOW | Requires expertise to initiate a threat event |
| 1 | VERY LOW | Theoretically impossible to initiate a threat event. |
| IMPACT SCORE |
IMPACT AREAS | |||||
|---|---|---|---|---|---|---|
| Organizational Output (time, quality, resources) |
Brand Reputation |
Business Continuity |
Customers & Stakeholders |
Legal & Regulatory |
Financial | |
| VERY LOW (1) | Organizational output is impacted by less than 20% |
Limited to reputational damage with no more than one customer within a fiscal period |
Outages of non-critical systems that impact GitLab team members |
Impact is limited to one customer and/or stakeholder |
Breach of company policy occurring once in a fiscal period |
Loss up to $999 |
| LOW (2) | Organizational output is impacted by 30% - 40% |
Confined to a limited number of parties (e.g. specific customers) and not publicized |
Outages which result in the inability of GitLab to continue sales and finance operations longer than 72+ hours |
Impact is limited to 2-3 customers and/or stakeholders |
Breach of company policy twice within a fiscal period |
Loss between $1,000 and $9,999 |
| MODERATE (3) | Organizational output is impacted by 40% - 50% |
Public domain publicity but limited to industry channels and not the broader public |
Outages that impact GitLab's ability to do business across 3+ departments |
Impact is limited to 4-5 customers and/or stakeholders |
Breach of a regulatory and/or contractual obligation |
Loss between $10,000 and $499,999 |
| HIGH (4) | Organizational output is impacted by 50% - 75% |
Wide-spread publicity but limited parties are impacted |
Outages that result in the loss of availability of GitLab for customers for less than 4 hours |
Major impact to many customers and/or stakeholders |
Regulatory censure and/or action taken against GitLab |
Loss between $500,000 and $999,999 |
| VERY HIGH (5) | Organizational output is impacted by 75% or more |
Widely publicized | Outages that result in the loss of availability of GitLab for customers for 4+ hours |
Major impact to all customers and/or stakeholders |
Public regulatory fines and/or major litigation against GitLab |
Loss of $1,000,000+ |
To arrive at a final impact score, the impact score of all impact categories is averaged.
Inherent Risk = Likelihood x Impact
Once the Inherent and Residual risk score is determined, the following table can be used to determine if a risk is considered LOW, MODERATE, or HIGH.
| 6 | MODERATE (6) | MODERATE (12) | HIGH (18) | HIGH (24) | HIGH (30) |
| 5 | MODERATE (5) | MODERATE (10) | MODERATE (15) | HIGH (20) | HIGH (25) |
| 4 | LOW (4) | MODERATE (8) | MODERATE (12) | MODERATE (16) | HIGH (20) |
| 3 | LOW (3) | MODERATE (6) | MODERATE (9) | MODERATE (12) | MODERATE (15) |
| 2 | LOW (2) | LOW (4) | MODERATE (6) | MODERATE (8) | MODERATE (10) |
| 1 | LOW (1) | LOW (2) | LOW (3) | LOW (4) | MODERATE (5) |
| LIKELIHOOD SCORE |
1 | 2 | 3 | 4 | 5 |
| IMPACT SCORE | |||||
In some cases where controls are identified that mitigate a risk, the Security Risk Team considers the CHER of the control that is established based on continuous monitoring performed by the Security Compliance Team. For details on how the Security Compliance Team rates observations, refer to the Observation Management handbook page.
Given that the scope of the StORM program is limited to Tier 2 Operational Risks, any information system level risks (i.e. Tier 3) identified within the organization are typically not included as part of the StORM program as Tier 3 risks should be addressed by one or more internal controls. However, should a control have a high CHER rating, this may be an indicator of a larger risk. Because of this, there are opportunities for Tier 3 risks to escalate to Tier 2 risks. The decision to escalate a Tier 3 risk in this manner will be documented within the Risk Details.
Each risk identified and triaged through the StORM program is required to undergo a risk treatment determination. This is an activity that will be discussed with each individual risk owner for the risks that they own.
| TREATMENT OPTION |
DEFINITION |
|---|---|
| Monitor (do nothing) | The risk level falls within our risk tolerance levels and no additional actions will be pursued at this time. Risks that have been treated, resulting in a risk score that is within the risk tolernace level will be given the status of Monitor within our GRC system. |
| Remediate the Risk | Complete a risk remediation plan to remediate the risk through: Sharing the risk (identify and implement solutions to share the risk with other parties), Reducing the likelihood of occurrence, and/or Reducing the level of impact to GitLab |
| Accept the Risk | Accept the risk because the value gained by GitLab outweigh the costs associated with pursuing other treatment options |
Once a risk treatment option is agreed upon, the Risk Owner will complete a Risk Treatment Plan which will be stored within our GRC application. The status of the risk treatment will be captured within our GRC application as well. Specific information about risk treatment options are documented below.
In the cases where a risk owner has concluded that a risk is low enough level, no additional action is required besides ensuring that the StORM Program DRI agrees with the treatment option.
When choosing to remediate the risk, a specific path must be selected:
Once a path is selected, the Risk Owner is required to provide a SMART, detailed plan that includes milestones and due dates for working towards risk remediation. The treatment plan must be achievable and address the root cause of the risk event. Additionally and in alignment with our value of Transparency, each treatment plan will include a step for documenting the results/outcome of the remediation within the Handbook. If the result of the remediation is considered not public and cannot be documented within the Handbook, it should be documented within our Internal Hanbook or an internal runbook. The Security Risk Team will leverage these risk treatment plans to track the status of risk remediation.
If the risk treatment plan is executed and results in a downgrading of the residual risk level for the risk (e.g., the residual risk level goes from High to Moderate), validation of the remediation will be performed and captured within the associated risk object in ZenGRC. Quality review of the downgrade support documentation will be completed by the Security Risk Manager and captured via comment in the GRC application.
In the cases where a risk owner has opted to pursue a risk acceptance, the following approvals will be required based on risk rating that was assigned to the risk undergoing a risk acceptance:
| Risk Level | Approval Level Required |
|---|---|
| HIGH | Risk Owner + Director/VP Level Approval* + E-group Level Approval |
| MODERATE | Risk Owner + Director/VP Level Approval* |
* If the Risk Owner is a Director/VP, no additional Director/VP level approval is required** If the Risk Owner is a Manager, no additional Manager level approval is requiredBy accepting the risk, the Risk Owner and risk acceptance approvers (if separate from Risk Owner), agree to reassess the risk on an annual basis to determine whether risk acceptance is the best treatment option for the respective risk. If risk acceptance is appropriate based on the annual assessment, approvals will be re-obtained based on the risk and approval requirements noted in the table above. Additionally, the Risk Owner will be on point for remediation in the event the risk is realized or risk acceptance is no longer appropriate.