---
layout: handbook-page-toc
title: "Code of Business Conduct & Ethics and GitLab People Policy Directory"
---

## On this page
{:.no_toc .hidden-md .hidden-lg}

- TOC
{:toc .hidden-md .hidden-lg}

## Code of Business Conduct & Ethics

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

  * Honest and ethical conduct, including the ethical handling of actual or apparent conflicts of interest between personal and professional relationships.
  * Full, fair, accurate, timely, and understandable disclosure in reports and documents we file with regulatory agencies and in our other public communications.
  * Compliance with applicable laws, rules, and regulations.
  * The prompt internal reporting of violations of this Code.
  * Accountability for adherence to this Code.

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](/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:

* Discuss the issue with your supervisor or manager.
* Discuss the issue with another supervisor or manager.
* Contact the [People Group](https://about.gitlab.com/handbook/people-group/)
* Contact [GitLab’s 24-hour hotline](#how-to-contact-gitlabs-24-hour-hotline).

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

#### Investigation Process

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

* the complaint is against a member of the People Business Partner team, in which case the investigation will be conducted by Legal (internal Chief Legal Officer or outside counsel, as appropriate).
* if the case requires the People Business Partner to investigate in their own Client group, the CPO and the People Business Partner will determine if a People Business Partner not supporting the group should lead the investigation.
* the complaint is made against a member of the executive team or there are multiple complainants regarding the same individual and/or issue, then outside counsel will be retained by the CPO to conduct the investigation. 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.

If the complaint involves a member of the executive team that has direct oversight for the Legal department or involves a member of the Legal department, then the CPO will work with outside counsel to conduct the investigation. If the complaint involves a member of the executive team that has direct oversight for the People Group or involves a member of the People Group, then Legal will work with outside counsel to conduct the investigation.

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 CPO. Based on the investigation findings, the CPO 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:

* **Violation Found**: Where a violation of GitLab policies, workplace rules or law is found to have occurred, the CPO will review the findings and make a recommendation for corrective action to the executive leader of the accused's reporting line. Together, the CPO and the business unit will determine the proper corrective action. If the accused is a member of the executive team then the CPO will confer with the CEO, and where necessary, the Board of Directors. Once a corrective action has been determined, the accused will be notified of the finding and of the specific corrective actions to be taken. The accused employee's manager will also be notified if appropriate. No details about the nature or extent of disciplinary or corrective actions will be disclosed to the complainant(s) or witness(es) unless there is a compelling reason to do so (for example, personal safety).
* **No Violation Found**: In this situation, the complainant (if known) and the accused should be notified that GitLab investigated the allegation(s) and found that the evidence did not support the claim.
* **Inconclusive investigation**: In some cases, the evidence may not conclusively indicate whether the allegation(s) were founded or unfounded. If such a situation occurs, the complainant (if known) and the accused will be notified that a thorough investigation was conducted, but GitLab was unable to establish the truth or falsity of the allegation(s). GitLab will take appropriate steps to ensure that the persons involved understand the requirements of GitLab's policies and applicable law, and that GitLab will monitor the situation to ensure compliance in the future.

#### 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](#commitment-to-non-retaliation).

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](/handbook/anti-harassment/#sts=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.

* Website: [https://www.lighthouse-services.com/gitlab](https://www.lighthouse-services.com/gitlab)
* USA Telephone:
  * English speaking USA and Canada: 833-480-0010
  * Spanish speaking USA and Canada: 800-216-1288
  * French speaking Canada: 855-725-0002
  * Spanish speaking Mexico: 01-800-681-5340
* All other countries telephone: +1-800-603-2869
* E-mail: reports@lighthouse-services.com (must include company name with report)
* Fax: (215) 689-3885 (must include company name with report)

The reports sent to Lighthouse Services are shared with the [Chief Legal Officer](/job-families/legal/chief-legal-officer/) and [the Chair of the Audit Committee](/handbook/board-meetings/#audit-committee-charter).

### 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.

### Open Door Policy
We encourage maximum communication between team members at all levels of the organization.  This is an important part of our culture.  Whenever problems or concerns arise, it is expected that they will be addressed as quickly as possible.  Your immediate manager is the person on the management team who is closest to you and your work.  When you need help or have questions, complaints, problems or suggestions, please contact your manager first.  It is your manager's responsibility to assist you - so please ask, and be willing to work the issue out with your manager.  They are interested in your success, the success of every team member in their department, and the overall success of GitLab.

If your manager cannot help you or answer your questions, your questions will be referred to someone who can.  If you feel your particular question, concern or suggestion cannot be discussed with your manager, you are encouraged to contact your manager's manager, your assigned People Business Partner, the Chief People Officer or the CEO.  It is important to remember that a team member who takes these steps will not be reproached.  You can expect to be treated fairly and with respect.

### 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.

* We do not tolerate discrimination against anyone, including team members, customers, business partners, or other stakeholders, on the basis of race, color, religion, national origin, sex (including pregnancy), age, disability, HIV status, sexual orientation, gender identity, marital status, past or present military service, or any other status protected by the laws or regulations in the locations where we operate.
* We comply with laws regarding employment of immigrants and non-citizens and provide equal employment opportunity to everyone who is legally authorized to work in the applicable country.
* We provide reasonable accommodations to individuals with disabilities and remove any artificial barriers to success.

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](/handbook/anti-harassment/) 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](/handbook/anti-harassment/) 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](/handbook/finance/#timesheets-for-hourly-employees) accurately. For more information on compensation, please refer to our [Compensation Principles](/handbook/people-group/global-compensation/#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 Contribute](/company/culture/contribute/).

### 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](/handbook/people-group/#sts=Using 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](/company/team/) 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 or CPO.

### 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 Data Protection Officer (“DPO”) by emailing [security@gitlab.com](mailto:security@gitlab.com) or your Privacy Officer by emailing [compliance@gitlab.com](mailto:compliance@gitlab.com).

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 Corp, 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., [about.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](https://docs.google.com/spreadsheets/d/1mTNZHsK3TWzQdeFqkITKA0pHADjuurv37XMuHv12hDU/edit#gid=0) 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:
 - An individual’s name.
 - Employee ID number.
 - Home address.
 - Home phone number.
 - Personal email address.
 - Names of family members.
 - Date of birth.

*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:
- Race and ethnic information.
- Sexual orientation.
- Political/religious beliefs.
- Social security or other taxpayer/government issued identification numbers.
- Financial information.
- Health or medical information, including genetic information.
- Criminal records.
- And in some regions, such as the European Union, trade union membership.

*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:
- Name
- Gender
- Home address
- Telephone number
- Date of birth
- Marital status
- Employee identification number
- Emergency contacts
- Residency
- Work permit status
- Military status
- Nationality
- passport information
- Social security or other taxpayer/government identification number
- Payroll information, banking details
- Wage and benefit information
- Retirement account information
- Sick pay, Paid Time Off, retirement accounts, pensions, insurance and other benefits information (including the gender, age, nationality and passport information for any spouse, minor children or other eligible dependents and beneficiaries).
- Information from interviews and phone-screenings you may have had, if any.
- Date of hire, date(s) of promotions(s), work history, technical skills, educational background, professional certifications and registrations, language capabilities, and training records.
- Beneficiary and emergency contact information.
- Forms and information relating to the application for, or in respect of changes to, employee health and welfare benefits; including, short and long-term disability, medical and dental care, etc.
- Physical limitations and special needs in order to provide accommodations.

- Records of work absences, vacation/paid time off, entitlement and requests, salary history and expectations, performance appraisals, letters of appreciation and commendation, and disciplinary and grievance procedures (including monitoring compliance with and enforcing our policies).

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.

- Information required for us to comply with laws, the requests and directions of law enforcement authorities or court orders (e.g., child support and debt payment information).

- Acknowledgements regarding our policies, including employee handbooks, ethics and/or conflicts of interest policies and computer and other corporate resource usage policies.

- Information captured on security systems and key card entry systems.

- Voicemails, e-mails, correspondence, documents, and other work product and communications created, stored or transmitted using our networks, applications, devices, computers or communications equipment.

 - Date of resignation or termination, reason for resignation or termination, information relating to administering termination of employment (e.g. references).

 - Letters of offer and acceptance of employment.

 - Your resume or CV, cover letter, previous and/or relevant work experience or other experience, education, transcripts, or other information you provide to us in support of an application and/or the application and recruitment process.

 - References and interview notes.

 - Information relating to any previous applications you may have made to GitLab and/or any previous employment history with GitLab.

For specifics about what information is collected by third party applications, please refer to the [Tech Stack Applications](https://docs.google.com/spreadsheets/d/1mTNZHsK3TWzQdeFqkITKA0pHADjuurv37XMuHv12hDU/edit#gid=0).

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:

 - Recruitment, training, development, promotion, career and succession planning

 - Appropriate vetting for recruitment and team allocation including, where relevant and appropriate credit checks, right to work verification, identity fraud checks, relevant employment history, relevant regulatory status and professional qualifications

 - Providing and administering remuneration, salary, benefits and incentive schemes and providing relevant information to payroll

 - Allocating and managing duties and responsibilities and the business activities to which they relate

 - Identifying and communicating effectively with other employees and management

 - Managing and operating conduct, performance, capability, absence and grievance related reviews, allegations, complaints, investigations and processes and other informal and formal HR processes and making related management decisions

 - Consultations or negotiations with representatives of the workforce

 - Conducting surveys for benchmarking and identifying improved ways of working employee relations and engagement at work (these will often be anonymous but may include profiling data such as age to support analysis of results)

 - Processing information about absence or medical information regarding physical or mental health or condition in order to assess eligibility for incapacity or permanent disability related remuneration or benefits, determine fitness for work, facilitate a return to work, make adjustments or accommodations to duties or the workplace and make management decisions regarding employment or engagement or continued employment or engagement or redeployment and conduct related management processes

 - For planning, managing and carrying out restructuring or redundancies or other change programs including appropriate consultation, selection, alternative employment searches and related management decisions

 - Operating email, IT, Internet, intranet, social media, HR related and other company policies and procedures. The company carries out monitoring of GitLab's IT systems to protect and maintain the systems, to ensure compliance with GitLab policies and to locate information through searches where needed for a legitimate business purpose

 - Complying with applicable laws and regulation (for example maternity or parental leave legislation, working time and health and safety legislation, taxation rules, worker consultation requirements, other employment laws and regulation to which GitLab is subject in the conduct of its business)

 - Monitoring programs to ensure equality of opportunity and diversity with regard to personal characteristics protected under local anti-discrimination laws

 - Planning, due diligence and implementation in relation to a commercial transaction or service transfer involving GitLab that impacts on your relationship with GitLab (for example mergers and acquisitions or a transfer of your employment under automatic transfer rules)

 - For business operational and reporting documentation such as the preparation of annual reports or tenders for work or client team records including the use of your personal photo

 - In order to operate the relationship with Third-Party customer and suppliers including the disclosure of relevant vetting information in line with the appropriate requirements of regulated customers to those customers, contact or professional CV details or resume, or your personal photo for identification to clients or disclosure of information to data processors for the provision of services to GitLab

 - Where relevant for publishing appropriate internal or external communications or publicity material including via social media in appropriate circumstances, provided that privacy rights are preserved

 - To support HR administration and management and maintaining and processing general records necessary to manage the employment or worker relationship and operate the contract of employment or engagement

 - To centralize HR administration and management processing operations in an efficient manner for the benefit of our employees and to change access permissions

 - To provide support and maintenance for the System

 - To enforce our legal rights and obligations, and for any purposes in connection with any legal claims made by, against or otherwise involving you

 - To comply with lawful requests by public authorities (including without limitation to meet national security or law enforcement requirements), discovery requests, or where otherwise required or permitted by applicable laws, court orders, government regulations, or regulatory authorities (including without limitation data protection, tax and employment), whether within or outside your country

 - Other purposes permitted by applicable privacy and data protection legislation including where applicable, legitimate interests pursued by GitLab where this is not overridden by the interests or fundamental rights and freedoms of employees.

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:

 - Where you request us or provide your consent to us.

 - In order to carry out the uses of personal information described above (see, How We Process and Use Your Personal Information).
When using or collaborating with third parties in the operation of our business, including in connection with providing many of the benefits and services we offer our employees (e.g., human resources information systems, financial investment service providers, insurance providers). When we share personal information with third parties we typically require that they only use or disclose such personal information in a manner consistent with the use and disclosure provisions of this Privacy Policy and applicable law.

 - We may buy or sell businesses and other assets. In such transactions, employee information is generally one of the transferred business assets and we reserve the right to include your personal information as an asset in any such transfer. Also, in the event that we, or substantially all of our assets, are acquired, your personal information may be one of the transferred assets.

 - Where required by law, by order or requirement of a court, administrative agency, or government tribunal, which includes in response to a lawful request by public authorities, including to meet national security or law enforcement requirements or in response to legal process.

 - If we determine it is necessary or desirable to comply with the law or to protect or defend our rights or property.

 - As necessary to protect the rights, privacy, safety, or property of an identifiable person or group or to detect, prevent or otherwise address fraud, security or technical issues, or to protect against harm to the rights, property or safety of GitLab, our users, applicants, candidates, employees or the public or as otherwise required by law.

 - Where the personal information is public and exempted from coverage under applicable data protection laws.

 - To seek advice from our lawyers and other professional advisors.

 - To professional advisors (e.g. bankers, lawyers, accountants) and potential buyers and vendors in connection with the sale, disposal or acquisition by use of a business or assets.

*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](/handbook/people-group/code-of-conduct/#how-to-contact-gitlabs-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:

 - You contest the accuracy of the personal information until we have taken sufficient steps to correct or verify its accuracy;
 - Where the processing is unlawful, but you do not want us to erase the information;
 - Where we no longer need the personal information for the purposes of the processing, but you require them for the establishment, exercise or defense of legal claims; or
 - Where you have objected to processing justified on legitimate interest grounds (see below) pending verification as to whether GitLab has compelling legitimate grounds to continue processing.

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 defense 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:
* Any non-public information concerning GitLab, including its businesses, team members, financial performance, results or prospects
* Any non-public information of a third party in GitLab's possession and under GitLab's protection
  - With the expectation that the information will be kept confidential and used solely for the business purpose for which it was conveyed and accessed solely by those who have a need to access the information in fulfilling that purpose

GitLab’s confidentiality provisions can be found in the [employee and contractor templates](/handbook/contracts/#employee-contractor-agreements), 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.

### Material Nonpublic Information / Inside Information

Employees know that they have to protect Confidential Information.  But did you know that employees also cannot **use** Confidential Information?  Employees are not permitted to use or share Confidential Information for purposes of trading securities, illegal activities or for any other purpose except to conduct [GitLab](https://about.gitlab.com/handbook/people-group/acceptable-use-policy/) business. Insider trading (or dealing) laws and regulations globally prohibit buying or selling a company’s securities while in possession of Confidential Information about that company that is Nonpublic and Material.

Employees can also violate these laws by disclosing Material Nonpublic Confidential Information to another person if, as a result, that person – or any other person – buys or sells a security while aware of that information. If you make such a disclosure or use such information, there can be stiff penalties, even if you yourself stand to make no financial gain.

Clarity on whether information is “Nonpublic” or “Material” or what restrictions exist on the use or distribution of such information is provided below.  Further questions should be directed to the Legal or Compliance Department.

**Definitions**
**Nonpublic Information** is Confidential Information that is maintained or otherwise handled by GitLab that may be harmful to GitLab, it’s employees or others with whom GitLab does business as defined in the Data Classification policy, including, but not limited to, any of the following:
Information used for, or obtained from, a rated entity or its agent for the purpose of determining a rating or pending rating;
Major personnel changes;
Lawsuits that may trigger heavy damages;
Mergers, acquisitions;
Substantial contracts not in the ordinary course of business;
Information concerning the rating committee process, including, but not limited to, the voting breakdown in the committee, the fact that a member of the rating committee disagreed with the ultimate committee decision, and the names or titles of members of the committee;
Nonpublic Information relating to GitLab’s customers and information provided by GitLab’s customers, including internal risk assessment models, information concerning the performance of those models, historical default data for loan portfolios, customer-specific loan pricing information and information concerning portfolio composition and concentration;
GitLab’s nonpublic financial information and sales projections; or
Information regarding GitLab’s business plans, strategies, proprietary systems, algorithms, formulas, methodologies, product designs, processes, research and development information and trade secrets; or Special Personal Information.

**Material Information** has no precise definition and is subject to a variety of interpretations. Accordingly, for the purposes of this Policy, “Material Information” refers to any information that: (i) might have an effect on the market for a security generally; or (ii) might affect an investment decision of a reasonable investor.

Examples of Material Information may include, but are not limited to:
sales results
earnings or estimates (including reaffirmations or changes to previously released earnings information)
dividend actions
strategic plans
new products, discoveries or services
major personnel changes
Merger, acquisition and divestiture plans
Financing plans
Proposed securities offerings
Government actions
Substance of major litigation or potential claims
Negotiation or termination of major contracts
Rating or pending rating actions

If you are not sure whether or not a particular piece of information is Material Information, you should err on the side of caution and assume that it is Material Information. In other jurisdictions, Material Information may be referred to as “inside information” or “price-sensitive information”.

Material Nonpublic Information refers to information that is both Material and Non-Public Confidential Information.

### Physical Assets and Resources

All employees and contractors must protect our [company assets](/handbook/spending-company-money/), 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](/handbook/people-group/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](/handbook/people-group/acceptable-use-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](/handbook/marketing/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:

* We follow all applicable laws and regulations directed toward privacy and information security. Keeping customer information secure and using it appropriately is a top priority for our company.
* We must safeguard any confidential information customers or third parties share with us.
* We must also ensure that such information is used only for the reasons for which the information was gathered, unless further use is allowed by law.
* We do not disclose any information about a third party without their written approval unless legally required to do so (for example, under a court-issued subpoena).

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](/handbook/security/).

### Intellectual Property and Protecting IP

Our [intellectual property](/handbook/contracts/#piaa-agreements) 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](/handbook/finance/authorization-matrix/)
6. View our [DMCA policy](/handbook/dmca) in regards to copyright / intellectual property violations

Assignment of intellectual property is addressed in the [employee and contractor templates](/handbook/contracts/#employee-contractor-agreements), 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:

* entering into agreements with competitors to fix prices, terms of sale or production output
* to engage in bid rigging
* to divide markets or customers
* to attempt to discriminate in prices or terms of sale among our customers
* to otherwise restrict the freedom of our customers to compete
* refusing to deal with certain customers or competitors

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:

  * Prices or pricing strategy
  * Discounts
  * Terms of our customer relationships
  * Sales policies
  * Marketing plans
  * Customer selection
  * Allocating customers or market areas
  * Contract terms and contracting strategies

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:

  * Exclusive dealing
  * Bundling / package offerings
  * Resale restrictions
  * Selective discounting

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:

  * publicly available information such as news accounts
  * industry surveys
  * competitors' displays at conferences and trade shows
  * information publicly available on the Internet
  * from customers and suppliers (unless they are prohibited from sharing the information)
  * by obtaining a license to use the information or actually purchasing the ownership of the information

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.
1. Kickbacks are agreements to return a sum of money to another party in exchange for making or arranging a business transaction.
1. A bribe is defined as directly or indirectly offering "anything of value" to influence or induce action, or to secure an improper advantage.
1. "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.
1. 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](/handbook/sales/public-sector/)** for more details on dealing with the US Federal Government.  Please note that government agencies, in general (US or otherwise) have more strenuous 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](https://docs.google.com/spreadsheets/d/1EbyOSQvjiT4KJGB0_evhJEfKlvp2qKaJJbyzknCEPzA/edit?usp=sharing) 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:

* ensure legal and ethical business practices
* prevent fraudulent activities
* ensure that the information we record, process, and analyze is accurate, and recorded in accordance with applicable legal or accounting principles
* ensure that it is made secure and readily available to those with a need to know the information on a timely basis

GitLab records include:

* booking information
* payroll
* timecards
* travel and expense reports
* e-mails
* accounting and financial data
* measurement and performance records
* electronic data files
* all other records maintained in the ordinary course of our business

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:

* paper documents
* e-mail
* electronic files stored on disk
* tape or any other medium (CD, DVD, USB data storage devices, etc.) that contains information about our company or our business activities

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](/handbook/contracts/#approval-for-outside-projects). 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](/company/culture/contribute/coc/).

### 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](https://docs.google.com/document/d/1ehxrg-ieUEx1ARZv4LpysMfxzFmnhgtzmJn1-299g_E/edit?usp=sharing) during onboarding as well as annually during the [Global Compensation Annual Review](/handbook/people-group/global-compensation/#annual-compensation-review) cycle. Please access the form template by clicking [here](https://docs.google.com/document/d/1ehxrg-ieUEx1ARZv4LpysMfxzFmnhgtzmJn1-299g_E/edit?usp=sharing).

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.

Team members that joined prior to the established requirement to upload the acknowledgement at hire are the exception but will be subject to capturing their acknowledgement during annual reviews.

## 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](/handbook/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](/handbook/paid-time-off/#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 Total Rewards Analyst team (aka [Total Rewards](/handbook/people-group/how-to-reach-us/)) 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](/handbook/benefits/#std-ltd) 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](/handbook/contracts/#employee-contractor-agreements):

- Once People Operations has been notified of the sickness they will also inform HRSavvy.
- GitLab has engaged with an occupational health and safety centre, Zorg van de Zaak, to assist employees of GitLab B.V. who may need support while being on long-term sick leave.
- If an employee is sick, People Operations will inform HRSavvy and they will be registered in their HR portal from the first day of sickness.
- If the employee is then on long-term sick leave (1 working week or more), People Operations will instruct HRSavvy to register the employee at the occupational health and safety service, depending on the situation and agreement with the employee.
- Zorg van de Zaak's contact details can be found in the People Operations 1Password vault.

### Worker's Compensation

If you have been injured at work, please contact Total Rewards 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:

* Candidates for employment will not be working directly for or supervising a significant other or relative.
* Candidates for employment will not occupy a position in the same line of authority in which employees can initiate or participate in decisions involving a direct benefit to the significant other or relative. Such decisions include hiring, retention, transfer, promotion, wages, and leave requests.

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

### Relocation

If your permanent address is changing, notify the Total Rewards Analyst at total-rewards@ 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.

- The Total Rewards Analyst will also update the locality field in BambooHR (if applicable), Payroll, and the Compensation Calculator with the change.
- If you are changing from one entity to another, the Total Rewards Analyst will list you as terminated on the appropriate payroll changes file for the current entity and add you as a new hire in the appropriate payroll changes file for the new entity.
    - They will also change your benefit group in BambooHR to INELIGIBLE and send an email to Lumity with the termination date and coverages to be terminated if you are moving out of the US. They will place you in the appropriate benefit group in BambooHR and send an email to Lumity with your relocation date if you are moving into the US.

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 your relocation is to a different geo area, then to stay aligned with our [compensation principles](/handbook/people-group/global-compensation/#compensation-principles) and per the [standard contract agreements](/handbook/contracts/), you should obtain written agreement first from your manager (email will do) and then from the Total Rewards Analyst team (aka [Total Rewards](/handbook/people-group/how-to-reach-us/)). You must have approval 30 days prior to any official move. If you are considering a move it is best to discuss this with your manager as soon as possible, before you have actually moved, to understand the impact to compensation or your role at GitLab. In almost all situations the compensation may change. In some instances a move will not align to your proposed location, (e.g. a recruiter hired in EMEA to support EMEA would not be approved to move to the US). It is the company's discretion to offer you a contract in your new location or to not continue with your contract based on a relocation. For an idea about the impact please check with our Compensation & Benefits Manager, Brittany Rohde, for an accurate salary in the new [geographical area](/handbook/people-group/global-compensation/#geographical-areas).
- To initiate a request for relocation the team member or manager can reach out to their assigned People Business Partner (PBP).  The PBP will work with the Total Rewards team to review the request and any changes in compensation.
- If a team member is moving to a location with a lower or equivalent location factor, the change only needs to be approved by their manager and the assigned People Business Partner. If the team member is moving to a location with a higher location factor they will need their People Business Partner and their group Executives approval.
- Once approved the PBP will confirm the relocation with the Total Rewards team.
- The Total Rewards Analyst team will check that any necessary changes to payroll and benefits administration are processed in time.
- The Total Rewards Analyst team will generate a letter of adjustment confirming the changes.
- This letter is drafted by the Total Rewards Analysts and signed by the Compensation & Benefits Manager and the signed document is filed in BambooHR.
- If there are any questions or concerns, please reach out to your People Business Partner.

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](https://www.udacity.com/).

GitLab team-members are eligible for a reimbursement of up to [20,000 USD](/handbook/people-group/global-compensation/#exchange-rates) 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](/handbook/finance/authorization-matrix/). 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:

* A Backend Engineer who is not on a performance improvement plan seeking a bachelor's degree in Computer Science.
* A People Operations Generalist seeking a master's in Human Resources with a concentration in International Employee Relations.
* A Security Analyst seeking to take courses to gain a Cybersecurity certificate through an accredited college or university.
* A Product Marketing Manager seeking to take courses to become a Certified Brand Manager from The Association of International Product Marketing and Management.
* A Technical Account Manager seeking to obtain a Cloud Certification such as CompTIA Cloud, AWS Certified Solutions Architect, MicroSoft MCSA/MCSE, Cisco CCNA/CCNP.

Examples of requests that may be denied:

* A Marketing Manager seeking a master's in Human Resources, but has no intention of applying to a role in people ops.
* A Frontend Engineer seeking a master's in computer science who is on a performance improvement plan or having discussions around underperformance.

#### 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.
1. 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](https://docs.google.com/document/d/1-WvPzoUMpcaUUOm3Gl5eDKQDw_-TtI4J0LP5ifMa8Vo/edit) and forwards it to the Total Rewards Analyst team at total-rewards@ domain to stage for the proper signatures (GitLab team member, Manager, People Operations) in HelloSign.
1. The Total Rewards Analyst will confirm there are no additional [tax implications](/handbook/people-group/code-of-conduct/#tax-implications-for-tuition-reimbursement-by-country) for reimbursement in the team member's country.
1. The Total Rewards Analyst  will file the application and signed agreement in BambooHR.
1. The Total Rewards Analyst will also log the tuition reimbursement in the "Tuition Reimbursement Log" found on the Google Drive.
1. Once the course is completed, an official grade report or successful certification of completion must be submitted to People Operations.
1. 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 Total Rewards Analyst at total-rewards@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](mailto:payroll@gitlab.com) or [People Ops](mailto:peopleops@gitlab.com) when you have questions.

### Employee Safety

**Preventing Unsafe Situations**

While GitLab is 100% remote, there may be times when employees travel for work related functions or co-working events.  GitLab is committed to the value of a safe, violence-free work environment and ensuring and exhibiting equal commitment to the safety and health of employees.

In general, please consider the following recommendations to ensure safety when traveling or coworking:

1. Do the research.  Have some familiarity with the destination before you arrive.  Check with your country's government department that provides advice for traveling overseas:
  * United States citizens: check the State Department's website for country updates and enroll in a Traveler Program such as Smart Traveler Enrollment Program (STEP) [https://step.state.gov/step/](https://step.state.gov/step/).
  * New Zealand citizens: [https://safetravel.govt.nz/](https://safetravel.govt.nz/).
1. Try not to draw attention.  People who appear to be from out of town are more vulnerable to crimes.  Try to respect the culture you are visiting by blending in. Consider protective clothing to avoid pickpockets or other theft. Do not flash money or credit cards unnecessarily.
1. Make copies of important documents.  Consider carrying hard copies of important documents (passport, driver's license) in a separate location in the event your documents are misplaced or stolen.
1. Keep friends and family updated. No matter whether you’re going on an overnight jaunt or a week-long international journey, it’s always a good idea to let friends or family know your plans. Before you leave, send a copy of your itinerary to a few trusted people who can keep tabs on your whereabouts. Check in regularly with your contacts so they know you’re where you’re supposed to be.
1. Be wary of public Wi-Fi.  Be aware that hackers can steal sensitive information in the public forum.  Use a VPN or other secure access if you plan to access sensitive data. More information on [VPN usage in GitLab](/handbook/security/#why-we-dont-have-a-corporate-vpn)
1. Safeguard your hotel.  Lock and deadbolt the door while you are in the room.  Ensure the door is locked when you leave.  Keep the windows closed. Try to give the impression that you’re in your room even when you’re away, such as placing the Do Not Disturb sign on the outside of your door and keeping the blinds or windows closed.  Don’t let any strangers into your room, even if they say they work for the hotel. You can always call the front desk to check whether someone was ordered by hotel staff to come to your room.
1. Be aware of your surroundings.  Always keep an eye on your personal belongings and use good judgment when talking to strangers. A big part of the joy of traveling is the opportunities it affords to meet new people and learn about their cultures. But if someone near you is acting suspiciously, or if you feel uncomfortable, leave the area immediately.  Trust your instincts.
1. Adhere to any recommended safety recommendations made by the GitLab group. For all large self-hosted events we (jointly completed by our internal security team and our contracted security agency) will do a full risk assessment  before we converge. It will be up to employees to read said risk assessment and adhere to recommendations outlined.
1. If you are sick please do not come or participate in person workplace activities. This is for your safety and for others. We recommend GitLabbers not travel while sick.


**Measures GitLab Takes to Aid Employee Health and Safety**
1.	Hand sanitizers placed around venue of live events or attendees given hand sanitizer.
1.	Employees can expense masks for travelling if suggested in risk assessment outlined above.
1.	Sick employees should expense mask if flying.
1.	If health risk is considered high, all food to be served by food health professionals rather than team.
1.	Fist bumps over handshakes.
1.	Sick/ Contagious employees may not participate in team food preparation activities.

**Responding to Unsafe Situations:**

The following are GitLab’s procedures in the event an employee feels threatened or unsafe:

1. If at any point, an employee feels that they are in danger of physical harm, please contact the local authorities immediately.  Local law enforcement can act quickly to protect the individual and neutralize any threats.
1. If at any point an employee feels like they or another employee may require immediate medical assistance, please contact the local authorities.
1. Once the immediate threat is controlled, employees should report any safety concerns to People Ops.
1. If you believe that a certain location, event or area presents greater risk or exposure to individuals, please notify People Ops.  People Ops can proactively communicate the concerns to other [potentially] affected employees.
1. If at any point you believe you, personally, may commit an unsafe act, People Ops can assist in providing information about available [Employee Assistance Options](/handbook/benefits/#employee-assistance-program).

### Mental Health Awareness

The World Health Organization (WHO) [defines health](https://www.google.co.uk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0ahUKEwj3oZ7I1M_XAhUsI8AKHXWiC5EQFggmMAA&url=http%3A%2F%2Fwww.who.int%2Fgovernance%2Feb%2Fwho_constitution_en.pdf&usg=AOvVaw0usN4G0kSEScrW3HqENGIr) as:

* "a state of complete physical, mental and social well-being and not merely the absence of disease or infirmity.  The enjoyment of the highest attainable standard of health is one of the fundamental rights of every human being without distinction of race, religion, political belief, economic or social condition."

The WHO [defines **mental health**](http://www.who.int/features/factfiles/mental_health/en/) as:

* “a state of well-being in which the individual realizes his or her own abilities, can cope with the normal stresses of life, can work productively and fruitfully, and is able to make a contribution to his or her community.”

Defining the terms from the sentence above:

* *"A state of well-being"* is a self-reported measure of 'wellness'.
* *"The individual realizes his or her own abilities"* requires feedback, positive or negative.
* *"Can cope with the normal stresses of life"* i.e. does not find normal life overwhelming too much of the time.
* *"Can work productively and fruitfully"* here GitLab clearly has a role to play as it can provide an opportunity for productive and fruitful work.
* *"Is able to make a contribution to his or her community"* versus the inverse, which is only being able to draw from that community.

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](http://www.who.int/whr/2001/media_centre/press_release/en/) 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](https://www.google.co.uk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwitr7eP18_XAhWIORoKHY2_CA4QFggrMAA&url=https%3A%2F%2Fcardinal-management.co.uk%2Fwp-content%2Fuploads%2F2016%2F04%2FBurton-Waddell-is-work-good-for-you.pdf&usg=AOvVaw0ROXJdWquGML5bIsBEIRLo).
   * In the cold-light of business metrics, the healthier we are, [the more productive we are](https://www.rand.org/randeurope/research/projects/workplace-health-wellbeing-productivity.html).

1. 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.

1. 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](https://gitlab.slack.com/messages/C834CM4HW) Slack channel.
   * GitLab would also like to encourage GitLab team-members to take their [time off](/handbook/paid-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](https://www.workplacestrategiesformentalhealth.com/employee-resources/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 team members 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.

GitLab has contracted with [Sterling Talent Solutions](https://www.sterlingtalentsolutions.com/) 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. 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.

All candidates who make it to the offer 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. If a candidate is unwilling to follow this process we are unable to proceed with their candidacy for any position at 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 Candidate Experience Specialists will [initiate](https://about.gitlab.com/handbook/hiring/recruiting-framework/coordinator/#step-20c-initiate-background-check) all background screenings for candidates. Background check results will be received by the Candidate Experience Specialist and brought to the relevant People Business Partner and functional leader to determine if the results warrant any adverse action, which could include rescinding of the offer or termination of employment.

#### Disclosure and Authorization

Candidates (as applicable, employees) will receive an email to fill out the background check application. The application will ask for personal and professional information. 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.

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 job duties with competence and integrity. Criminal convictions that would raise a concern are job-related offenses, including but not limited to: embezzlement, extortion, computer/internet crime, fraud, tax evasion, and violent crimes. In addition, the report should be reviewed for omissions or inaccuracies contained in the employment application or made during the interview process.

#### Fair Credit Reporting Act (FCRA) and Related State Law Compliance

**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 they complete 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.
1. The number of offenses for which the individual was convicted.
1. The age of the individual at the time of conviction or release from prison.
1. 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.
1. The length and consistency of employment history before and after the offense.
1. Any efforts of the applicant towards rehabilitation.
1. Employment or character references obtained regarding the individual’s fitness for the particular position.
1. 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. See [this page](https://about.gitlab.com/handbook/hiring/recruiting-framework/coordinator/#step-20c-initiate-background-check) for process details.

### 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](/handbook/offboarding/#involuntary-terminations) for job abandonment unless otherwise required by law.

If a manager is unable to reach a team member via email or slack within a 24 hour period they should contact their [People Business Partner](https://about.gitlab.com/handbook/people-group/how-to-reach-us/#people-business-partner-alignment-to-groups). The People Business partner will access the team member's information to obtain additional contact methods and numbers. The manager and People Business Partner will create an action plan to make all attempts to contact the team member.

### Other People Policies

* [United States Employment Status](/handbook/contracts/#united-states-employment-status)
* [PIAA Agreements](/handbook/contracts/#piaa-agreements)
* [360 Feedback](/handbook/people-group/360-feedback/)
* [Return of Property](/handbook/offboarding/#returning-property)
* [Promotions and Transfers](/handbook/people-group/promotions-transfers/)
* [General Benefits](/handbook/benefits)
* [Entity Specific Benefits](/handbook/benefits/#entity-specific-benefits)
* [Parental Leave](/handbook/benefits/#parental-leave)
* [Paid Time Off](/handbook/paid-time-off/)
* [Probation Period](/handbook/contracts/#probation-period)

### Partner Due Diligence

GitLab’s Anti-Bribery Policy prohibit giving illegal or improper payments to, or receiving such payments from, any person or organization, including government officials (U.S. and foreign) and persons in the private sector. Such payments also are prohibited by the U.S. Foreign Corrupt Practices Act ("FCPA") and anti-bribery laws and regulations in foreign jurisdictions, including but not limited to the U.K. Bribery Act 2010 and the European Commission on Anti-Corruption (collectively, “Anti-Bribery Laws”).

GitLab’s export policy requires that we ensure compliance with applicable export laws including the Export Administration Regulations (EAR), the International Traffic in Arms Regulations (ITAR) (if and to the extent they become applicable to GitLab’s products), general prohibitions and country control lists (collectively “Export Laws”).

It is an offense under Anti-Bribery Laws for a company to engage a third party who pays bribes in connection with the company’s business. Additionally, it is an offense under US Export Laws for a company to engage a third party who violates export laws.  In short, GitLab can be held criminally and civilly liable for the bad acts of its partners.

Therefore, the Anti-Bribery, Anti-Corruption and Export Policy applies not only to GitLab’s employees, but also to all resellers, agents, consultants, joint venture partners or other representatives who provide services directly related to obtaining, retaining or facilitating businesses or business opportunities for GitLab (“Partners”).

In order to minimize the risk relating to Anti-Bribery Law and Export Law violations from such third parties, due diligence will be conducted on GitLab Partners.  Due diligence is the process of taking reasonable steps to satisfy legal requirements and ensure that there are no red flags associated with the respective Partner ("Due Diligence"). The manager of the relationship is responsible for ensuring that the Due Diligence is conducted.

For GitLab, Due Diligence is verification that the proper contract terms are in play with the appropriate parties and verification that no Red Flags are present prior to moving forward in a relationship. If a red flag is present, the matter should be escalated to Legal.  Legal will make a recommendation on whether or not to pursue the relationship based on the circumstances.  Legal, at its sole discretion, will document justification for its final disposition.

Red Flags include:
  A poor credit check;
  Presence of media reports or rumours relating to illegal payments, bribes, export violations, corruption or other criminal activity;
  Requesting an unusually high commission if an agent or if a reseller is requesting to be paid money;
  Partner requesting a cash payment or payment to a secret account;
  Partner requesting third parties to be added to a contract;
  Partner refuses to disclose owners or principals for purposes of a credit check;
  Partner attempts to negotiate around (or refuses to agree to) terms around penalties around corruption or violation of law; and/or
  A negative hit on Denied Party Screen.  (Denied Party Screens are conducted by Legal or Compliance.)

Please contact Legal or Compliance with questions or concerns about this section.

### Partner Code of Ethics

GitLab, Inc. and its respective affiliates, subsidiaries and divisions (“GitLab”) operate business in a responsible manner. At GitLab, the way we conduct business is as important as the relationships we have and the products and services we provide. Accordingly, GitLab will only do business with suppliers, contractors, resellers, agents and consultants (collectively herein referenced as “Partners”) that comply with applicable and controlling laws, rules, and regulations (collectively herein referenced as “applicable laws”) and at a minimum, with standards of business conduct consistent with those set forth in this Partner Code of Ethics (“Code”).

It is GitLab’s expectation that Partners, their employees, sub-suppliers and any other parties involved with the execution of GitLab work, similarly comply with the applicable laws and the standards set forth in this Code. GitLab expects the following, without limitation, including respecting the human rights of employees from all its Partners:

**HUMAN RIGHTS AND LABOR STANDARDS**

*Forced Labor, Human Trafficking and Slavery*
Partner shall not use any form of forced labor including prison, indentured, bonded, military, slave or any other forms of forced labor. Partner shall not participate in the recruitment, transportation, transfer, harboring or receipt of any persons by means of threat, use of force, or any other forms of coercion, abduction, fraud, deception, abuse of power or position of vulnerability, or the giving or receiving of payments or benefits to achieve the consent of a person having control over another person for the purpose of exploitation. Partners shall not retain an employees’ government-issued identification, passports or work permits as a condition of employment and shall allow employees to resign from their positions at any time.

*Child Labor*
Partner shall ensure that no underage labor has been used in the production or distribution of their goods or services. Employees must not be younger than the minimum employment age established by the respective country or local jurisdiction. In the event no minimum employment age is established, employees must not be younger than the age of compulsory education; or if no minimum age for compulsory education is established, employees should not be younger than age 14.

*Working Hours*
Partner’s employee working hours must be in compliance with all applicable laws and regulations. Partners should encourage employees to receive at least one day off every seven days in compliance with all applicable laws.

*Wages and Benefits*
Partners must have a system in place to verify and accurately record payroll, deductions and the hours worked by legally authorized employees. Partners must comply with all applicable wage and compensation requirements as defined under applicable labor laws for regular work, overtime, maximum hours, piece rates, and other elements of compensation and employee benefits.

*Freedom of Association and Collective Bargaining*
Partner must adhere to applicable laws regarding the right to affiliate with lawful organizations without interference.

*Nondiscrimination*
Employment by Partner shall be based solely on an individual’s ability and not personal characteristics. Partner shall maintain a workplace free of unlawful discrimination, which includes, but is not limited to, race, gender, sexual orientation, age, pregnancy, caste, disability, union membership, ethnicity, religious belief or any other factors protected by applicable law. Employees shall not be subject to verbal, physical, sexual or psychological abuse or any other form of mental or physical coercion and shall be treated with respect and dignity.

*Conflict Minerals*
Partner shall abide by all regulations and laws relating to conflicts minerals and legal and sustainable sourcing.

**HEALTH AND SAFETY**

Partners shall provide safe and healthy working and housing environments (if Partner provides housing) to prevent accidents and injury to health. Partners shall minimize employee exposure to potential safety hazards by identifying, assessing and minimizing risks by developing and implementing plans and procedures.

**ENVIRONMENT**

Partners shall be sensitive to its impact on the environment (including but not limited to air emissions, water discharge, toxic substances and hazardous waste disposal) and local communities. Partner shall comply with the environmental laws and standards within its facilities. Partners must use care in handling hazardous materials or operating processes or equipment that use hazardous materials to prevent unplanned releases into the workplace or the environment.

**ANTI-BRIBERY AND ANTI-CORRUPTION**

Partners shall not engage in any form of corrupt practices including without limitation to, extortion, fraud, impersonation, false declarations, bribery, money laundering, supporting or involved with terrorist or organized crime organizations or activities. Partners shall not offer bribes, kickbacks, illegal political contributions or other improper payments to GitLab representative or agency, any customer, government official or third party, with the intention of obtaining or retaining a business or other improper advantage. Partners must have a written anti-corruption / anti-bribery policy that includes an annual review with its employees of such policy.

**PRIVACY AND SECURITY**

Partners shall ensure that there are appropriate administrative, technological, physical and technical controls in place to ensure the protection and security of any data subject subject to laws and regulations.  Partners will execute any necessary agreement relating to the handling of data and will notify GitLab of any known or suspected vulnerabilities that may compromise individuals subject to the relationship with GitLab.

**COMPLIANCE**

If a Partner’s efforts to comply with this Code have been deficient and Partner fails to cooperate in developing and implementing reasonable remedial steps, GitLab reserves the right to take appropriate actions up to, and including, discontinuing the relationship with Partner. Nothing in this Code is intended to, in any way, grant any additional rights or expectations to a GitLab Partner or, in any way, modify or otherwise limit any of GitLab’s contractual or legal rights.

No matter where we operate around the world, we are steadfast in our dedication to service and integrity. Strong partnerships are a cornerstone of GitLab’s business and a vital link in setting and achieving expectations for ethical sourcing and corporate social responsibility. At GitLab, the way we conduct business is as important as the people with whom we conduct business. services we provide.