Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Code of Business Conduct & Ethics and GitLab People Policy Directory

On this page

Code of Business Conduct & Ethics

GitLab is committed to serving our customers and employing individuals with personal standards consistent with that of our values. This Code is designed to deter wrongdoing and to promote:

Our Code applies to all directors, officers, employees, and contractors of GitLab and its affiliates and subsidiaries. Agents and vendors of GitLab are also expected to read, understand, and abide by this Code.

This Code should help guide your conduct in the course of our business. Many of the principles described in this Code are general in nature, and the Code does not cover every situation that may arise. Use common sense and good judgment in applying this Code. If you have any questions about applying the Code, please seek guidance. Not all information regarding the conduct of our business is found in this Code. Please review the applicable policies and procedures in specific areas as they apply as found in our Team Handbook.

The Code of Conduct will be reviewed on an annual basis to ensure compliance with applicable laws and industry standards.

Complying with the Code

To maintain the highest standards of integrity, we must dedicate ourselves to complying with this Code, company policies and procedures, and applicable laws and regulations. Violations of this Code not only damage our company’s standing in the communities we serve, they may also be illegal. Team members involved in violating this Code will likely face negative consequences. GitLab will take the appropriate disciplinary action in response to each case, up to and including termination. In addition, team members involved may be subject to government fines, or criminal or civil liability.

Reporting Violations

If you think this Code or any GitLab policy is being violated, or if you have an ethics question, you have several options:

All reports (formal or informal) made to a GitLab supervisor, manager or executive should be promptly escalated to People Business Partners and the Legal team. GitLab will then review the report promptly and thoroughly to determine if an investigation is warranted.

Investigation Process

If Legal has determined it appropriate, GitLab will promptly initiate an appropriate investigation into all possible violations of law and/or GitLab policy. The Vice President of Legal Affairs will engage the People Business Partner assigned to the business department to investigate all reports unless:

Outside counsel will be retained by Legal to conduct the investigation if:

The Board of Directors will be notified of any complaints made against a member of the executive team alleging illegal conduct and/or egregious unethical conduct.

GitLab expects all employees and contractors to cooperate fully and candidly in investigations.

Investigation Timeline

GitLab will make all reasonable efforts to initiate an investigation into the allegation(s) and conclude the investigation in a timely fashion. Depending on the type of investigation the steps and timeline for each investigation will vary.

Investigation Findings

The investigation findings will be reported back to the VP of Legal. Based on the investigation findings, Legal will make a determination as to whether the allegation(s) were founded, unfounded or inconclusive. This determination will be documented in writing and made part of the investigation report. The determinations are as follows:

How to Contact GitLab's 24-hour hotline:

GitLab has engaged Lighthouse Services to provide an anonymous ethics and compliance hotline for all team members. The purpose of the service is to insure that any team member wishing to submit a report anonymously can do so without the fear of retribution.

Reports may cover but are not limited to the following topics: ethical violations, wrongful discharge, unsafe working conditions, internal controls, quality of service, vandalism and sabotage, sexual harassment, theft, discrimination, conduct violations, alcohol and substance abuse, threats, fraud, bribery and kickbacks, conflict of interest, improper conduct, theft and embezzlement, violation of company policy, violation of the law, misuse of company property, falsification of contract, reports or records.

Please note that the information provided by you may be the basis for an internal and/or external investigation into the issue you are reporting and your anonymity will be protected by Lighthouse to the extent possible by law. However, your identity may become known during the course of the investigation because of the information you have provided. Reports are submitted by Lighthouse to a company designee for investigation according to our company policies.

Lighthouse Services toll free number and other methods of reporting are available 24 hours a day, 7 days a week for use by team members.

The reports sent to Lightouse Services are shared with the VP of Legal and Chief People Officer.

Commitment to Non-Retaliation

Any employee or contractor who reports a violation will be treated with dignity and respect and will not be subjected to any form of discipline or retaliation for reporting in good faith. Retaliation against anyone who provides information or otherwise assists in an investigation or proceeding will be treated as a violation of this Code.

Discrimination

Having a diverse workforce, made up of team members who bring a wide variety of skills, abilities, experiences and perspectives, is essential to our success. We are committed to the principles of equal opportunity, inclusion, and respect. All employment-related decisions must be based on company needs, job requirements, and individual qualifications. Always take full advantage of what our team members have to offer; listen and be inclusive.

Report suspected discrimination right away and never retaliate against anyone who raises a good faith belief that unlawful discrimination has occurred. Employees and contractors should refer to the GitLab Anti-Harassment Policy for more information.

Harassment

Every employee or contractor has a right to a work environment free from harassment, regardless of whether the harasser is a co-worker, supervisor, manager, customer, vendor, or visitor. Please refer to the GitLab Anti-Harassment Policy for more information. As is the case with any violation of the Code, you have a responsibility to report any harassing behavior or condition, whether you are directly involved or just a witness.

Fair Wages

Our company is committed to following all applicable wage and working hours laws and regulations. To help ensure that all work performed for GitLab is compensated correctly, team members compensated on the basis of hours worked must report and record time accurately. For more information on compensation, please refer to our Compensation Principles.

Substance Abuse

GitLab strives to maintain a workplace that is free from illegal use, possession, sale, or distribution of alcohol or controlled substances. Legal or illegal substances shall not be used in a manner that impairs a person’s performance of assigned tasks. This will help to maintain the efficient and effective operation of the business, and to ensure customers receive the proper service. GitLab team members must also adhere to the local laws of where they reside and where they travel to, including the GitLab Summit.

Employee Information Privacy

GitLab respects the confidentiality of the personal information of employees and contractors. This includes employee and contractor medical and personnel records. All team member records are kept in BambooHR. Team members have self service access to their profile. Where available, documents and information are shared with the team member within the platform. If a team member would like to view their entire profile from the admin view, please schedule a call with People Operations Specialists to walk through a screen share or request screenshots to be sent to your personal email address. Access to personal information is only authorized when there is a legitimate and lawful reason, and access is only granted to appropriate personnel. Requests for confidential employee or contractor information from anyone outside our company under any circumstances must be approved in accordance with applicable laws. It is important to remember, however, that employees and contractors should have no expectation of privacy with regard to normal workplace communication or any personal property used for GitLab business.

If there is no requirement within someone's job description to be public-facing, then team members can opt-out of any public exposure. Team members can opt-out of being added to the team page or what content about them is shown on the team page and can use either only their initials or an alias if desired. Since GitLab publishes much of our content, including video calls and meetings, the only way to ensure no unwanted exposure from these videos is to have video turned off and initials or an alias added to the Zoom profile name whenever a call is being recorded. Zoom shows whether a call is being recorded at the top right of the video screen, and team members are always encouraged to ask if a video will be shared or not. For any GitLab livestreams through YouTube, a team member can watch and comment through YouTube instead of through the internal video call. Any questions can be sent directly to our People Business Partners and Legal teams.

Employee Privacy Policy

This Employee Privacy Policy (“Privacy Policy”) explains what types of personal information we may collect about our employees and how it may be used.

While this Privacy Policy is intended to describe the broadest range of our information processing activities globally, those processing activities may be more limited in some jurisdictions based on the restrictions of their laws. For example, the laws of a country may limit the types of personal information we can collect or the manner in which we process that information. In those instances, we adjust our internal policies and practices to reflect the requirements of local law.

For personal data collected under this Privacy Policy, the controller will be GitLab and the GitLab affiliates by which you are employed. For specific security concerns around your data, please contact your respective Data Protection Officer (“DPO”) at the following email address:

In the event you feel that you have not received proper attention to your data concern, or if you have any other legal/law enforcement concern - please contact GitLab's Legal Department at Legal@gitlab.com.

GitLab, Inc. is a global company with its headquarters in the U.S. This means that personal information may be used, processed, and transferred to the United States and other countries or territories and those countries or territories may not offer the same level of data protection as the country where you reside, including the European Economic Area. However, GitLab will ensure that appropriate or suitable safeguards are in place to protect your personal information and that transfer of your personal information complies with applicable data protection laws. Where required by applicable data protection laws, GitLab has ensured that service providers (including other GitLab affiliates) sign standard contractual clauses as approved by the European Commission or other supervisory authority with jurisdiction over the relevant GitLab data exporter (which typically will be your employer).

Who is collecting your personal data (who is the data controller)?

