Confidentiality levels

1. You are here:
2. GitLab Communication
3. Confidentiality levels

On this page

• Public by default
• Not public
  • Internal
  • Limited access
    • Project names

Public by default

At GitLab, we are public by default, but some information is classified as internal or limited access. This page provides details on confidentiality levels.

Not public

We make things public by default because transparency is one of our values. Some things can't be made public and are either internal to the company or have limited access even within the company. If something isn't listed in the sections below we should make it available externally.

Internal

Some things are internal, available internally but not externally. In instances where a topic should only be accessible to team members, but we would otherwise have a page in the public handbook, it can be added to GitLab's internal handbook. Background on the internal handbook can be found in the public handbook. It is okay to refer to the public handbook or the internal and public handbooks in agregate as "the handbook." The internal handbook should always be referred to as the "internal handbook."

The following items are internal:

1. Security and abuse vulnerabilities are not public since they would allow attackers to compromise GitLab installations. We do make them public after we remediated a vulnerability. Issues that discuss how to improve upon the security posture of an implementation that is working as intended can be made public, and are often labeled as feature proposals. Security and abuse implementations that detect malicious activities cannot be made public because doing so would undermine our operations.
2. Financial information, including revenue and costs for the company, is confidential because we are a public company and, as such, need to limit both the timing and content of financial information as investors will use and rely on it as they trade in GitLab stock. As the guideline, if it is a first step to constructing a profit, we need to keep it confidential. Examples include:
   • The specific IACV of an opportunity
   • Total monthly cash inflow/outflow for GitLab.com
   • Spend of more than 10%
   • A department's cost
   • Team member retention (analysts may make business assumptions based on this)
   • The Sales pipeline (but the Marketing pipeline can be public)
   • Net and gross retention KPIs. Only the actual numbers can't be public. Everything else–the goal, their calculation, etc.–can be.
3. All external communications about any financal information should be in line with the company's SAFE Guidelines and Social Media Policy. If you have any questions please reach out via the #Safe Slack channel.
4. Deals with external parties like contracts and approving and paying invoices.
5. Content that would compromise a GitLab team member, customer, or user's personal data as defined by GDPR, unless explicit consent has been provided by the data owner. Examples of compromising content include a name, an identification number, location data, an online identifier, or one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person.
6. Legal discussions are not public due to the purpose of Attorney-Client Privilege.
7. Acquisition offers for us are not public since informing people of an acquisition that might not happen can be very disruptive.
8. Acquisition offers we give are not public since the organization being acquired frequently prefers to have them stay private.
9. Customer information is not public since customers are not comfortable with that, and it would make it easier for competitors to approach our customers. If an issue needs to contain any specific information about a customer, including but not limited to company name, employee names, number of users, the issue should be made confidential. Try to avoid putting customer information in an issue by describing them instead of naming them and linking to their SalesForce account. When we discuss a customer by name that is not public unless we're sure the customer is OK with that. When we discuss a competitor (for example in a sales call) this can be public as our competitive advantages are public.
10. Competitive sales and marketing campaign planning is confidential since we want to minimize the time the competition has to respond to it.
11. Discussions that involve decisions related to country of residence are not public as countries are a core part of people's identity and any communication should have complete context. The output of such decisions, such as country hiring guidelines, will be public.
12. If public information compromises the physical safety of one or more team members, it will be made not public because creating a safe, inclusive environment for team members is important to how we work. Information that might compromise the physical safety of a team member includes doxxing or threats made against a team member.
13. Information related to a press embargo, or related to an upcoming publication where the response will be managed by our external communications team
14. Information that relies on someone else's copyrighted IP. Our compensation calculator, for example, relies on private sources of information and can't be made completely public.
15. Information related to early exploratory initiatives in which premature sharing of information could slow down purchases.
16. When there is a product offering being developed that is expected to generate very high demand that cannot be quickly met, it should be kept internal in order to give the team the time to create the right solution.
17. Changes to GitLab.com free tier limits such as storage, data transfer, user limits or compute credits are not public as they are similar to Pricing and Packaging as discussed below in limited access.
18. Specific details about our hiring processes such as our scoring rubrics & criteria are not public as we want to ensure candidates provide an accurate overview of their experience and do not falsify their responses to meet our criteria. High-level interview plans are public and documented in each job family.

Limited access

The items below are not shared with all team members. Limited access is a more severe restriction than internal.

