Security Risk Team

Security Risk Mission

To improve security at GitLab by enabling informed and intelligent decision making through proactive identification, monitoring, and reporting of security risks.

Core Competencies


Security Operational Risk Management (StORM) Program

An integrated Operational Risk Management program which focuses on the identification, assessment, continuous monitoring, and reporting of security risks across the organization. Visit 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.

Security Third Party Risk Management (TPRM) Program

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. Our program is integrated within the Procurement process and is built to continuously monitor third parties based on risk. Additional information can be found on the Third Party Risk Management handbook page.

Business Impact Analysis (BIA) and Critical System Tiering (CST)

The Business Impact Analysis (BIA) helps determine the systems critical to serving GitLab’s Customers. It also helps determine the prioritization of system restoration efforts in the event of a disruption.

The Security Risk Team facilitates a BIA for all new systems. A BIA is performed or previously collected BIA data is validated for existing systems based on Critical System Tiering (CST).

Asset Inventory Maintenance

Establishing a complete and accurate inventory of assets is key to the success of GitLab’s Risk Program. As such, the Security Risk Team collaborates closely with IT and Business Owners to ensure new systems are added to the Tech Stack and that associated data is maintained via our BIA processes.


Metrics and Measures of Success

Team Members

Team Member Role
Ty Dilbeck Manager, Security Risk
Eric Geving Senior Security Risk Engineer
Kyle Smith Senior Security Risk Engineer
Ryan Lawson Senior Security Risk Engineer
Nirmal Devarajan Security Assurance Engineer

Functional DRIs

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
TPRM Data Quality and Emerging Requirements Management Eric Geving
StORM Metrics and Reporting Kyle Smith
TPRM Metrics and Reporting Ryan Lawson

Contact the Team

Return to the Security Assurance Homepage


Security Operational Risk Management (StORM) Program & Procedures
This is a Controlled Document Inline with GitLab’s regulatory obligations, changes to controlled documents must be approved or merged by a code owner. All contributions are welcome and encouraged. Not a GitLab team member but want to provide feedback on our StORM program? We receive feedback from GitLab team members regularly and we wanted to provide a mechanism for non-GitLab team members to provide feedback as well to help us iterate and align more closely with our values.
Security Third Party Risk Management
This is a Controlled Document Inline with GitLab’s regulatory obligations, changes to controlled documents must be approved or merged by a code owner. All contributions are welcome and encouraged. Purpose GitLab’s Security Third Party Risk Management (TPRM) Program helps guard against security threats posed by third parties who have access to GitLab data or that of our customers. These risks may include data breaches, unauthorized use or disclosure, and corruption or loss of data.
SOX CUEC Mapping Procedure
Purpose In accordance with ITGC SR.1 - SOC Report Review, GitLab executes annual CUEC mappings of our internal controls to each SOC report associated with a SOX in scope application to ensure controls are adequately designed to address the CUEC requirements outlined in the SOC report. This activity is executed in Q1 of each fiscal year in order to gain the greatest coverage for the prior fiscal year. Scope Formal CUEC mappings are limited to SOX in scope third party SaaS applications as defined by management.
Last modified September 6, 2023: Replace taps with spaces (69f17a79)