The GitLab entity that is a party to your employment contract or contract for services or otherwise employees you will be the data controller of your personal data. The following are the GitLab entities that act as controller: GitLab, Inc., GitLab, LLC., GitLab BV, GitLab GmbH, GitLab, LTD, GitLab PTY Ltd, GitLab Canada, GitLab IT BV, and other GitLab subsidiaries throughout the globe ("collectively "GitLab").

GitLab affiliates may act as processors on behalf of other GitLab affiliates and/ or controllers. Furthermore, the GitLab its affiliates and subsidiaries participate in group-wide IT system in order to harmonize GitLab’s IT infrastructure and its use (the “System”). The System also may hold data on all employees, workers, individual contractors and contingent workers ("Staff"). Insofar the System serves to improve and harmonize most of the human resources (“HR”) processes within GitLab. GitLab, Inc. in the US is responsible for the System.

Applicability of Other GitLab Privacy Policies

The websites of GitLab (e.g., www.GitLab.com) have separate privacy policies and terms of use that apply to their use. Additionally, some of our third party products and services may have separate privacy policies and terms of use that apply to their use. Any personal information collected in connection with your use of those websites or products and services are not subject to this Privacy Policy. If you are unsure how or if this Privacy Policy applies to you, please contact your DPO or Privacy Officer.

Third Party Services

In some cases, you may provide personal information to third parties that GitLab works with or that provide services to GitLab. This includes, those parties identified in the Tech Stack Application document (“Third Parties”).

The Tech Stack is updated periodically to ensure accurate, up-to-date disclosure of employee and customer third party applications used at GitLab. This particular policy applies to those applications identified as relating to Employee applications. The use of such Third Party websites may be governed by separate terms of use and privacy policies which are not under our control and are not subject to this Privacy Policy. Please contact such Third Parties for questions regarding their privacy practices, as well as if you would like to have them modify, update, alter or delete your personal information. Please understand that there are exceptions to rights surrounding personal data relating to employment. GitLab is required to maintain certain employment information by law.

What is Personal Information?

Personal information, also known as personally identifiable information or personal data, for purposes of this Privacy Policy means any information that (i) directly and clearly identifies an individual, or (ii) can be used in combination with other information to identify an individual. Personal information does not include such information if it is anonymous or if it has been rendered de-identified by removing personal identifiers.

Examples of personal information include:

What is Sensitive Personal Information?

Sensitive personal information is a subset of personal information that may be more sensitive in nature for the individual concerned.

Examples of sensitive personal information include:

What Personal Information Do We Collect?

We collect and maintain different types of personal information about you in accordance with applicable law. This includes the following:

Where permitted by law and applicable we may collect the results of credit and criminal background checks, screening, health certifications, driving license number, vehicle registration and driving history.

For specifics about what information is collected by third party applications, please refer to the Tech Stack Applications.

Apart from personal information relating to yourself, you may also provide us with personal data of related parties, notably your dependents and other family members, for purposes of your HR administration and management, including the administration of benefits and to contact your next-of-kin in an emergency. Before you provide such third-party personal data to us you must first inform these third parties of any such data which you intend to provide and of the processing to be carried out by us. You must ensure and secure evidence that these related parties, or their legal representatives if they are minors, have given their free and express consent that their personal data may be processed by GitLab and/or its affiliates and subcontractors for the purposes described in this Privacy Policy.

How is Data Collected?

Generally, we collect personal information directly from you in circumstances where you provide personal information (during the onboarding process, for example). However, in some instances, the personal information we collect has been inferred about you based on other information you provide us, through your interactions with us, or from third parties. When we collect your personal information from third parties it is either because you have given us express consent to do so, your consent was implied by your actions (e.g., your use of a Third-Party employee service made available to you by us), or because you provided explicit consent to the Third-Party to provide the personal information to us. Where permitted or required by applicable law or regulatory requirements, we may collect personal information about you without your knowledge or consent.

We reserve the right to monitor the use of our equipment, devices, computers, network, applications, software, and similar assets and resources for the safety and protection of employees and intellectual property. In the event such monitoring occurs, it may result in the collection of personal information about you. If required by applicable law, we will notify you of such monitoring and obtain your consent.

How We Process and Use Your Personal Information

We may collect and process your personal information in the Systems for various purposes subject to local laws and any applicable collective bargaining agreements and works council agreements, including:

Additional information regarding specific processing of personal data may be notified to you by locally.

Legal Basis for processing

Where applicable data protection laws require us to process your personal data on the basis of a specific lawful justification, we generally process your personal data under one of the following bases:

Compliance with a legal obligation to which GitLab is subject; Entering into at-will employment (for US only) or performance under an employment contract with GitLab; For GitLab's legitimate interests being those purposes described in the section above headed "How We Process and Use Your Personal Information"; Your consent where required and a legitimate legal basis under applicable local laws.

We may on occasion process your personal data for the purpose of the legitimate interests of a Third-Party where this is not overridden by your interests.

Processing of Special Categories of Personal Data

“Special Categories of Personal Data” includes information revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, health, sex life or sexual orientation, as well as genetic and biometric data.

From time to time you may provide us with information which constitutes Special Categories of Personal Data or information from which Special Categories of Personal Data may be deduced. In such cases, where required by law, we will obtain your express written consent to our processing of Special Categories of Personal Data. If separate consent is not required by local law, by providing this information to GitLab, you give your freely given, informed, explicit consent for us to process those Special Categories of Personal Data for the purposes set out in How We Process and Use Your Personal Information section above.

You may withdraw your consent at any time by contacting your Local HR Department or DPO. Where you have withdrawn consent but GitLab retains the personal data we will only continue to process that Special Category Personal Data where necessary for those purposes where we have another appropriate legal basis such as processing necessary to comply with legal obligations related to employment or social security. However, this may mean that we cannot (for example) administer certain benefits or contact your next-of-kin in an emergency or provide support to you above and beyond our legal obligations. You give your knowledgeable, freely given, express consent to GitLab for GitLab to use, disclose and otherwise process any personal health information about you that is provided to GitLab by any of your personal health information custodians, for the purposes set out in the How We Process and Use Your Personal Information section above.

Sharing Personal Information

Your personal information may be shared, including to our affiliates, subsidiaries, and other third parties, as follows:

Access to Personal Information We Collect

To the extent access is required by applicable law, you can ask to see the personal information that we hold about you. If you want to review, verify or correct your personal information, please submit a request to the HR Department or DPO.

When requesting access to your personal information, please note that we may request specific information from you to enable us to confirm your identity and right to access, as well as to search for and provide you with the personal information that we hold about you. We may, in limited circumstances, charge you a fee to access your personal information; however, we will advise you of any fee in advance.

We reserve the right not to grant access to personal information that we hold about you if access is not required by applicable law. There are also instances where applicable law or regulatory requirements allow or require us to refuse to provide some or all of the personal information that we hold about you. In addition, the personal information may have been destroyed, erased or made anonymous. In the event that we cannot provide you with access to your personal information, we will inform you of the reasons why, subject to any legal or regulatory restrictions.

Correction of Collected Personal Information

We endeavor to ensure that personal information in our possession is accurate, current and complete. If an individual believes that the personal information about him or her is incorrect, incomplete or outdated, he or she may request the revision or correction of that information. We reserve the right not to change any personal information we consider to be accurate or if such correction is not required by applicable law.

Retention of Collected Information

Except as otherwise permitted or required by applicable law or regulatory requirements, we may retain your personal information only for as long as we believe it is necessary to fulfill the purposes for which the personal information was collected (including, for the purpose of meeting any legal, accounting or other reporting requirements or obligations) and for IT archival purposes.

Personal data for data subjects in the European Union is by default erased by GitLab after termination of your employment, with the exception of certain types of personal data, which may be stored for an extended period of time due to administrative purposes, e.g. for payment of retirement income or for giving references to other employers, or where such personal data must be retained to comply with regulatory requirements.

You may request that we delete the personal information about you that we hold, provided that we reserve the right not to grant such request if we are not required to delete personal information under applicable law. There are instances where applicable law or regulatory requirements allow or require us to refuse to delete this personal information. In the event that we cannot delete your personal information, we will inform you of the reasons why, subject to any legal or regulatory restrictions.

Requests to Access, Delete, or Correct Information

Please send requests to access, delete, or correct your personal information to your DPO.

Any request by you to us to delete your personal information will not result in deletion of any information submitted by you to a Third-Party provider. If you require the Third-Party to delete any of your personal information, you must contact the Third-Party directly to request such deletion.

As stated previously, there are instances where applicable law or regulatory requirements allow or require us to refuse to delete this personal information. In the event that we cannot delete your personal information, we will inform you of the reasons why, subject to any legal or regulatory restrictions.

Resolving Concerns

If you have questions or concerns regarding the handling of your personal information, please contact your local HR Department or DPO. Alternatively, you may report concerns or complaints to the Legal Department.

You may also anonymously report violations of policy or law using our Third-Party managed Compliance & Fraud Prevention Hotline. You can access the Hotline by going to How to Contact GitLab's 24 Hour Hotline

Changes to Privacy Policy

We may change this Privacy Policy at any time by posting notice of such a change in the revision table below. The effective date of each version of this Privacy Policy is identified the revision table.

Security of Collected Information

We are committed to protecting the security of the personal information collected, and we take reasonable physical, electronic, and administrative safeguards to help protect the information from unauthorized or inappropriate access or use.

Additional Rights You may also have the following additional rights, subject to certain exceptions and limitations as specified in applicable law:

Data portability

Where we are relying upon your consent or the fact that the processing is necessary for the performance of a contract to which you are party as the legal basis for processing, and that personal information is processed by automatic means, to the extent provided under applicable law, you have the right to receive all such personal information which you have provided to GitLab in a structured, commonly used and machine-readable format, and also to require us to transmit it to another controller where this is technically feasible;

Right to restriction of processing

You have the right to restrict our processing of your personal information where:

To the extent required by applicable law, where personal information is subjected to restriction in this way we will only process it with your consent or for the establishment, exercise or defense of legal claims.

Right to withdraw consent

Where we are relying upon your consent to process data, you have the right to withdraw such consent at any time. You can do this by contacting your local HR Department or DPO.

Right to object to processing justified on legitimate interest grounds

Where we are relying upon legitimate interest to process data, then you have the right to object to such processing, and we must stop such processing unless we can either demonstrate compelling legitimate grounds for the processing that override your interests, rights and freedoms or where we need to process the data for the establishment, exercise or defence of legal claims. Normally, where we rely upon legitimate interest as a basis for processing we believe that we can demonstrate such compelling legitimate grounds, but we will consider each case on an individual basis.

You also have the right to lodge a complaint with a supervisory authority, in particular in your country of residence, if you consider that the processing of your personal data infringes this regulation.

Proprietary and Confidential Information

In carrying out GitLab’s business, team members often learn confidential or proprietary information about our company, its customers, prospective customers, or other third parties. Team members must maintain the confidentiality of all information entrusted to them, except when disclosure is authorized or legally mandated.

Confidential or proprietary information includes:

GitLab’s confidentiality provisions can be found in the employee and contractor templates, but these may vary from what you agreed to at the time of your contract. For specific information about your obligations regarding confidentiality, please reference your contract.

In addition to confidentiality obligations owed to third parties, we also have obligations to protect the personal and sensitive information of our fellow team members. Therefore, you may not access and/or disseminate any team member's personal information (i.e. address, personal phone number, salary, etc.) that the team member has not made publicly available, unless the team member has provided written permission to share the information. An exception to this restriction would be when access is a necessary function of your job duties. A violation of this obligation is considered severe and could result in disciplinary action, up to and including termination.

Physical Assets and Resources

All employees and contractors must protect our company assets, such as equipment, inventory, supplies, cash, and information. Treat company assets with the same care you would if they were your own. No employee or contractor may commit theft, fraud or embezzlement, or misuse company property.

GitLab Internal Acceptable Use Policy

The Gitlab Internal Acceptable Use Policy specifies requirements related to the use of GitLab computing resources and data assets by GitLab team-members so as to protect our customers, team members, contractors, company, and other partners from harm caused by both deliberate and inadvertent misuse. Our intention in publishing this policy is not to impose restrictions but outline information security guidelines intended to protect GitLab assets.

Proper Use of Electronic Media

Our company uses global electronic communications and resources as routine parts of our business activities. It is essential that electronic resources used to perform company business are protected to ensure that these resources are accessible for business purposes and operated in a cost-effective manner, that our company’s reputation is protected, and that we minimize the potential for legal risk.

In addition to following the Social Media Guidelines, when utilizing social media think about the effects of statements that you make. Keep in mind that these transmissions are permanent and easily transferable, and can affect our company’s reputation and relationships with team members and customers. When using social media tools like blogs, Facebook, Twitter or wikis, ensure that you do not make comments on behalf of GitLab without proper authorization. Also, you must not disclose our company’s confidential or proprietary information about our business, our suppliers, or our customers.

Protecting Customer/Third Party Information Privacy

We take the protection of privacy for our customer’s, consumer’s, and other third parties that have entrusted us with information very seriously. Customer or third party information includes any information about a specific customer/third party, including such things as name, address, phone numbers, financial information, etc. Specifically, note that:

If you do not have a business reason to access this information, you should not do so. If you do, you must also take steps to protect the information against unauthorized use or release in line with our Security Best Practices.

Intellectual Property and Protecting IP

Our intellectual property is among our most valuable assets. Intellectual property refers to creations of the human mind that are protected by various national laws and international treaties. Intellectual property includes copyrights, patents, trademarks, trade secrets, design rights, logos, expertise, and other intangible industrial or commercial property. We must protect and, when appropriate, enforce our intellectual property rights. We also respect the intellectual property belonging to third parties. It is our policy to not knowingly infringe upon the intellectual property rights of others.

  1. Take proper care of any confidential information you get from our customers.
  2. As an employee or contractor, the things you create for GitLab belong to the company.
    • This work product includes inventions, discoveries, ideas, improvements, software programs, artwork, and works of authorship. This work product is the company’s property (it does not belong to individuals) if it is created or developed, in whole or in part, on company time, as part of your duties or through the use of company resources or information.
  3. If you copy code always check the license and attribute when needed or appropriate.
  4. Check community contributions and do not merge it when there can be doubt about the ownership.
  5. Only certain authorized individuals may sign legal documents such as NDAs. Please refer to our signature policy
  6. View our DMCA policy in regards to copyright / intellectual property violations

Assignment of intellectual property is addressed in the employee and contractor templates, but these may vary from what you agreed to at the time of your contract. For specific information about your obligations regarding intellectual property rights and obligations, please reference your contract.

Antitrust and Fair Competition

All directors, officers, employees, and contractors must comply with antitrust and competition laws which prohibit collusive or unfair business behavior that restricts free competition. These laws are quite complicated, and failure to adhere to these laws could result in significant penalties imposed on both GitLab and the employees and/or contractors who violated the law.

Unlawful behavior examples:

Such laws prohibit efforts and actions to restrain or limit competition between companies that otherwise would be competing for business in the marketplace. You must be particularly careful when you interact with any employees, contractors or representatives of GitLab’s competitors, especially at trade association meetings or other industry or trade events where competitors may interact. Under no circumstances should you discuss customers, prospects, pricing, or other business terms with any employees or contractors or representatives of our competitors.

If you are not careful, you could find that you have violated antitrust and competition laws if you discuss or make an agreement with a competitor regarding:

Depending on business justification and effect on competition, other practices not involving competitors may also result in civil violations of the antitrust and competition laws. These practices include:

We engage in open and fair procurement activities regardless of nationality or the size of the transaction. Suppliers are selected on a competitive basis based on total value, which includes quality, suitability, performance, service, technology, and price. We strive toward establishing mutually beneficial relationships with our suppliers based on close cooperation and open communication. Terms and conditions defining our relationship with suppliers are communicated early in the supplier selection process. Any agreements to such terms and conditions, or any acceptable modifications, are reached before work begins.

Honest Advertising and Marketing

It is our responsibility to accurately represent GitLab and our products in our marketing, advertising, and sales materials. Deliberately misleading messages, omissions of important facts or false claims about our products, individuals, competitors or their products, services, or employees or contractors are inconsistent with our values. Sometimes it is necessary to make comparisons between our products and our competitors. When we do, we will make factual and accurate statements that can be easily verified or reasonably relied upon.

Obtain Competitive Information Fairly

Gathering information about our competitors, often called competitive intelligence, is a legitimate business practice. Doing so helps us stay competitive in the marketplace; however, we must never use any illegal or unethical means to get information about other companies.

Legitimate sources of competitive information include:

When working with consultants, vendors, and other partners, ensure that they understand and follow GitLab policy on gathering competitive information.

Anti-Money Laundering

Money laundering is a global problem with far-reaching and serious consequences. Money laundering is defined as the process of converting illegal proceeds so that funds are made to appear legitimate, and it is not limited to cash transactions.

Complex commercial transactions may hide financing for criminal activity such as terrorism, illegal narcotics trade, bribery, and fraud. Involvement in such activities undermines our integrity, damages our reputation and can expose GitLab and individuals to severe sanctions.

Our company forbids knowingly engaging in transactions that facilitate money laundering or result in unlawful diversion. Anti-money laundering laws require transparency of payments and the identity of all parties to transactions. We are committed to full compliance with anti-money laundering laws throughout the world and will conduct business only with reputable customers involved in legitimate business activities and transactions.

Selection and Use of Third Parties/Procurement (Fair Purchasing)

We believe in doing business with third parties that embrace and demonstrate high principles of ethical business behavior. We rely on suppliers, contractors, and consultants to help us accomplish our goals. They are part of the GitLab team and should be treated according to our values. To create an environment where our suppliers and consultants have an incentive to work with GitLab, they must be confident that they will be treated in an ethical manner. We offer fair opportunities for prospective third parties to compete for our business. The manner in which we select our suppliers and the character of the suppliers we select reflect on the way we conduct business.

Anti-corruption / Anti-bribery

Globally, many countries have laws that prohibit bribery, kickbacks, and other improper payments. No GitLab employee, contractor, officer, agent, or vendor acting on our behalf may offer or provide bribes or other improper benefits in order to obtain business or an unfair advantage. You must avoid participating in commercial bribery and kickbacks, or even the appearance of it, in all of our business dealings. Even in locations where such activity may not technically be illegal, it is absolutely prohibited by our company policy.

Definitions

  1. Commercial bribery involves a situation where something of value is given to a current or prospective business partner with the intent to obtain business or influence a business decision.
  2. Kickbacks are agreements to return a sum of money to another party in exchange for making or arranging a business transaction.
  3. A bribe is defined as directly or indirectly offering "anything of value" to influence or induce action, or to secure an improper advantage.
  4. "Anything of value" is very broadly defined and can include such things as:
    • Cash
    • Gifts
    • Meals
    • Entertainment
    • Travel and lodging
    • Personal services
    • Charitable donations
    • Business opportunities
    • Favors
    • Offers of employment

Situations

  1. No employee or contractor shall make or promise to make, directly or indirectly, any payment of money or object of value to any foreign official of a government, political party, or a candidate for political office for the purpose of inducing or influencing actions in any way to assist our company in obtaining or retaining business for or with GitLab.
  2. The exchange of appropriate gifts and entertainment is often a way to build our business relationships. However, you must conduct business with customers, suppliers, and government agencies (including U.S. and non-U.S. governments) without giving or accepting bribes including (but not limited to) commercial bribery and kickbacks.

Gifts and Entertainment

Modest gifts, favors, and entertainment are often used to strengthen business relationships. However, no gift, favor, or entertainment should be accepted or given if it obligates, or appears to obligate, the recipient, or if it might be perceived as an attempt to influence fair judgment.

In general, unless you have supervisory approval you should not provide any gift or entertainment to customers, suppliers, or others that you would not be able to accept from a customer, supplier, or other applicable parties.

All directors, executives, and anyone else in the company participating in vendor selection, must disclose all gifts and entertainment valuing over US$250 for the six months prior to the vendor selection and during the term of the services and for a period of twelve months after services have been completed. The disclosure shall be made to the Legal department, and shall include the value of the gift or entertainment, the individual or company providing the gift, favor, or entertainment, and the date on which it was received. If you have any questions relating to this section, feel free to contact the Legal department.

Trade Compliance (Export/Import Control)

GitLab is not to engage in activities that could threaten foreign policy and national security interests of the United States or other countries in which GitLab has facilities, international peace and security by distribution of products to end-users that could violate applicable export control laws. This Trade Compliance Policy defines the security transaction controls and control procedures to be developed and implemented at GitLab.

What?

An export is the transfer of goods, technology, technical data and software transfer to a foreign country or a foreign national. Be advised that “export” includes downloads, electronic access to technology, emails and even visual reviews.

Goods, Technology, Technical Data & Software Transfers

Goods, technology, technical data & software transfers may be subject to Export Administration Regulations (the “EAR”) and also to the export control laws of other countries in which GitLab operates. For example, exports by GitLab from Canada would be subject to the EAR and also to Canada’s Export and Import Permits Act and the Canadian Export Control List (the “ECL”). For export purposes, technology and technical data includes any information that can be used or adapted for use in the design, development, manufacture, utilization, or reconstruction of products or commodities. This can include more than tangible items. For example, intangible items such as technical services, presentations, product demonstrations and software would be included in technology and technical information for the purposes of export control laws.

For the purposes of the EAR, an export of technology, technical data, and/or software is defined as the release of technology or software subject to the EAR, released in a foreign country and/or any release of technology or source codes (does not include object codes) subject to the EAR to a foreign national. Release to foreign nationals is deemed to be an export to the home country or countries of the foreign national (a “Deemed Export”). Some other countries, such as Canada, do not control Deemed Exports under their export control laws, however, US export control laws will still apply to Deemed Exports within those countries.

A Deemed Export does not apply to persons lawfully admitted for permanent residence in the United States (“green card” holders) and does not apply to persons who are protected under the Immigration and Naturalization Act.

It is possible that a license may have to be obtained prior to visits with foreign nationals or discussions of technical information with foreign nations, whether these occur at US facilities or in other countries.

Release for Export includes:

Visual inspection by foreign nationals of U.S. equipment and facilities such as demonstrations and on-site training;
Oral and written exchanges of information in the U.S. or abroad. This includes exchange or transmission of information through any media such as facsimile, email, internet, intranet, telephone, downloading, or causing the downloading, of software to locations outside the U.S. or to foreign nationals.
Applications of situations abroad of personal knowledge or technical experience acquired in the U.S.; or Downloading or actual physical shipment of the technology or software. Similar rules apply in other countries in respect to what is or is not considered to be an export.

NOT subject to Export Administration Regulation (EAR) Control The following technology, technical data and software are not subject to and are outside the scope of the EAR. However, other policy controls and restrictions may apply:

Technology, technical data and software that is publicly available, meaning published in periodicals, books, print, or electronic media that is available to the public at a price that does not exceed the cost of reproduction or distribution; Data that is readily available at universities or other public libraries; All patent information available at any patent office; All technical data presented at open conferences, meetings, seminars or trade shows, provided the gathering is open to all technically qualified members of the public and that attendees are permitted to take notes or otherwise make a record of the proceedings; Technology, technical data or software arising during, or resulting from, fundamental research (as described in the EAR); or Technology, technical data or software that is educational in nature (as described in the EAR).

Other countries have similar exemptions, however, the specific exemptions for each country should be reviewed if technology, technical data or software is being exported from those countries to make sure that the exemptions recognized under U.S. law are also recognized under the law of the applicable country from which an export is being considered.

Release of information into the public domain is a conscious decision on the part of GitLab. In many cases, technology (in the form of product data sheets or technical specifications) has been released through distribution at public trade shows. Technology in the form of detailed drawings for production or manufacturing procedures is not public domain data.

How?

Items are given special classification numbers (ECCNs). These numbers help determine whether a license is required. To determine an ECCN, you must know the ECCNs of the technology that was included in the overall export. Items that are EAR99 are the easiest to export. That said, the addition of a highly-regulated piece of technology can change the overall ECCN of the entire product. Other countries have their own classification systems that specify what is and is not controlled under their export control laws. When obtaining new good, software or technology from third party – make sure you know the ECCN or if an ECCN is not available, the applicable foreign law classification for the applicable good, software or technology.

Company Type Classification GitLab’s current product Export Control Classification Number is 5D992.c. (Contact the Legal Department for a copy of letter.)

New Projects/Products/Tenders The relevant business unit will work with The Legal Department to determine the export classification of new software as soon as possible during the project. Please note that changes to the encryption functionality may require a new export classification. This will usually occur after feature scope is determined and the origin of technologies to be used in the project is known. If an applicable product is going to be exported from GitLab’s facilities outside of the U.S., then an export classification will also need to be done for that country.

Ongoing Surveillance of Export Classification All Product Classification sheets will be reviewed annually to ensure the export classification of the software has not changed, if GitLab is still exporting that software. GitLab will also monitor regulation changes that might affect the classification of GitLab products or other items that could be exported.

Standard Terms and Conditions of Sale Our standard terms and conditions of sale contain text substantially similar to the following: *Exports and U.S. Government Rights. The Products furnished to you may be subject to export and other restrictions under the laws and regulations of the United States of America and other countries. You hereby agree that you shall not transfer, export or re-export, directly or indirectly, any Product or technical data received from GitLab to any destination or entity subject to export or other restrictions under the laws and regulations of the United States of America or any other applicable countries unless prior written authorization is obtained from GitLab and the appropriate United States and applicable foreign agencies. The Products are provided with Restricted Rights. Use, duplication or disclosure by the U.S. government is subject to restrictions as set forth in (a) this Agreement pursuant to DFARs 227.7202-3(a); (b) subparagraph (c)(1)(i) of the Rights in Technical Data and Computer Software clause at DFARs 252.227-7013; or (c) the Commercial Computer Software Restricted Rights clause at FAR 52.227-110 subdivision (c)(1) and (2), as applicable. *

Where?

Some countries (and nationals of those countries) are prohibited from accessing US Technology.

Countries prohibited from receiving any technology include: Cuba, Iran, North Korea, Sudan, Syria and the Crimean Region of the Ukraine.

US Government Classified Information must only be accessible by US Citizens who have appropriate clearance and a need to know. If you know or believe GitLab is in receipt of US or Foreign Government Classified Information, please contact Legal or Compliance.

Additionally, companies cannot agree to boycott any other country. If you receive any request to boycott a country, please notify Legal.

Embargoed Countries The United States restricts imports and exports to certain destination without a specific authorization from the government. Products exported to an entity within an embargoed country or to a foreign national of that country, e.g., Cuba, Iran, North Korea, Sudan, Syria, and the Crimean Region of the Ukraine will require a license, even if the shipment is through a reseller or via another country. Some countries have legislation that prohibits the imposition of U.S. embargo requirements on individuals and companies in those countries (“Blocking Legislation”).

U.S. Anti-Boycott U.S. Anti-Boycott regulations exist to counteract foreign economic boycotts that are at odds with U.S. policy. It is GitLab's policy to comply with the requirements of Anti-Boycott regulations. Actions prohibited by the regulations include:

Refusing (or agreeing to refuse) to do business with entities “blacklisted” under a foreign boycott. Discriminating against a person based on race, religion, sex, national origin, or nationality condemned by a foreign boycott. Furnishing information that would assist in furthering a foreign boycott. Implementing letters of credit that include prohibited boycott terms or conditions.

Employees encountering requests or issues to avoid certain countries, nationals or protected individuals should contact Legal immediately. Under certain circumstances, the anti-boycott laws may require filing a report with the U.S. Department of Commerce regarding the request to participate in the boycott even if the employee correctly refuses to participate. Other countries have similar anti-boycott provisions.

Who?

Some people have been prohibited from receiving technology by various government agencies. To ensure that a particular person or entity is not prohibited, a Denied Party Screen must be completed before any export occurs. Companies with whom GitLab does business, must undergo a due diligence review which includes a Denied Party Screen, valid contract and background check of the entity.

Due Diligence If there are any suspicions about any particular customer, reseller, or order, they should be discussed with the Export Compliance Officer or Legal.

There must be sufficient information provided about a customer to ensure a proper Denied Party Screen can be completed. If this information is missing, the Sales person shall contact the reseller or the end-user to ask them to provide the requisite information.

To ensure traceability the individual performing the Denied Party Screen shall record the end-user site details for all approved orders received directly from end-users as well as any resellers. It is important to always be assured that the end-user and the end-use is legitimate.

Denied Party Screens Prior to the release of technology to a foreign country or foreign national, sales operations, order processing, shipping, engineering and/or licensing shall ensure that the receiving person or entity is not on an Export Control Watch List by conducting a Denied Party Screen. If an export is being done from a country other than the U.S., then the denied parties list for that country will need to be checked in addition to the US denied persons screening. If any of the customers are on any of the Export Control Watch Lists, the Transaction will be escalated to the Export Control Officer who will work with the relevant departments and government agencies to determine if the delivery is allowed. It is important to note that products that are being shipped to an entity on the Export Control Watch Lists will require a license, even if the shipment is through a reseller or via another country. The outcome of this Legal determination will be binding. The completion of this check will be recorded in the appropriate records and in the appropriate customer record in GitLab’s salesforce.com system.

Why?

In some cases, an End Use Certificate may be required from the End User of a product to confirm legitimate uses of the product being exported. If you are suspicious of the intentions of a purchaser, consult Legal.

End Use GitLab's Products are designed and intended for commercial use. In the event that GitLab knows or had reason to know that a customer seeks to use GitLab products for improper or nefarious purposes, please contact Legal so that the appropriate End Use statements can be obtained.

If you have any questions or concerns about anything herein, please contact Compliance@gitlab.com.

Government Customers/Contracting

We must ensure all statements and representation to government procurement officials are accurate and truthful, including costs and other financial data. If your assignment directly involves the government or if you are responsible for someone working with the government on behalf of GitLab, be alert to the special rules and regulations applicable to our government customers. Please review GitLab's Public Sector Rules of Engagement for more details on dealing with the US Federal Government. Please note that government agencies, in general (US or otherwise) have more strenous requirements than traditional customers. Be aware of the heightened sensitivity around dealing with any government entity or foreign official.

Any conduct that could appear improper should be avoided when dealing with government officials and employees or contractors. Payments, gifts, or other favors given to a government official or employee are strictly prohibited as it may appear to be a means of influence or a bribe. Failure to avoid these activities may expose the government agency, the government employee, our company, and you to substantial fines and penalties.

Record Retention Policy

This Records Retention Policy promotes and assists with the implementation of procedures, best practices, and tools to promote consistent life cycle management of GitLab records. Because records contain important information, it is essential to take a systematic approach to the management of records.

1. Records Management Records management addresses the life cycle of records, i.e., the period of time the records are in the possession of GitLab.
The life cycle usually consists of three stages: 1) Creation or receipt; 2) Maintenance or use; and 3) Destruction or retention. This policy is used in conjunction with the Records Retention Schedule.
Records retention does not mean permanent retention. There are certain situations where documents must be preserved permanently, but most records need only be retained for a specified period of time. When the retention period for a particular record expires, we should destroy or delete the record. However, if we destroy or delete a record before its retention period expires, GitLab may be subject to penalties and sanctions. Unnecessary retention of records creates significant burdens for GitLab. For example, unnecessary records take up valuable storage space and make retrieval of needed records more difficult and costly. Consequently, GitLab recommends destruction of records after the retention period expires, except in those instances where GitLab directs otherwise (such as when a Litigation Hold is issued by the Legal Department). In other words, GitLab requires adherence to the records retention requirements and recommends the destruction of records according to the Retention Schedule.