1. Deals with external parties like contracts and approving and paying invoices.
2. Content that would violate confidentiality for a GitLab team-member, customer, or user.
3. Customer lists and other customer information are not public since many customers are not comfortable with that and it would make it easier for competitors to approach our customers. If an issue needs to contain any specific information about a customer, including but not limited to company name, employee names, and/or number of users, the issue should be made confidential. Avoid putting customer information in an issue by describing them instead of naming them and by linking to their Salesforce account.
4. Plans for reorganizations. Reorganizations cause disruption and the plans tend to change a lot before being finalized, so being public about them prolongs the disruption. We will keep relevant team members informed whenever possible.
5. Planned pricing changes. Much like reorganizations, plans around pricing changes are subject to shift manage time before being finalized. Thus, pricing changes are limited access while in development. Team members will be consulted before any pricing changes are rolled out.
6. Some discussions on team process and policy changes. Some organizational policies are sensitive in nature and require thoughtful consideration before messaging the changes internally and externally. Relevant team members and leaders will be informed whenever possible.
7. Legal discussions are restricted to the purpose of Attorney-Client Privilege.
8. Some information is kept confidential by the People Group to protect the privacy, safety, and security of team members and applicants, including: job applications, background check reports, reference checks, compensation, terminations details, demographic information (age and date of birth, family or marital status, national identification such as passport details or tax ID, required accommodations), home address. Whistleblower identity is likewise confidential. Performance improvement plans, disciplinary actions, as well as individual feedback are restricted as they may contain negative feedback and negative feedback is 1-1 between you and your manager. However, People Group policies and processes are public (for example, Job families and our Compensation Calculator), along with information that team members choose to share on the Team page.
9. Performance improvement plans, disciplinary actions, as well as individual feedback, are confidential as they contain private negative feedback and negative feedback is 1-1 between team members and managers
10. GitLab's Risk Register is maintained by the Risk & Field Security Team. Access to GitLab’s Risk Register is limited to the Security Compliance Team, VP of Security, Executive Leadership and individually identified employees on a need to know basis. This document is not publicly or internally available as there may be risks on the risk register that explicitly call out the mechanisms available for external actors or internal GitLab team members to access content that would violate confidentiality for a GitLab team-member, customer, or user, and may include Personally Identifiable Information (PII).
11. Acquisition offers for us are not public since informing people of an acquisition that might not happen can be very disruptive
12. Acquisition offers we give are not public since the organization being acquired frequently prefers to have them stay private.
13. Compensation Changes: GitLab will communicate and train team members on the output of iterations to the Total Rewards offerings (Compensation, Equity, Benefits), but team members will not have visibility into the inputs and decision making of compensation changes.
14. Security Incident Investigation: In order to avoid exposing team members to MNPI, the Security Incident Response Team (SIRT) will restrict access to only those necessary to assess the materiality of incidents. Once an incident is determined to not have MNPI the access can be changed to internal.

Project names

Some projects require limited access internally due to the confidential or sensitive nature of the project, including but not limited to projects related to the items listed above. Often, in order to maintain the necessary confidentiality of these types of initiatives, we assign a code name for the project. For consistency and to make it easier to identify the genesis of these projects and their organizational affiliations, we've established the following naming conventions.

Project code names can be overused. Code names should only be used for projects in which the leaking of a descriptive name (even without access to any related content) would be a problem. There are two cases where the project name should be used instead of a name that clearly describes the project.

1. The existence of the project is material non-public information (MNPI). Example: "Gotham" was our project name for our IPO, because GitLab would have been penalized for pre-maturely signaling the imminence of its IPO.
2. Knowledge of the project or initiative is not MNPI but should remain limited access to avoid prematurely sharing information with team members, customers or the wider community. Examples include: "Tiering" was our project name for End of Availability, and "Hamster" was our project name for exploring how to enter China.

In many cases, key project or initiative content will be MNPI or limited access, but we do not use a code name. In these cases, it is okay for folks to have a sense of what is being worked on, but the exact details are sensitive. For example:

1. Q3 Earnings: material is MNPI until formally shared, but team members working on this is known and expected, not sensitive information.
2. Pricing and Packaging: this is an example, but it would be okay to say that we had a group thinking about this even if exact plans were kept limited access.

Once there is no longer a need to limit access of the project's existence for limited access or MNPI reasons, the code name for the project should be retired. Please note that a project does not need to be promoted (e.g., publishing a blog post) in order to be deemed publicly disclosed (i.e., not confidential); publishing the information in GitLab’s external Handbook will suffice. If there are any questions about whether a project still requires the use of the code name, please contact the DRI for such project or contact the Legal Team via the #safe Slack channel.

Team	Theme
CEO	Pets / Animals
Corporate Development	Movie / TV Show characters
Engineering	Hex color names
Finance	Sports team names
Legal	TV Shows / Movies
Marketing	One name famous people
People	Trees
Product	Famous Mountain Peaks
Sales	Car model names