Introduction

This document explains some of the key concepts in information security risk management, as well as explaining how to carry out the actions required by Sourcegraph’s Information Security Risk Management Policy.

Knowledge of the policy, including details of the required actions and definitions of key terms, is assumed within this document. In other words, please read the policy if you haven't already!

Risk register

Sourcegraph's security team maintains an information security risk register tracked in our GRC tool. This risk register tracks high-level issues which could affect the confidentiality, integrity, or availability of the data Sourcegraph manages. As it is high-level, the risk register does not contain specific technical vulnerabilities. Instead, it tracks security concerns which require medium- to long-term effort to rectify.

The risk register is the source of truth for Sourcegraph’s information security risks. To edit the Risk Register, you must be a member of the Security team; if you do not have access and believe you might require it, email [email protected].

Risk Identification, Assessment Schedule, and Methodology

This section outlines how risks are identified, when assessments are conducted, and the methodologies used to evaluate and manage risks.

Risk identification

Information security risks can be identified in one of two ways:

• Ad-Hoc Risk Identification:

  Employees can report potential risks at any time by emailing details to [email protected]. The Security team member on the support rota ensures that:

  • The email is acknowledged
  • Any unclear details about the risk in question are clarified with the person reporting the risk
  • Estimates of inherent and residual risk are created according to the process described in the Information Security Risk Management Policy. Only Security team members are able to add new risks and set information security risk estimates.
  • A risk manager is assigned. An appropriate risk manager should have good knowledge of the risk area in question, and should be able to coordinate and drive any required risk treatments.
  • If required, a treatment plan with a due date is defined
  • A risk owner will be assigned and notified about risk treatment plan
  • The new risks will be reviewed during the scheduled quarterly risk reviews and adjusted accordingly

  Security team members are also free to raise and triage risks in this manner as required.

• Scheduled Risk Identification:

  Risks may also be identified during quarterly risk review sessions or through ongoing assessments conducted by the Security team. These reviews ensure that new risks are identified systematically and existing risks remain relevant.

Risk Assessment Triggers

In addition to quarterly assessments, risk assessments may also be initiated in response to specific events or triggers that could indicate a shift in the organization's risk landscape. These triggers include:

• Introduction of New Technologies: Deployment of new systems, critical tooling or software.
• Organizational Changes: Changes in structure, new departments, or shifting responsibilities.
• Regulatory or Legal Updates: New compliance requirements or changes to existing laws.
• External Events: Industry-specific incidents, economic or geopolitical shifts, or emerging global risks.
• Security Incidents: Breaches, vulnerabilities, or other significant security events.