2. The Difference between a “Record” and “Non-Record” GitLab Records Retention Policy is based on a fundamental distinction between a “record” and a “non-record.” GitLab Records Retention Schedule applies only to “records.” Therefore, it is important to understand the difference between a “record” and a “non-record.”

2.1 What is a “record”?
A “record” is a Document created or received by a GitLab entity or individual in the transaction of business that contains significant business value. It is maintained to memorialize GitLab’s policies, procedures, functions, decisions, operations, processes or other business activities. The business value of a record is derived from the legal, regulatory, fiscal, operational, or informational significance of the content.
“Records” must be retained throughout their life cycle in accordance with GitLab Records Retention Schedule.
“Document” as used above is a piece of written, printed or electronic matter that provides information or evidence or otherwise serves as an official record and can include software application files, paper, slide presentations, spreadsheets, CAD drawings, electronic images, pictures, emails, faxes, and the like.

2.2 What is a “non-record”? Simply stated, a “non-record” is everything that does not qualify as a “record.” Non-records are materials that GitLab does not own, materials without substantive business value, or materials that have only temporary use as reference or reminders. They are not subject to GitLab Records Retention Schedule and should be discarded when no longer needed. Examples of non-records include: Correspondence that is only needed for a short period of time and does not have substantive business value; Calendars; Informational items such as publications and extra copies of documents kept only for convenience or reference; personal or casual correspondence, Reminders and ticklers that are needed only for a short period of time and do not have substantive business value. This would include things like reminders, “post-it” notes or superseded drafts.

