Confidentiality levels

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 please refer to Security’s Data Classification Standard and Legal’s SAFE Framework in the Handbook for additional guidance.

Internal

Some things are internal to GitLab team only. In instances where a topic should only be accessible to team members, but otherwise the content would be in the public handbook, then this information should instead 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 aggregate 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. Anything that is a first step to constructing a profit should be kept 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
   • Net and gross retention KPIs. Only the actual numbers can’t be public. Other details, such as the goal and their calculation, may be public.

3. All external communications about any financial 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 in our Privacy Terms. Examples of compromising content include personal (not GitLab assigned) contact information, location data, online identifiers, employment information, government IDs, financial information, or sensitive data elements related to health, religion, race/ethnictiy, political status, or sexual orientation.

6. Legal discussions are not public due to the purpose of Attorney-Client Privilege.

7. Competitive sales and marketing campaign planning is confidential since we want to minimize the time the competition has to respond to it.

8. Discussions that involve decisions related to country of residence are not public due to privacy and employment considerations. The output of such decisions, such as country hiring guidelines, will be public.

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

10. Information related to a press embargo, or related to an upcoming publication where the response will be managed by our external communications team.

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

12. Information related to early exploratory initiatives in which premature sharing of information could slow down purchases.

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

14. Changes to GitLab.com free tier limits such as storage, data transfer, user limits or compute minutes are not public, as they are similar to Pricing and Packaging as discussed below in limited access.

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

16. GitLab’s strategy, Yearlies, and OKRs are internal-only. GitLab goal setting is intentionally ambitious. External folks, without context, could make misinterpretations about the company’s financial health and strategic plans, so sharing this information may have unintended and undesirable effects.

17. Discussion, designs, and code that are subject to the Discovery phase of a patent application. Prior to filing the application all product and protype development should take place outside of public repositories.

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 information is generally not public due to confidentiality obligations and the problematic use of such information by our competitors. If an issue needs to contain any specific information about a customer, including but not limited to company name, employee names, or number of users, then the issue should be made confidential. When we discuss a customer by name or describe a customer in terms that could make them identifiable, this should only occur in private projects or by linking to the SFDC account in an internal GitLab issue.
4. Plans for reorganizations. Reorganizations may cause disruption and reorganization plans tend to change a lot before being finalized. We will keep relevant team members informed whenever possible.
5. Planned pricing changes. Much like reorganizations, plans around pricing changes are subject to modifications before being finalized. Thus, pricing changes are limited access while in development. Applicable team members will be consulted before any pricing changes are rolled out.
6. Certain discussions that relate to company policy or process changes. Some organizational policies are sensitive in nature and require thoughtful consideration before any communications are made. Relevant team members and leaders will be informed whenever possible.
7. Legal discussions are restricted to the purpose of Attorney-Client Privilege and some may be limited access instead of internal.
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), and home address. Whistleblower identity is likewise confidential. Performance improvement plans, disciplinary actions, and 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 limited information that team members choose to share on the Team page.
9. Acquisition offers by or of GitLab.
10. 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.
11. 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 may 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: as an example only, it would be okay to say that we had a group considering changes to P&P 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.

View page source - Edit this page - please contribute.