FY27 Controlled Doc - STORM

- Control testing results identify gaps and weaknesses

- Compliance findings map back to Risk Register items including [risk treatment plans](/handbook/security/security-assurance/security-risk/storm-program/#remediate-the-risk)

- Testing coverage data informs [risk response decisions](/handbook/security/security-assurance/security-risk/storm-program/#risk-response)

- Control effectiveness metrics are leveraged as Key Risk Indicators (KRIs) in [Quarterly Risk Reporting](/handbook/security/security-assurance/security-risk/storm-program/#storm-reporting-schedule)

- Control effectiveness metrics are leveraged as Key Risk Indicators (KRIs) in [Quarterly Risk Reporting](/handbook/security/security-assurance/security-risk/storm-program/#top-5-risks)

### Benefits of Integration

The scope of the STORM program is limited to operational, technology-agnostic risks. These risks can be identified in many ways including Risk Assessments, reports from team members, [industry trends](https://github.com/jacobdjwilson/awesome-annual-security-reports), or as a result of compliance activities. There may be instances where an application's role is so significant to internal controls that we may create risks specifically for that system. This will primarily be limited to GitLab.com as its use is pervasive in all that we do.

**Out of Scope** Unless they are related to a STORM risk (for example security compliance observations that span multiple systems), the following risk-types are not in scope for STORM:

**Out of Scope** Unless they are related to a STORM risk, the following risk-types are not in scope for STORM:

1. Operational risks that are not security or technology-related are out of scope (ex. accounting-specific risks)

1. [Individual, system-specific security compliance observations](/handbook/security/security-assurance/observation-management-procedure/) (ex. inadequate password settings for a specific system)

| ------ | ------ |

| Executive Risk Owner | - Accountable for driving treatment for one or more of GitLab's Top 5 Security Risks <br>- Responsible for identifying one or more Risk Owners. Security Risk recommends identifying at least one Risk Owner per department involved in risk treatment <br>- Responsible for approving the long-term risk treatment plan including the creation of KRs to associated treatment milestones identified by Risk Owners and the Security Risk Team <br>- Note that most Executive Risk Owners will be CEO + 2 (Senior Director or VP-level) and will be responsible for cross-department collaboration to drive risk reduction over time |

| Risk Owners |  - Responsible for the creation of a long-term risk treatment plan including treatment milestones meant to reduce  residual risk over time <br>- Accountable for executing risk treatment activities <br>- Responsible for collaborating with the Security Risk Team to ensure associated risk(s) and treatment status are reported periodically <br>- Note that most Risk Owners will be CEO + 3 (Senior Manager or Director level) |

| Security Risk Manager | This role is assigned per risk to a specific Security Risk team member. Expectations include:<br>- Maintains knowledge on the history, current-state, and direction of their risk<br>- Works with the risk owner or owners to ensure the risk status and treatment is documented<br>- Identifies, monitors, and participates in associated issues/MRs/epics/working groups that are relevant to their assigned risk<br>- Validates remediation activities<br>- Maps risks to relevant <a href="/handbook/security/security-assurance/security-compliance/sec-controls/#gitlab-control-framework-gcf">GCF controls</a>, <a href="https://gitlab.com/groups/gitlab-com/gl-security/security-assurance/-/epics?state=opened&page=1&sort=start_date_desc&label_name[]=Observation+Epics">Root Cause Observation Epics</a>, Security Compliance Tier 3 Observations</a>, <a href="/handbook/security/security-assurance/field-security/field-security-study/">Field Security Study Observations</a>, and other observations noted from security-impacting assessments (internal-only) <br>- Collaborates with Executive Risk Owner and Risk Owners to create and monitor long-term risk treatment plans|

| Security Risk Manager | This role is assigned per risk to a specific Security Risk team member. Expectations include:<br>- Maintains knowledge on the history, current-state, and direction of their risk<br>- Works with the risk owner or owners to ensure the risk status and treatment is documented<br>- Identifies, monitors, and participates in associated issues/MRs/epics/working groups that are relevant to their assigned risk<br>- Validates remediation activities<br>- Maps risks to relevant <a href="/handbook/security/security-assurance/security-compliance/sec-controls/#gitlab-control-framework-gcf">GCF controls</a>, Security Compliance Tier 3 Observations, and other observations noted from security-impacting assessments (internal-only) <br>- Collaborates with Executive Risk Owner and Risk Owners to create and monitor long-term risk treatment plans|

| Security Risk Team | - Coordinates and executes STORM procedures including establishing risk appetite and conducting risk assessments<br>- Maintains the risk register to ensure accuracy and currency<br>- Acts in a Program Management capacity to support the tracking of risk treatment activities<br>- Coordinates peer validation testing after all risk remediation activities have been completed <br>- Periodically reports on the status of security and technology operational risks <br> - Provides management level oversight of the STORM program, including continuing reviews of GitLab's Risk Register and acts as a point of escalation as needed <br>- Responsible for approving significant changes and exceptions to this procedure|

## STORM Procedures

### Establishing Risk Appetite and Tolerance

**Tone at the Top**: GitLab's STORM methodology uses a defined Risk Appetite and Risk Tolerance as primary drivers to determine which risks GitLab are willing to accept/take versus which risks we will need to mitigate. These thresholds are defined by Senior Leadership across the organization to ensure the Tone at the Top is aligned with the STORM program. Risk Appetite and Tolerance are reassessed year-to-year. This is done through an annual Risk Appetite Survey based on the [ISO 31000 Risk Management Methodology](https://www.iso.org/standard/65694.html). The survey is distributed to individuals operating in a Senior Leadership capacity with direct relations to Security Operations. The responses are averaged to arrive at an overall risk appetite and tolerance.

**Tone at the Top**: GitLab's STORM methodology uses a defined Risk Appetite and Risk Tolerance as primary drivers to determine which risks GitLab are willing to accept/take versus which risks we will need to mitigate. These thresholds are defined by Senior Leadership across the organization to ensure the Tone at the Top is aligned with the STORM program. Risk Appetite and Tolerance are reassessed year-to-year. This is done Annually as part of our Annual Risk Assessment (ARA) activity based on [ISO 31000 Risk Management Methodology](https://www.iso.org/standard/65694.html). Historically this has been carried out via survey or workshop.

#### How GitLab Determines Risk Appetite

- GitLab should respond to all risks impacting the organization, regardless of the level of impact (risk response approach)

- GitLab should respond to risks based on cost, management priorities, and ROI (risk response drivers)

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:

GitLab utilizes the following risk appetite matrix:

| RISK APPETITE<br>APPROACH | RISK SEEKING | RISK RECEPTIVE | RISK NEUTRAL | RISK AVERSE |

| ---- | ---- | ---- | ---- | ---- |

*GitLab's Risk Appetite Matrix was formed through consideration of guidance set forth in NIST's [SP 800-39](https://csrc.nist.gov/pubs/sp/800/39/final) and [SP 800-30 Rev. 1](https://csrc.nist.gov/pubs/sp/800/30/r1/final).*

Scoring is performed by individuals operating in at least Senior Leadership capacity within GitLab and spans across multiple departments.

#### Translating GitLab's Security Risk Appetite to Risk Tolerance

Our risk appetite is translated to a tolerance which defines a range in which a [risk score value](#risk-factors-and-risk-scoring) is tolerable and does not require remediation or a risk acceptance, that is, the risk response will be set to "monitor". Risk scores can range from 1 (lowest) to 30 (highest). The range is defined per Risk Appetite in the table below:

1. (**Preferred**) Submit a [Risk Escalation issue](https://gitlab.com/gitlab-com/gl-security/security-assurance/security-risk-team/STORM/-/issues/new?issuable_template=risk-escalation) on the STORM Repo.

1. If the risk is identified within an issue, team members can tag the team directly by @ mentioning `@gitlab-com/gl-security/security-assurance/security-risk-team` on the issue or MR

When documenting risks, team members can leverage [description guidance](/handbook/security/security-observations-risk-management/#drafting-finding-description-guidance) for existing issues/observations or [risk drafting guidance](#risk-drafting-guidance).

When documenting risks, team members can leverage [finding description guidance](/handbook/security/security-observations-risk-management/#drafting-finding-description-guidance) for existing issues/observations or [risk drafting guidance](#risk-drafting-guidance) for net-new risks.

#### Risks identified during risk assessments

#### Risk Drafting Guidance

STORM Program considerations include both risks (what might happen) and observations (what has happened/non-compliance). For guidance on writing observations, please refer to the[Observation Management Procedure Handbook page](/handbook/security/security-assurance/observation-management-procedure/).

STORM Program considerations include both risks (what might happen) and observations (what has happened/non-compliance).

When drafting a risk, start with a risk statement. This will represent the title of the Risk in our GRC system and is an attempt to condense the risk into a single sentence. In the spirit of [low-context communication](/teamops/decision-velocity/#low-context-communication), avoid using single words or short phrases for the risk statement (ex. Supply Chain). As we largely deal with negative risks (vs. positive risks/opportunities), starting the statement with negative language like "Failure to", "Inadequate", "Incomplete", "Lack of", etc. is appropriate, but not required. As risks represent what might happen, use "may" before describing the negative effect it *may* have on the confidentiality, integrity, availability, security, and privacy of GitLab data. Example: *Inadequate physical security controls may result in the loss of GitLab/Customer data and physical assets.* The risk description should contain details related to the assets/resources at risk, the event that may occur, the source that would trigger the event (root cause), and the consequence (impact/loss) [source](https://www.srmam.com/post/how-to-write-a-risk-statement).

### Risk Tracking and Reporting

Identified risks are formally tracked in an internal risk register. Given the nature of the sensitivity of this information in aggregate, the risk register is [not made public](/handbook/communication/confidentiality-levels/#not-public), and is not distributed externally. However, a publicly viewable GitLab Risk Register Template is available [here](https://docs.google.com/spreadsheets/d/1Lvn-ZjPNcZ-QMh-pkC6HqjwR-acUf70V9w2pquhRmH0/edit?usp=sharing) for those interested in getting some more insight into the type of information tracked in GitLab's risk register. STORM-related risk activities are centralized [within GitLab](https://gitlab.com/gitlab-com/gl-security/security-assurance/security-risk-team/STORM-risk-register/-/issues/?sort=weight_desc&state=opened&first_page_size=100) (internal only).

Identified risks are formally tracked in an internal risk register. Given the nature of the sensitivity of this information in aggregate, the risk register is [not made public](/handbook/communication/confidentiality-levels/#not-public), and is not distributed externally. However, a publicly viewable GitLab [Risk Register Template is available](https://docs.google.com/spreadsheets/d/1Lvn-ZjPNcZ-QMh-pkC6HqjwR-acUf70V9w2pquhRmH0/edit?usp=sharing) for those interested in getting some more insight into the type of information tracked in GitLab's risk register. STORM-related risk activities are centralized [within GitLab](https://gitlab.com/gitlab-com/gl-security/security-assurance/security-risk-team/STORM-risk-register/-/issues/?sort=weight_desc&state=opened&first_page_size=100) (internal only).

We report on our top 5 risks on a quarterly basis (the Security Risk Quarterly or "SRQ") in alignment with our values. To learn more about the SRQ, please see this [YouTube unfiltered overview video]. The template we've used can be found [here](https://docs.google.com/document/d/1cpBbn_0kIWpEzbzLrzEcVesN-3Y0y1K6SD6wiv0-Vaw/edit?usp=sharing) for reference. Additionally, we perform an annual exercise to refresh our Risk Appetite and our Top 5 risks.

We report on our top 5 risks on a quarterly basis (the Security Risk Quarterly or "SRQ") in alignment with our values. To learn more about the SRQ, please see this [YouTube Unfiltered overview video](https://www.youtube.com/watch?v=sHZr-5SR7yg). See our [SRQ template](https://docs.google.com/document/d/1cpBbn_0kIWpEzbzLrzEcVesN-3Y0y1K6SD6wiv0-Vaw/edit?usp=sharing) for reference. Additionally, we perform an annual exercise to refresh our Risk Appetite and our Top 5 risks.

The STORM program is integrated within daily operations at GitLab. As such, we have mapped our STORM risks to risk sources including [Security Compliance controls and observations](/handbook/security/security-assurance/observation-management-procedure/) and [Product Security's Risk Register](/handbook/security/product-security/security-platforms-architecture/risk-register/). Our mapping exercises are intended to provide a more comprehensive view of our security risk landscape and to enable STORM engineers to more quickly identify and escalate risks.

## Top 5 Risks

The Security Division's "Top 5 Risks" are established annually and are reported upon quarterly as resources allow through the SRQ. Security Leadership leverages these Top 5 Risks when conducting short and long-term strategic planning activities. We intend to support remediation through assisting with treatment activities and performing design and operating effectiveness assurance testing on key remediation activities.

The Security Division's "Top 5 Risks" are established annually through our Annual Risk Assessment (ARA) and are reported upon quarterly as resources allow through the SRQ. Security Leadership leverages these Top 5 Risks when conducting short and long-term strategic planning activities. We intend to support remediation through assisting with treatment activities and performing design and operating effectiveness assurance testing on key remediation activities.

### Long-Term Risk Treatment Planning

In the event the Executive Risk Owner chooses not to pursue a Risk Remediation-related KR in a given quarter due to competing priorities, a [Risk Acceptance](/handbook/security/security-assurance/security-risk/third-party-risk-management/#tprm-security-notice-process) should be formalized to document the business rationale. This Risk Acceptance should contain rationale explaining why the risk of delaying additional Risk Remediation is less than the risk of not fulfilling the competing priority.

### STORM Reporting Schedule

The table below outlines planned/completed activities for FY25.

|Timing|Activities|

|-----|-----|

|Q1| SRQ |

|Q2| SRQ, Annual Refresh Planning, and AI Risk Assessment |

|Q3| SRQ with refreshed risk appetite and Top 5 risks |

|Q4| SRQ |

## Exceptions

The only exceptions to this procedure are those risks that are out of scope (as defined above).