2.3 The difference between an original record and a copy The original record represents GitLab’s official version of any information asset. Original records may be created by a GitLab employee, received by GitLab from an outside source, or may be forms processed by a GitLab department. A copy of a record is typically a duplicate that was created for dissemination or handy reference. There is no obligation to retain copies. Copies may be disposed of when they are no longer needed.

3. Responsibility for Developing and Managing Records GitLab employees are responsible for making and keeping records of their work. In that regard, they have four basic obligations: Create records needed to do the business of GitLab, record decisions on actions taken, and document activities for which they are responsible.

Maintain records in a legible and readily identifiable format.

Take care of records so that information can be found when needed. This means setting up adequate directories and files, and filing materials regularly and carefully in a manner that allows them to be safely stored and efficiently retrieved when necessary.

Carry out the destruction or retention of records under their control; This includes transferring records to storage or destruction of records in accordance with GitLab Records Retention Schedule and verifying records are destroyed in a manner conducive to prevent the release of sensitive information into the public domain (i.e. erasing, shredding, etc.) The individual or department that maintains the official version of a record is responsible for managing the record. This is known as the Record Owner. The Record Owner is responsible for the use, retention, and destruction of that record, unless and until a record is officially transferred to a designated archive or storage center.

4. Management of Electronic Records The Record Owner ensures that electronically-generated records are identified, and the systems used to store the records comply with this Records Retention Policy and Records Retention Schedule. Records may be managed in either a paper format or an electronic format. Electronic recordkeeping systems must be designed to ensure the security and integrity of the records, preservation of records for the time when they are needed, and migration of data to other GitLab systems or subsequent systems. Consequently, GitLab records should not be maintained solely on the personal hard drive, flash drive, or directories of a GitLab employee assigned only for that person’s use. GitLab employees should create an electronic filing system located in the appropriate server for their department or function, with specific folders for each employee and for each matter, and transfer their GitLab records to those folders, or at least copy them to those folders, as soon as possible after those records are created.

