Risk Management and Dispute Resolution

RMDR processes, policies, and resources

What we do

The Risk Management and Dispute Resolution (RMDR) division of GitLab Legal and Corporate Affairs (LACA) is responsible for informing and guiding GitLab’s risk management strategies as well as managing internal and external investigations, litigation and other dispute resolution. We seek to support resolution across a wide range of topics, including responding to subpoenas and discovery requests, drafting and revising legal documentation, managing investigations and negotiating and drafting agreements. It is our goal to proactively address and resolve these matters in support of GitLab’s business objectives, coordinating with internal business partners across the company whenever appropriate.

How to get in touch with RMDR

In support of these goals, we adopt this mantra: if you see something, say something!

  • If the question is of a general nature and does not require legal advice or discussion of confidential information, you can reach out to this team in Slack at #legal. We find this channel best for questions regarding process, who handles what, or how to find certain things if the handbook has not yielded the right result for you after searching. #legal is not a private channel, so your inquiry will be visible to the entire company.
  • You can also email rmdr@gitlab.com for matters where Slack may not be the appropriate forum to discuss.

When to get in touch with RMDR

There are times when GitLab team members must immediately consult with RMDR to ensure that GitLab is managing its legal risks effectively. These include:

  • If a team member receives a communication from a third party (i.e., a customer, vendor, partner, etc.) accusing the company of wrongdoing or demanding money from the company. A team member is not permitted to bind the company to pay money to settle a dispute without signoff from a member of the Legal and Corporate Affairs team.
  • If a team member receives a communication from an attorney representing a third party of any type, or other similar legal notice. If another party involves an attorney, GitLab must involve its RMDR team.
  • If a team member suspects wrongdoing within GitLab. RMDR can confidentially discuss such matters with the appropriate legal resources, as necessary.
  • If a team member has questions about the legal or regulatory landscape.
  • In the case of an emergency that may have legal implications, such as a cybersecurity incident or major system failure.

If in doubt, please involve RMDR earlier rather than later – we would always rather be proactive than reactive. You can reach out to RMDR via rmdr@gitlab.com.

Privilege

Privileged communication is communication, written or oral, that is protected from later disclosure in litigation because it was conveyed to the attorney in confidence by a client for the purpose of seeking legal advice or by an attorney for the purpose of giving legal advice. Privilege can also be asserted over certain confidential documents created by attorneys for the same purpose.

The terminology differs depending on the jurisdiction. For example, in the United States, the privilege is generally referred to as “attorney-client privilege” for communications made to or from an attorney for the purpose of providing legal advice or “attorney work product” for communication or documentations created in relation to actual or anticipated litigation. In many of our EMEA and APAC countries, it may be called “client legal privilege,” “legal professional privilege,” “legal advice privilege,” or “litigation privilege.” Additionally, the scope of the privilege differs by country. It is therefore likely that the status of a privileged communication that contains legal advice in respect of foreign law will be determined by reference to the law of the country in which any action is taken. If you have jurisdiction-specific questions about privilege, please contact a LACA team member who sits in that jurisdiction.

Practically speaking, this means that communications between our team members and members of LACA are not necessarily privileged just because a member of the LACA team is involved. As a threshold matter, the LACA team consists of both attorneys and non-attorneys. Communications may be privileged if the person wishing to assert the privilege can establish that the communication was made to an attorney of the LACA team and the dominant purpose of the communication was to seek legal advice. Conversely, if the dominant purpose of the communication - even if made to an attorney - is simply to seek business advice, it is very unlikely to be privileged. Additionally, otherwise privileged communication will lose its privilege in most circumstances if it is further or also disclosed to third parties. Thus, team members should always be aware of who has access to the communication and should be very careful about forwarding it.

What are some tips for team members to follow to help maintain privileged communication? Below are the steps you can take to help ensure that any communications you have with GitLab’s LACA team can be considered privileged:

  • When seeking legal advice in writing from an attorney in GitLab LACA, label the subject line of the email and the top of the email, document, or Slack message: “CONFIDENTIAL & PRIVILEGED ATTORNEY-CLIENT COMMUNICATION”.
  • End the communication by asking your attorney for a legal opinion and analysis. Simply including the attorney on a request for business advice will not create privilege.
  • When seeking legal advice orally, it should be clearly noted at the commencement of the discussion that its purpose is to enable you to obtain legal advice.
  • Do not disclose the contents of your communications with GitLab’s attorneys to anyone outside the company without consent of the attorney with whom you have exchanged the privilege communication, including friends or family members, and notify GitLab LACA department at ’legal@gitlab.com’ if any person from outside the company asks you to divulge privileged or confidential information.

For more information, please see the internal handbook here.

A legal hold is the process GitLab uses to preserve all forms of relevant evidence, whether it be emails, instant messages, physical documents, handwritten or typed notes, voicemails, raw data, backup tapes, and any other type of information that could be relevant to an investigation, pending or imminent litigation or when litigation is reasonably anticipated. Legal holds are imperative in preventing spoliation (destruction, deletion, or alteration) of evidence which can have a severely negative impact on a company’s case, including leading to sanctions. Once GitLab becomes aware of an investigation or potential litigation, a GitLab attorney will provide notice to the impacted team members, instructing them not to delete or destroy any information relating to the subject matter of the investigation or potential litigation. The legal hold applies to paper and electronic documents. During a legal hold, all retention policies must be overridden. Your obligation to follow the procedures outlined in the notice continues until the hold is lifted, even if you depart the Company. If you depart the Company, all Company owned devices and any material you are holding in accordance with any active Legal Hold Notice or active Company investigation should be turned over upon your departure.

Last modified June 27, 2024: Fix various vale errors (46417d02)