The purpose of the ERM program at GitLab is to identify, assess and develop action plans for the top enterprise-wide risks that could impact the company’s ability to achieve our strategies and objectives. ERM will also help us to build a more risk aware culture by coordinating our efforts with Security Operational Risk Management Program.
Our ERM program is authorized by the Audit Committee of the Board of Directors and GitLab senior management and will be conducted using key elements of COSO Enterprise Risk Management – Integrating with Strategy and Performance.
GitLab’s ERM program is designed to assess operational, strategic, financial and compliance risks that could impact GitLab’s operations, financial results and/or reputation. All processes and systems implemented by GitLab to achieve its strategic objectives are in scope for ERM.
Enterprise risks will be evaluated using three common risk assessment criteria:
A governance structure has been established to outline the overall roles and responsibilities for ERM at GitLab.
| Role | Responsibility |
|---|---|
| Audit Committee Chairperson | Provides Board of Directors oversight of the ERM program. |
| Senior Leadership Team | Sets the “risk awareness” tone for GitLab and approves the risk appetite, risk assessment criteria and risk treatment plans for identified key risks. Drives direct reports in their respective business units to comply with the ERM program. |
| ERM Steering Committee | Provides oversight and recommendations on risk appetite, risk criteria, risk treatment and overall coordination of material risk assessment activities at GitLab. The committee will be comprised of: → Chief Financial Officer → Principal Accounting Officer → Senior Internal Audit Manager → Chief Legal Officer → Director of Legal Corporate → Chief Technology Officer → Vice President of Security → Director, Security Risk & Compliance |
| Principal Accounting Officer | Executive Sponsor and provides oversight of Internal Audit’s execution of the ERM program and works with the senior leadership team to ensure efficient and timely execution of the program |
| Senior Internal Audit Manager | Responsible for coordinating and executing the ERM program and working with other GitLab risk assessment functions to ensure alignment on risk appetite, risk criteria and risk treatment |
| Risk Owners | Makes decisions for their specific organizations and provides insight into the day-to-day operational procedures executed by their organization in support of Risk Treatment planning. Responsible for driving risk acceptance and/or implementing remediation activities for the risks identified |
Our approach to ERM implementation is as follows:
Step 1 – Understand key strategies and OKRs.
Step 2 – Develop a Risk Appetite matrix to determine those high-level risks that GitLab is willing to take and not willing to take in the furtherance of the company’s strategies and objectives. This includes determining the maximum amount of risk the company is willing to accept in pursuit of value.
Step 3 – Document a Risk Assessment Criteria matrix to objectively state the definitions for high, moderate and low enterprise risk for GitLab. GitLab evaluates enterprise risk using three objective criteria: likelihood, impact and velocity.
A composite risk score is then determined by multiplying likelihood times impact.
Step 4 – Identify each key business process and the owners of those processes, that are directly related to the achievement of GitLab’s strategic objectives. This step forms the basis for the list of executives that will be interviewed or surveyed as part of the ERM assessment.
Step 5 – Using the common risk themes from the interviews and surveys, as well as the outputs from the StORM risk assessment, Internal Audit assembles a list of top risks to the company. Those risks are then evaluated by risk category (strategic, operational, compliance and financial), and a business impact statement is then documented for each risk to develop a common understanding of the impact to GitLab if the risk were not addressed. The results are plotted on a heat map to show relative impact, likelihood and velocity of the risks. Please note at this stage, the key risks are categorized based on the results of interviews and surveys; no direct testing will have been performed to audit the risk themes.
Step 6 – A risk treatment owner will be identified for each top risk. Each risk owner will be sent a survey asking them to develop a risk treatment that addresses the root cause of the risk with key action steps, process/system dependencies and/or obstacles with due dates for completion. Depending on the category or severity of the risk, a risk owner may be asked to present their risk plan and status to senior management and or the Audit Committee.
The results of the ERM risk assessment will also be used as the basis for the creation of an internal audit plan. Internal Audit will conduct independent reviews of key areas of the company to determine whether processes and systems are functioning as intended and whether process owners are following GitLab policies and procedures, as well as good operating practices.
Internal Audit will communicate the top risks to management and the audit committee. Internal Audit will update the risk assessment on an annual basis or more frequently as the needs of the business changes. At the conclusion of the annual risk assessment, Risk Treatment Plans (RTPs) will be documented that summarize the: risk statement, the potential impact to GitLab, the type of risk (strategic, operational, financial or compliance), the assigned owner that will ensure the risk treatment is accomplished and a due date for the completion of the RTP. RTP status will be shared with the Audit Committee on a regular basis.
The outputs of the ERM program are as follows:
As per GitLab's Communication Page, information about risks tracked in GitLab's Risk Register defaults to not public and limited access. Given the nature of risk management, GitLab will always be susceptible to risks. The goal of implementing risk treatment plans and carrying out risk remediation activities is to reduce the likelihood or impact (or both) of a risk occurring. Given that no risks identified can ever be fully eliminated, but instead are mitigated through reduction of likelihood and/or impact, risks that have been escalated to GitLab's Risk Register will be shared on a need-to-know basis. GitLab’s enterprise risk register will be maintained and monitored by Security Compliance and Internal Audit function.