4.1 Emails and Slack Much of the business conducted today is done by email and Slack. GitLab has separate policies with regard the use of GitLab managed messages and attachments, which covers such things as communication etiquette, prohibited use and content of communications, password and encryption key security and integrity, GitLab’s right to access information, confidential GitLab information, privileged communications and personal use of email.
Email and Slack communications are subject to the same records retention procedures that apply to other documents and must be retained in accordance with GitLab Records Retention Schedule. The following guidelines apply to emails and Slack:

The status of any particular communication (i.e., whether it is a record and its retention period) is determined by its content, not the method of delivery.

The responsibility of maintaining and retaining an internally created and distributed document most often falls on the author, not the recipient.

GitLab employees who receive emails from outside GitLab are responsible for proper management of those communications. In an effort to be environmentally conscious, the printing of emails for record retention purposes discouraged.

GitLab strongly discourages the storage of voluminous non-record email messages because of the limited value of such messages, and the cost and confusion associated with unmanaged retention and proliferation of email. Unmanaged retention of messages fills up storage space on the network servers, extends the amount of time to backup data, requires additional resources to maintain, slows performance, and can potentially lead to an inaccurate history of GitLab because it is haphazard and incomplete. As a general rule, employees are encouraged to promptly delete any non-record email messages they send or receive that no longer require action and are no longer necessary to GitLab’s business. If a non-record email no longer has business value, it should be deleted.

5. Retention Period The retention periods for specific types of records are set forth in GitLab Records Retention Schedule. The Records Retention Schedule will ensure that records are safely preserved until the retention period has expired. GitLab recommends that the records be destroyed in the normal course of business in accordance with the Records Retention Policy and Records Retention Schedule. In some instances, GitLab may choose to permanently preserve information for business or historical reasons. Such records are specifically designated in the Records Retention Schedule.

