This is a Controlled Document
Inline with GitLab's regulatory obligations, changes to controlled documents must be approved or merged by a code owner. All contributions are welcome and encouraged.
All of the policies listed below are important for GitLab team members to read and understand as they deal with people benefits, entity specific issues, and procedures and requirements of the company. If you have any questions around the internal policies, please reach out to People Operations at people-connect@gitlab.com.
These policies apply to all GitLab team members, contractors, advisors, and contracted parties interacting with GitLab computing resources and accessing company or customer data.
| Role | Responsibility |
|---|---|
| GitLab Team Members | Responsible for following the requirements in these policies |
| PeopleOps | Responsible for implementing and executing these policies |
| Legal & PeopleOps Management (Code Owners) | Responsible for approving significant changes and exceptions to these policies |
We encourage 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, concerns, 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 or Team Member Relations. It is important to remember that a team member who takes these steps will not be subject to retaliation. You can expect to be treated fairly and with respect.
GitLab uses appropriate controls to ensure that its assets and its customer relationships and information are protected. To reduce these risks, GitLab will obtain and review background information of covered prospective, and, as applicable, current team members as allowed by local law. Contractors will also be required to complete a background screening per GitLab's Third Party Risk Management Policy and as allowed by local law. GitLab will run background screenings for independent contractors that are hired directly, but otherwise, will defer to each contractor's hiring agency's background screening policies and processes. GitLab will complete a background screening for contractors employed by agencies that do not conduct their own background screenings.
GitLab currently contracts with Sterling Talent Solutions to provide background screenings. For all candidates being considered for a position at GitLab, an employment history for the last 5 years and/or the three most recent employers will be verified in accordance with applicable local law (if applicable local law limits the review of employment history to fewer years and/or employers, then GitLab follows local law). In jurisdictions where criminal records may be reviewed, criminal records will be requested. Additional screenings may include, where applicable and in accordance with local law, a search of the Office of Foreign Assets Control Sanctions List or Extended Global Sanctions, and/or the U.S. Department of Health and Human Services Office of Inspector General's List of Excluded Individuals/Entities. For certain positions where the candidate's financial history is relevant to the position, GitLab may also run a screening for any financial related offenses and may also run a credit check. GitLab may use the returned background information to make decisions regarding employment, where allowed by local law. No background screening will be run until a conditional offer has been made, unless local law explicitly requires otherwise.
In the event the background screening is not available on the scheduled hire date due to delays in processing, GitLab will run the background screening as soon as possible. The same adjudication guidelines will apply to current employees as they do with prospective employees. The Senior Background Check Specialist will monitor background screenings for completion and accuracy and will follow up accordingly regarding any concerns or issues.
The Candidate Experience Specialists will initiate all employment verifications and background screenings for candidates. The Senior Background Check Specialist will initiate any applicable retroactive background screenings or requested enhanced background screenings for current team members.
Please contact the Senior Background Check Specialist at backgroundchecks@gitlab.com regarding any questions.
Candidates (and, as applicable, current team members) will receive an email to fill out the background screening 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 screening. The application process is designed to take less than fifteen minutes to complete.
To prepare for the employment verification for those candidates being considered for Director level positions or higher, 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, and where permitted by law, 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. In certain circumstances, the Senior Background Check Specialist may also reach out to candidates and/or team members for additional documentation.
Background screenings will act as an additional mechanism of transparency and will help to build trust with our clients.
Reviews of the background screening are conducted by the Senior Background Check Specialist in accordance with the applicable law of the candidate’s jurisdiction. The Senior Background Check Specialist will first review the report for omissions, inaccuracies, and/or discrepancies with employment, including, but not limited to, dates of employment, employer names, or positions held. If the report includes discrepancies related to employment, the Senior Background Check Specialist will take the necessary steps to investigate and adjudicate the discrepancies and/or reach out to Team Member Relations for additional support and collaboration. The Senior Background Check Specialist and Team Member Relations may escalate the report, as necessary, to the Legal Employment team. Employment decisions based on the employment verification portions of the background screening report shall be finalized before any review of the criminal records information takes place.
If criminal record information has been provided, then it will be adjudicated in accordance with applicable local law. Generally, and subject to local law, criminal records are reviewed to determine if criminal convictions have a direct connection with an applicant’s ability to fulfill the job duty with competence and integrity, while also considering the safety and/or security of Gitlab team members, customers, vendors, and/or overall business. Decisions are made that are job related and consistent with business necessity. Arrest records are not considered during the adjudication process, nor is any criminal conviction information that is prohibited from being reviewed by applicable local law.
Hiring Significant Others or Family Members
GitLab is committed to a policy of opportunities based on qualifications and merit and does not discriminate in favor of or in opposition to the employment or affiliation of significant others or family members. 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 for hire significant others and/or family members of persons currently serving as team members only if all points below are true:
This policy applies to all current team members and candidates for open roles. In the spirit of our Transparency value, we ask the team member and the candidate to disclose the family relationship to the recruiter at the beginning of the hiring process. For purposes of this policy, a significant other or family member is any person who has a relation by blood, marriage, adoption, or domestic partnership within the third degree of our team member. If the candidate progresses through the process as a final candidate, and prior to any offer, the recruiter should notify the hiring manager and the People Business Partner of the family relationship to ensure there is not a conflict of interest. In addition, the GitLab team member should not be part of their family member's interview process. If there is a concern that either the team member or the candidate may progress to a position that would trigger one of the conditions above, a waiver will be signed by both parties acknowledging that future work assignments, promotions, etc may be impacted by enforcement of this policy.
Active Team Member Relationships (Significant Other or Family Members)
Please report any relationship with a significant other or family member to your People Business Partner, if you find yourself in a reporting relationship with the significant other or family member. Furthermore, if two team members who are in a reporting relationship become significant others or family members in the course of their employment, they should also report the relationship to the People Business Partner. Transfers, promotions, and future work assignments will be made in accordance with all applicable anti-discrimination laws and policies.
As stated in the Confidentiality and Corporate Assets and Corporate Opportunities section of the Code of Business Conduct and Ethics, team members are, on occasion, entrusted with confidential GitLab information and with the confidential information of GitLab suppliers, customers, or other business partners. This information may include:
This information, if disclosed, might be of use to competitors, or harmful to GitLab's suppliers, customers or other business partners. This information is the property of GitLab, or the property of its suppliers, customers, or business partners, and in many cases was developed at great expense. All team members, upon commencement of their role with GitLab, shall sign offer letters or contractor agreements that contain confidentiality provisions (the “Confidentiality Agreement”) provided by GitLab. Strict adherence to the Confidentiality Agreement is required of each team member.
Team members shall not take for themselves, or for family members, or any other entities with which they are affiliated, any opportunity of which they become aware through the use of GitLab property or information, or through their position with GitLab, and shall not use GitLab property or information, or their position with GitLab, for personal gain other than actions taken for the overall advancement of the interests of GitLab.
Team members 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 this 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.
Exceptions to this procedure will be tracked as per the [Information Security Policy Exception Management Process] (https://about.gitlab.com/handbook/security/#information-security-policy-exception-management-process). For reference see the Parent Policy: Information Security Policy.
Please see the Anti-Harassment Policy.
Please see the Anti-Retaliation Policy.
Please see the Complaint Procedure.
Please see our Environmental, Social, and Governance page.
The image GitLab projects to the public is reflected in the appearance of our team members. Simply stated, team members should be dressed and groomed appropriately for their specific duties. Team members are expected to use good judgment in their appearance and grooming. Read our GitLab Events Code of Conduct for more information. Please read our GitLab Events Code of Conduct for more information regarding team member responsibility during attendance at company-sponsored events.
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 their supervisor, they may be terminated 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. 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.
GitLab understands there are extenuating circumstances that can occur. In the instance that a team member is absent from work for three consecutive workdays due to an emergency outside of the team members' control (ex. an internet outage in their country of residence), the recommendation is:
While GitLab is 100% remote, there may be times when team members 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 team members.
In general, please consider the following recommendations to ensure safety when traveling or coworking:
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.
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.
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.
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 at GitLab and the Personal VPN page.
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.
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.
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.
The following are GitLab’s procedures in the event a team member feels threatened or unsafe:
If you have been injured at work, at a co-working site, or traveling to a customer location please contact the Absence Management team (leaves@gitlab.com). The Absence Management team will provide you with paperwork to file your claim and explain your benefits.
CA Team Members Only: Complete this form and email to the Absence Management Team at leaves@gitlab.com.
The following states are considered “monopolistic” workers compensation states, meaning employers must purchase workers compensation coverage directly from the state. If a team member in these states is injured, they may file the claim themselves or the Absence Management Team will file on their behalf. Team members in these States are still required to contact the Absence Management Team, even if they file their own claim through the State:
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 for company-sponsored events.
For additional information, please see the Mental Wellness Services offered through Modern Health and tips on Leading Through Adversity. Additionally, team members should learn to recognize burnout and to prevent it.
Any questions or concerns? Please feel free to contact the People Connect team in the #people-connect Slack channel or email people-connect@gitlab.com.
There are a number of GitLab Legal Policies which are important for GitLab team members to read and understand, and they are listed here.
Workplace Regulations
Health and Safety
To ensure the health and safety of our team members in Germany, and to maintain compliance with the German Occupational Safety and Health Act, all team members in Germany will complete the following checklist at onboarding. If you think you may need accommodations in order to achieve and/or maintain a healthy and safe work environment, please contact People Connect. If you need to report an accident or injury, please contact Team Member Relations.
Health and Safety
Complaint and Disciplinary Procedures
Health and Safety
To ensure the physical and mental health and safety of our team members in Ireland, and to maintain compliance with local employment regulations, all team members in Ireland will complete a home working checklist at onboarding. This checklist will be reviewed annually. If you think you may need accommodations in order to achieve and/or maintain a healthy and safe work environment, please contact People Connect. If you need to report an accident or injury, please contact Team Member Relations.
None currently applicable specific to team members in Korea.
GitLab LTD (UK) Homeworking and Flexible Working Policy
Health and Safety
GitLab Ltd (UK) Health and Safety Risk Assessment
To ensure the physical and mental health and safety of our team members in the UK, and to maintain compliance with local employment regulations, all team members employed by GitLab Ltd. must review the guidelines for working comfortably at home and complete a home working risk assessment at onboarding. If you think you may need accommodations in order to achieve and/or maintain a healthy and safe work environment, please contact People Connect. If you need to report an accident or injury, please contact Team Member Relations. Team members should regularly inspect their home offices for potential hazards related to the following:
The handbook also has a wealth of information and recommendations for setting up your workspace and procuring the proper equipment:
Working Time Regulations
What are the Working Time Regulations?
The Working Time Regulations (1998) were introduced to support the health and safety of workers by setting maximum requirements for the number of hours that they can work, paid time off and rest periods.
The 48-hour working week
The regulations state it is illegal for you to work any time over a total of 48 hours each week. You can agree to exceed this limit if you want to, but you cannot be mandated to work more than 48 hours per week. Average working hours are calculated over a ‘reference’ period, which is usually 17 weeks. This means you can work more than 48 hours one week, as long as the average over 17 weeks is less than 48 hours a week. For more information about the 48-hour working week restrictions, please visit the government's website.
How to opt-out of the 48-hour working week
It is entirely your decision if you would like to work more than an average of 48 hours a week. GitLab is committed to enabling team members to maintain a healthy work-life balance, but on occasion (for example during periods of high customer demand) you may be asked to work longer hours. To ensure that we remain compliant with the regulations, we ask you to opt out of them, in case such a need arises. If you would like to opt-out, you can do this by signing this written agreement, known as the opt-out agreement. You may have chosen to sign/confirm this agreement already during your onboarding. The duration of the agreement is indefinite. If you haven't already signed this agreement but would like to do so, you can make a copy of this document, add your name and sign it, and email a copy to people-connect@gitlab.com, with a request that it be saved with your documents in Workday.
How do I cancel my opt-out agreement?
You can choose to cancel your opt-out agreement at any time. The notice period you are required to give is three months.
Health and Safety
To ensure the physical and mental health and safety of our team members in Australia, and to maintain compliance with local employment regulations, all team members in Australia will complete the following checklist at onboarding. This checklist will be reviewed annually. If you think you may need accommodations in order to achieve and/or maintain a healthy and safe work environment, please contact People Connect. If you need to report an accident or injury, please contact Team Member Relations.
Health and Safety
To ensure the physical and mental health and safety of our team members in New Zealand, and to maintain compliance with local employment regulations, all team members in New Zealand will complete the following survey at onboarding. The responses will be reviewed annually. If you think you may need accommodations in order to achieve and/or maintain a healthy and safe work environment, please contact People Connect. If you need to report an accident or injury, please contact Team Member Relations.
Health and Safety
Data Protection/Privacy Policy
Workplace Harassment Policy
Fair Employment Practices Policy
