To improve security at GitLab by enabling informed and intelligent decision making through proactive identification, management, and transparent reporting of operational security risks.
An Operational Risk Management program which focuses on the identification, assessment, tracking, and overall management of security risks across the organization. Check out the StORM Program & Procedures handbook page for additional details, including a quick introduction to Risk Management at GitLab as well as information about the purpose, scope, and specific procedures executed as part of the program.
Need to communicate a potential risk to the team?
Please refer to the communication section of the StORM Program & Procedures page for information on the various ways that team members can use to escalate potential risks to the Security Risk Team.
Every system at GitLab is assigned a critical system tier. The Security Risk Team owns the tiering methodology that establishes each system's tier. For more information about the methodology and inputs utilized to determine tiering, refer to the Critical Systems Tiering Methodology handbook page.
The Security Risk Team conducts a BIA for all new systems and periodically for existing systems based on their CST. The data collected as part of this process are used in various ways such as ensuring system inventory data is accurate and identifying potential risks. For more information about the BIA process and procedures, refer to the Business Impact Analysis handbook page.
The TPRM Program is focused on identifying and assessing the incremental security risk impact that may develop over the lifecycle of GitLab's relationship with various third parties. Additional information on the scope of these reviews, including the various third parties subject to this program, can be found on the Third Party Risk Management handbook page.
While the DRI is the individual who is ultimately held accountable for the success or failure of any given project, they are not necessarily the individual that does the tactical project work. The DRI should consult and collaborate with all teams and stakeholders involved to ensure they have all relevant context, to gather input/feedback from others, and to divide action items and tasks amongst those involved.
DRIs are responsible for ensuring a handbook-first approach to their project(s) and challenging existing processes for efficiency.
| Function | DRI |
|---|---|
| Annual Risk Assessment | Kyle Smith |
| Business Impact Analysis - Design And Requirements | Kyle Smith |
| Business Impact Analysis - Reporting and Periodic BIA Execution | Nirmal Devarajan |
| Critical System Tiering | Kyle Smith |
| Ongoing SecRisk-Related Observations Management | Ty Dilbeck |
| Ongoing Risk Treatment | Kyle Smith |
| Ongoing TPRM Assessments | Ryan Lawson |
| Periodic SOX CUEC Facilitation | Eric Geving |
| Periodic TPRM Assessments | Eric Geving |
| StORM Metrics and Reporting | Kyle Smith |
| TPRM Metrics and Reporting | Ryan Lawson |
securityrisk@gitlab.com@security-risk@gitlab-com/gl-security/security-assurance/security-risk-team