6. GitLab Records Retention Schedule GitLab Records Retention Schedule establishes the retention periods for various types of records. It applies to all records, regardless of format. Retention of records according to the Records Retention Schedule must be observed to ensure consistent application of reasonable due diligence in recordkeeping practices.

GitLab’s Records Retention Program promotes the destruction of records and other documents at the earliest possible time, in accordance with the following principles:

All records should be promptly destroyed pursuant to GitLab Records Retention Schedule. As discussed above, "non-record” materials are not subject to the Records Retention Schedule and should be discarded when no longer needed.

The retention periods in the Records Retention Schedule applies to the "original" version, or official record, of each information asset. Copies of records should be destroyed when they are no longer needed.

All Record Control processes will contain documented procedures clearly defining methods for identifying, storing, protecting and retrieving Records.

Identification methods should include a recommended destruction date and a mechanism for efficient retrieval of the information.

Storage will be in such a form as to preserve the integrity of the data and prevent eroding, tampering or altering the data.

Protection of the stored information will be in such a form as to ensure the integrity of the storage mechanism.

Retention will be, at a minimum, for the time period set forth in the Retention Schedule.

Records will be properly disposed of once the respective retention period has lapsed.

Disposal of the information will be in such a form as to protect the sensitive nature of the information therein and prevent release into the public domain.

Litigation Holds or other non-destruct directives issued by GitLab’s Legal Department override any destruction authority granted by the Records Retention Schedule. In addition, destruction of non-record materials identified in the Litigation Hold is suspended.

When the decision is made to destroy GitLab information, it must be destroyed/erased in a secure and confidential manner that is appropriate to the sensitivity of the informational content. Employees will consult the Data Classification and Handling Procedures for details on retention, destruction and storage of all Records.

7. Litigation Holds
GitLab is occasionally the subject of threatened or pending litigation or administrative proceedings. Such proceedings may suspend the normal operation of GitLab Records Retention Policy. Where appropriate, GitLab will issue a “Litigation Hold” to certain employees, departments or the entire GitLab. The Litigation Hold will provide a description of records and other documents that must be preserved. The failure to preserve records, documents and other evidence could subject GitLab to fines or sanctions. It is therefore very important to manage documents and other evidence in strict accordance with the Litigation Hold.

8. Special Situations

8.1 Mergers and acquisitions Documents that may come into the possession of GitLab through the acquisition of another business entity, or through mergers or other agreements, are subject to GitLab Records Retention Policy. Such documents will be promptly screened and managed in accordance with the Policy directives.

8.2 Consolidations In the event of consolidations, such as a facility closure, GitLab will continue to manage records associated with such facilities in accordance with GitLab Records Retention Policy. The following guidelines apply: All records should be transferred to the new Record Owner, or as directed by GitLab. Legal Department must be informed of the identity of the new Record Owner and provided a description of the records transferred. If a successor Record Owner is not identified, GitLab records will be transferred to the department or office most closely associated with the record’s business function. For instance, personnel files without new Record Owners must be forwarded to the Corporate HR Department.
All other records must continue to be managed in accordance with GitLab Records Retention Policy. To ensure this, Legal Department must be involved in all decisions concerning the destruction or transfer of such records.

8.3 Employee Moves (Office Moves, Reassignments and Termination of Employment) Employees are responsible to follow GitLab’s Policy for ensuring that records are properly maintained. When an employee’s duties are being reassigned or the relationship with the employee is terminated, each employee should conduct an inventory of records and other materials in his or her possession and follow the steps listed below: If the employee has any records that belong in department files, follow the procedures for ensuring that those records are properly stored in the appropriate location. Dispose of non-record materials as soon as the employee no longer needs them.
Remove or destroy any personal materials. Employees are reminded that materials relating to their jobs cannot be removed without GitLab’s permission. Identify active records that are needed for current business and arrange for their transfer to the new Record Owner or as directed. The supervisor of the former employee whose employment was terminated is responsible for compliance with the steps described above.

8.4 Contractual obligations In some instances, GitLab may be required to maintain certain types of records or other types of information for designated periods of time pursuant to its contractual obligations with third parties. To the extent agreed to by GitLab, those contractual obligations must be honored. If there is a conflict between the Record Retention Schedule and a contract, the longer of the two terms shall prevail unless otherwise prevented by law.

9. Communications GitLab Legal is responsible for implementing and managing the Records Retention Policy.

Maintain Accurate Financial Records / Internal Accounting Controls

Accurate and reliable records are crucial to our business. Records will be maintained accurately to:

GitLab records include:

There is never a reason to make false or misleading entries. Undisclosed or unrecorded funds, payments, or receipts are inconsistent with our business practices and are prohibited.

Manage Records Properly

Our records are our corporate memory, providing evidence of actions and decisions and containing data and information critical to the continuity of our business.

Records consist of all forms of information created or received by GitLab, whether originals or copies, regardless of media. Examples of company records include:

We are responsible for properly labeling and carefully handling confidential, sensitive, and proprietary information and securing it when not in use. We do not destroy official company documents or records before the retention time expires, but do destroy documents when they no longer have useful business purpose.

Avoiding Conflicts of Interest

We have an obligation to make sound business decisions in the best interests of GitLab without the influence of personal interests or gain. Our company requires you to avoid any conflict, or even the appearance of a conflict, between your personal interests and the interests of our company.

A conflict exists when your interests, duties, obligations or activities, or those of a family member are, or appear to be, in conflict or incompatible with the interests of GitLab. Conflicts of interest expose our personal judgment and that of our company to increased scrutiny and criticism and can undermine our credibility and the trust that others place in us.

Should any business or personal conflict of interest arise, or even appear to arise, you should disclose it immediately to leadership for review. In some instances, disclosure may not be sufficient and we may require that the conduct be stopped or that actions taken be reversed where possible. As it is impossible to describe every potential conflict, we rely on you to exercise sound judgment, to seek advice when appropriate, and to adhere to the highest standards of integrity.

GitLab is often required to disclose any organizational or personal conflict of interest to various third parties. To ensure accuracy in our disclosures, please notify Compliance at Compliance@gitlab.com of any organizational or personal conflicts of interest.

Communicating with External Parties

GitLab employees and contractors are not authorized to speak with the media, investors, or analysts on behalf of our company unless authorized by our Marketing department. Unless authorized, do not give the impression that you are speaking on behalf of GitLab in any communication that may become public. This includes posts to online forums, social media sites, blogs, chat rooms, and bulletin boards. This policy also applies to comments to journalists about specific matters that relate to our businesses, as well as letters to the editor and endorsements of products or services.

Personal Hygiene

When attending Contribute or any conference, public meeting, customer meeting or meet-up, kindly keep in mind you are representing GitLab. Personal hygiene and hygiene in general helps to maintain health and prevent the spread of diseases and various other illnesses. We motivate everyone to maintain cleanliness. For more information about our Contribute Code of Conduct, read more here.

Social Responsibility

We pride ourselves on being a company that operates with integrity, makes good choices, and does the right thing in every aspect of our business. We will continually challenge ourselves to define what being a responsible company means to us, and work to translate our definition into behavior and improvements at GitLab. We seek to align our social and environmental efforts with our business goals and continue to develop both qualitative and quantitative metrics to assess our progress.

Political Activities and Contributions

You may support the political process through personal contributions or by volunteering your personal time to the candidates or organizations of your choice. These activities, however, must not be conducted on company time or involve the use of any company resources. You may not make or commit to political contributions on behalf of GitLab.

Charitable Contributions

We support community development throughout the world. GitLab employees or contractors may contribute to these efforts, or may choose to contribute to organizations of their own choice. However, as with political activities, you may not use company resources to personally support charitable or other non-profit institutions not specifically sanctioned or supported by our company. You should consult the Legal department if you have questions about permissible use of company resources.

Human Rights

We are committed to upholding fundamental human rights and believe that all human beings around the world should be treated with dignity, fairness, and respect. Our company will only engage suppliers and direct contractors who demonstrate a serious commitment to the health and safety of their workers, and operate in compliance with human rights laws. GitLab does not use or condone the use of slave labor or human trafficking, denounces any degrading treatment of individuals or unsafe working condition, and supports our products being free of conflict minerals.

Anti-Slavery and Anti-Human Trafficking Policy

  1. Slavery and Human Trafficking are crimes and violations of fundamental human rights. These violations take various forms, such as slavery, servitude, forced and compulsory labour, and/or human trafficking, all of which have in common the deprivation of a person’s liberty by another in order to exploit them for personal or commercial gain. GitLab is committed to acting ethically and with integrity in our business dealings and relationships by implementing and enforcing systems/controls to ensure modern slavery or human trafficking are not taking place in our business, or with those with whom we do business.

  2. GitLab is also committed to ensuring there is transparency in our business and in our approach to tackling slavery and human trafficking throughout our supply chains and overall organization, consistent with disclosure obligations we may have under applicable law. To that end, we prohibit the use of forced, compulsory or trafficked labor, or anyone held in slavery or servitude, whether adults or children by anyone working for or with GitLab.

  3. All employees, directors, officers, agents, interns, vendors, distributors, resellers, contractors, external consultants, third-party representatives and business partners are expected to comply with this policy.

  4. Every Team Member is responsible to assist in the prevention, detection and reporting of slavery and human trafficking by those working for or with GitLab. Each Team Member is encouraged to raise concerns about any known or suspected incidents of slavery or human trafficking in any parts of our business or supply chains at the earliest possible stage. If you are unsure about whether a particular act, the treatment of workers more generally, or their working conditions within any tier of our supply chains or business partners constitutes any of the various forms of modern slavery/human trafficking, raise it at Compliance@Gitlab.com.

  5. We may terminate our relationship with individuals and/or Business Partners if they breach this policy.

Code of Business Conduct & Ethics Acknowledgment Form

Team members will review and sign the Code of Business Conduct & Ethics Acknowledgment Form during onboarding as well as annually during the Global Compensation Annual Review cycle. During the annual merit cycle, people operations will be responsible for sending all team members the updated Code of Business Conduct & Ethics acknowledgment form and ensuring all team members review and acknowledge. The Code of Conduct will be sent to each team member via BambooHR. To review and sign the document: log into BambooHR download the PDF and click on the Code of Conduct Link. Once a team member has reviewed the Code of Conduct they will use the BambooHR signature and date tool to complete the acknowledgement. No changes should be made to the Code of Business Conduct & Ethics without prior approval from the VP of Legal.

GitLab People Policy Directory

All of the policies listed below are important for GitLab team-members to read and understand as they deal with people benefits, procedures, and requirements of the company. If you have any questions around the internal policies, please reach out to People Operations.

Sick Time - Taking and Reporting

In keeping with our values of freedom, efficiency, transparency, kindness, and boring solutions, we have crafted the following protocol around sick leave for all GitLab team-members.

All GitLab team-members

If you or a loved one is ill, we want you to take care of yourself or your loved one(s). To facilitate this, you should take sick leave when you need it. Sick leave is meant to be used when you are ill, or to care for family members including your parent(s), child(ren), spouse, registered domestic partner, grandparent(s), grandchild(ren), or sibling(s).

You still need to report when you take sick leave, by entering the dates as an event in PTO Ninja via Slack. Once entered in PTO Ninja it will automatically update in BambooHR and payroll can update any other systems.

If you need sick leave for more than 8 consecutive calendar days, notify your manager and the People Analyst team to accommodate an extended leave request. What can (or must) be accommodated varies from location to location: GitLab will comply with the applicable laws in your specific location.

Upon request, you should be able to provide proper documentation of the reason for your sick leave (doctor's note).

Details for specific groups of GitLab team-members

Employees of GitLab Inc. can take off sick time in line with our paid time off policy. Sick time does not get paid out in case of termination, nor does it reduce your final paycheck in case of a negative balance. Related to the topic of extended leave requests, see information about short term disability through Cigna / your state.

Employees of GitLab B.V. have further rights and responsibilities regarding sick time based on Dutch law, as written into their employment contracts:

Worker's Compensation

If you have been injured at work, please contact People Operations Analysts to determine what your benefits are.

Military Leave

GitLab is committed to protecting the rights of team members absent on military leave. No team member or prospective team member will be subjected to any form of discrimination on the basis of membership in or obligation to perform service for any of the uniformed services of their country of residency. If any team member believes that he or she has been subjected to discrimination in violation of this policy, immediately contact People Business Partners for assistance. For any questions about how to initiate a military leave, please contact People Operations.

Hiring Significant Others or Family Members

GitLab is committed to a policy of employment and advancement based on qualifications and merit and does not discriminate in favor of or in opposition to the employment of significant others or relatives. Due to the potential for perceived or actual conflicts, such as favoritism or personal conflicts from outside the work environment, which can be carried into the daily working relationship, GitLab will hire or consider other employment actions concerning significant others and/or relatives of persons currently employed or contracted only if all points below are true:

This policy applies to all current employees and candidates for employment.

Relocation

If your permanent address is changing, notify the People Ops Analyst at compensation@ domain of the new address before the pay cycle of the move. The best way to do this is by logging in to BambooHR and changing your address under the Personal tab which triggers a message to the BambooHR admin to review the change and "accept" it. If you do not have your new address you can also email People Operations to trigger a review.

If you are going to spend six months or more in one location this will be considered as a relocation and your compensation will be evaluated based on the new geo area.

If there are any questions or concerns, please reach out to the Chief People Officer.

Short-term relocation

If you are not changing your permanent location (where you pay taxes and maintain residency), but instead are traveling to different locations over a period of time, you are responsible for maintaining your health insurance, visas, and any other item directly relating to your travel. Since GitLab does not require you to travel to these locations as part of your position, you will not be eligible to utilize the Business Accident Travel Policy or expense any items related to your travel. If you are hired in a role requiring a timezone alignment, you must still be able to fulfill that requirement.

Tuition Reimbursement

GitLab supports team members who wish to continue their education and growth within their professional career. If you are a full-time GitLab team member and have been employed for more than three months, you are eligible to participate in this program. To be eligible for reimbursement, courses must be a requirement of a degree or certification program and delivered through a credentialed college or university or effective online education such as Udacity.

GitLab team-members are eligible for a reimbursement of up to 20,000 USD per calendar year (January 1st - December 31st) depending on tenure, performance, and company need for the learned skill. A course is considered to be included in the calendar year in which the course is paid/reimbursed (which should also be the same calendar year in which the course ends). Approval must be obtained in advance from the e-group member in charge of your organization and in accordance with the signature authorization policy. There is no limit to the number of years a team member can participate in the program. Courses eligible for reimbursement include classes for credit resulting in a grade (not pass/fail), courses providing continuing education credits, and/or courses taken as part of a certification program. You must earn a passing grade equivalent to a “B” or obtain a successful completion certification to submit for reimbursement.

The program will cover only the tuition and enrollment related fees. Additional fees related to parking, books, supplies, technology, or administrative charges are not covered as part of the program. Tuition will be validated by receipt showing proof of payment. A description of the course(s) and degree or certification program along with a final grade report or satisfactory certificate of completion are required to receive reimbursement.

If you voluntarily terminate employment with GitLab after completion of the course and prior to completing twelve consecutive months of active employment after completion of the course, you will refund the entire amount of the educational expenses provided to you.

Examples of requests that may be approved:

Examples of requests that may be denied:

Tuition Reimbursement Process

To receive tuition reimbursement, GitLab team members should follow the following process:

  1. GitLab team member first discusses their interest in professional development with their manager.
  2. If the manager agrees that the degree or certification program is aligned with the business and growth opportunities within GitLab, a minimum of three weeks prior to the course start date, the GitLab team member fills out a Tuition Reimbursement Agreement and forwards it to the People Analyst team at compensation@ domain to stage for the proper signatures (GitLab team member, Manager, People Operations) in HelloSign.
  3. The People Ops Analyst will confirm there are no additional tax implications for reimbursement in the team member's country.
  4. The People Ops Analyst will file the application and signed agreement in BambooHR.
  5. The People Ops Analyst will also log the tuition reimbursement in the "Tuition Reimbursement Log" found on the Google Drive.
  6. Once the course is completed, an official grade report or successful certification of completion must be submitted to People Operations.
  7. After grades are verified, People Operations will ensure the reimbursement is processed through the applicable payroll by the second pay cycle after submission.
    • If the program does not allow for tuition deferment and this would cause financial strain on the team member, they can email the People Ops Analyst at compensation@ domain to receive 50% of the reimbursement up front and the other 50% upon successful completion of the course.

Tax Implications for Tuition Reimbursement by Country

In some countries, tuition reimbursement may be considered as taxable income and can be (partially) exempted from personal income taxes or subject to employer withholding taxes. Please contact Payroll or People Ops when you have questions.

Mental Health Awareness

The World Health Organisation (WHO) defines health as:

The WHO defines mental health as:

Defining the terms from the sentence above:

  1. Why is awareness of Mental Health important at GitLab?

    • It can affect any and all of us. The statistics from the WHO are that 1 in 4 of us will be affected by mental or neurological disorders at some point in our life. That said, we are all subject to periods where we or those around us find the "the normal stresses of life" harder than usual to deal with.
    • The more we are aware of mental health, the more inclusive we are. That will help encourage any colleagues currently experiencing mental health issues to talk about it.
    • Our business at its core is a group of people working together towards a common goal. With awareness of what might affect our colleagues, we are better equipped to help them if they do discuss it with us and therefore help our business.
    • Mental health has so much emotional baggage as a topic that it can initially seem scary to talk about. Promoting mental health awareness helps to remove the stigma and taboos associated with it.
    • GitLab can offer "productive and fruitful" work for all of our employees. That should not be underestimated.
    • In the cold-light of business metrics, the healthier we are, the more productive we are.
  2. At GitLab we strive to create a stigma-free workplace. In accordance with the National Mental Health Association and the National Council for Behavioral Health we would like to:

    • Educate employees about the signs and symptoms of mental health disorders.
    • Encourage employees to talk about stress, workload, family commitments, and other issues.
    • Communicate that mental illnesses are real, common, and treatable.
    • Discourage stigmatizing language, including hurtful labels such as “crazy,” “loony” or “nuts.”
    • Help employees transition back to work after they take leave.
    • Encourage consultation with our employee assistance programs.
  3. What are we doing to get there?

    • People Operations Learning and Development team will be developing training for managers on this topic.
    • Talk about mental health issues and ideas in the #mental_health_aware Slack channel.
    • GitLab would also like to encourage GitLab team-members to take their time off to properly take care of themselves. We encourage the team to go to yoga, take a long lunch, or anything else in their day to day life that assists in their mental and emotional well-being.
    • In addition to our current EAP programs available for employees, we encourage GitLab team-members to take a look at Working Through It for insight into reclaiming well-being at work, off work, and return to work.
    • We believe that our values and culture lends itself to being able to discuss mental health open and honestly without being stigmatized, but let's work together to make it even more inclusive. For example, Finding the right words:
      • "How can we help you do your job?"
      • "You’re not your usual self."
      • "Do you want to talk about it?"
      • "It's always OK to ask for help."
      • "It’s hard for me to understand exactly what you’re going through, but I can see that it’s distressing for you."

Any questions or concerns? Please feel free to speak with anyone in People Ops.

Background Checks

GitLab is concerned about the safety of its employees and about maintaining appropriate controls to ensure that assets of GitLab and our customer relationships and information are protected. To reduce these risks, GitLab will obtain and review background information of covered prospective, and, as applicable, current employees.

All candidates who make it to the reference check stage with GitLab must undergo a background screening according to this policy as part of the employment screening process. All contracts will state that employment is subject to obtaining results from an approved background screening that are satisfactory to GitLab.

In the event the background check is not available at the time of hire (switching vendors or delays in processing), GitLab will run the background check as soon as possible. The same adjudication guidelines will apply to current employees as they do with prospective employees. The results will be reviewed by Candidate Experience Specialists and Legal to determine if the results warrant any adverse action, which could include termination of employment.

We have contracted with Sterling Talent Solutions to perform these background checks, which will cover criminal history for the last 7 years and employment history for the last 5 years and/or the three most recent employers. GitLab may use the returned background check information to make decisions regarding employment. Therefore, the employment of team members is contingent upon a successful completion of the background check, per language in the contract. For certain positions where the candidates financial history is relevant to the position, we may also run a check in the federal database for any financial related offenses.

Disclosure and Authorization

Candidates/employees will receive an email to fill out the background check application following the completion of their contract. The application process includes signing a disclosure and a consent form which explains the rights of an individual undergoing a background examination. The application process is designed to take less than fifteen minutes to complete. Candidate Experience Specialists will initiate all background screenings.

To prepare for the employment verification, candidates should gather each previous employer's name and address, position title held, employment start and end dates, manager’s name and title, their phone number, and email address. Details for a Human Resources contact can be entered instead of a manager's contact details.

Occasionally, Sterling will reach out to the candidate to retrieve additional information, such as backup documentation to act as proof of previous employment or picture IDs. Proof of employment can typically be provided in various ways, such as tax returns (e.g. W2s), pay stubs, LLC documentation, official company registrations, etc.

Background checks will act as an additional mechanism of transparency and will help to build trust with our clients.

Review Criteria

Once the background check is completed, Candidate Experience Specialists will review the report and determine if any negative information has a direct connection with an applicant’s ability to fulfill the employee’s duties with competence and integrity. Matters that might raise a concern include but are not limited to: criminal history, recent felony convictions, theft, violent crimes, drug related crimes, and sex offenses. In addition, the report should be carefully reviewed for any omissions or inaccuracies contained in the employment application or made during the interview process.

Step 1: Disclosure and Authorization

The applicant must give the employer consent to have a third party service conduct a background check. The Disclosure and Authorization form can be presented to the applicant at the time he/she completes the employment application form. The form should grant the employer permission to conduct an initial background check (and, subject to state law, subsequent background checks if the applicant is hired) utilizing a third party service. Also, a “Summary Of Your Rights Under The Fair Credit Reporting Act” should be enclosed with the consent and disclosure form. For New York applicants, a copy of Article 23-A of the Correctional Law also should be enclosed and any other relevant state summary of rights.

The background investigation cannot be lawfully conducted without a signed Disclosure and Authorization form. Applicants can be advised that they will not be considered for employment without submitting the signed form. Equally for current team members, they can be advised that their employment may be impacted if they do not consent to the background check.

Step 2: Pre-Adverse Action: Notify the Applicant of Negative Report BEFORE Adverse Action is taken

If the consumer reporting agency reports information which may be used, in whole or in part, as a basis for an adverse employment action (e.g., rescinding a conditional offer of employment), the applicant must receive notification before a final decision is made to deny employment. As a result, the employer must provide a copy of the consumer report, a pre-adverse action letter, and another copy of the FCRA notice of rights (and for New York applicants, the Article 23-A notice). The applicant shall also receive any applicable state rights as required.

If the disqualification decision is not based on a misrepresentation or omission in the employment application, it is a best practice to discuss the potentially disqualifying information with the individual prior to issuing the pre-adverse action notice. This practice supports the individual job-related nature of any disqualification decision.

Step 3: Wait for a Reasonable Period of Time to Find Out What, if Any, Explanation is Offered by the Applicant

If the applicant does not respond at all to the notification within a reasonable period of time (5 days), the employer may proceed with its decision to rescind the conditional offer. If the applicant responds, the employer should carefully consider the information submitted and then make a decision. If the explanation is reasonable under the circumstances, then it may still be possible to go forward with the new hire (for example, a case of mistaken identity). However, if the applicant's explanation is determined to be insufficient, then the employer should proceed to the next step.

Step 4: Notify Applicant of Adverse Action

The employer must provide the applicant with written notice of the adverse action and the name, address, and telephone number of the consumer reporting agency. The Adverse Action Notice form should be sent along with the federal summary of rights and any applicable state summary of rights. The notice includes a statutorily required statement that the consumer reporting agency did not make the decision and does not know why the decision was made should be included as well as a notice of the applicant's right to obtain the report and dispute the information.

Step 5: Maintain Documentation

For all adverse decisions, document each step taken. Keep copies of all consent and disclosure forms and other documentation sent to the applicant in the event the company has to defend its decision at some later point.

Record Retention

All documents related to the background check process must be retained for at least five years.

Equal Employment Laws

GitLab will adhere to all equal employment laws. When reviewing any criminal record information that appears on a background check, the company shall factor in any known factors relating to:

  1. The facts and circumstances surrounding the offense.
  2. The number of offenses for which the individual was convicted.
  3. The age of the individual at the time of conviction or release from prison.
  4. Evidence that the individual has performed the same type of work, post-conviction, with the same or a different employer, without incidents of criminal conduct.
  5. The length and consistency of employment history before and after the offense.
  6. Any efforts of the applicant towards rehabilitation.
  7. Employment or character references obtained regarding the individual’s fitness for the particular position.
  8. Whether the individual will be bonded for the position.

Financial Checks

Finance team members only will be required to participate in a federal check through Sterling, which searches for any tax-related or financial offenses.

Initiating a Background Check through Greenhouse

US Candidates Only

  1. Log in to Greenhouse and go to the candidate's profile.
  2. Click the "Private" tab.
  3. Click "Export to TalentWise".
  4. Click "Complete Report", which will redirect you to the Sterling website.
  5. Scroll down and click "Add Screening".
  6. Next to "Comprehensive Criminal", click on "Ticket". If you need to run a financial check as well for Finance team members, after you click "Ticket", click "Add Products" on the right and search for and include "Federal Criminal District Search".
  7. Check off that you agree to your obligations as a user.
  8. Under "Disclosure and Authorization Options", select the first option to have Sterling send the candidate a disclosure form.
  9. Click "Generate Ticket".

Initiating a Background Check through Sterling Talent Solutions

US Candidates Only

  1. Log in to Sterling and select "Quick Launch".
  2. Click "Launch Screening".
  3. Next to "Comprehensive Criminal" click on "Ticket". If you need to run a credit check as well, after you click "Ticket" click "Add Products" on the right and search for "Federal Criminal Check".
  4. Check off that you agree to your obligations as a user.
  5. Enter the candidate's name and personal email address.
  6. Select the first option to have Sterling send the candidate a disclosure form, and click "Generate Ticket".

Non-US Candidates Only

  1. Log in to Sterling and E-invite the candidate by inputting their email address.
  2. Under "Applicant Information" enter in the candidate's first and last name, as well as their email address to confirm.
  3. Next, select "A La Carte" from the "Screening Packing".
  4. Then, you will select "Verification- Employment (International)" from the "A La Carte" drop down. Then click "Add".
  5. After that, you will select "Criminal-International". A drop down menu will appear, and you will select the country the candidate is located in. Then click "Add"
  6. Make sure both checks are included in the "Search" box.
  7. Finally, scroll to the bottom of the page and click "Send"

Job Abandonment

When a team member is absent from work for three consecutive workdays, there is no entry on the availability calendar for time off, and fails to contact his or her supervisor, they can be terminated for job abandonment unless otherwise required by law.

If a manager is unable to reach an employee via email or slack within a 24 hour period they should contact their HR Business Partner. The HR Business partner will access the employee's information to obtain additional contact methods and numbers. The manager and HR Business Partner will create an action plan to make all attempts to contact the employee.

Other People Policies