GitLab Data Classification Standard

Purpose

The Data Classification Standard defines data type and categories and provides the associated Data Classification of each for the purposes of determining the level of protection to be applied to GitLab and Customer data throughout its lifecycle.

Scope

The Data Classification Standard applies to all GitLab team members, contractors, consultants, vendors and other service providers that handle, manage, store or transmit GitLab data.

Roles & Responsibilities

GitLab Responsibilities

• GitLab team members, contractors, consultants, vendors and all other service providers acting on behalf of GitLab are required to review and understand this data classification standard, and how to handle data according to the classification levels below unless otherwise noted.

• Data Owners shall determine the classification of data in accordance with this standard. The Data Classification Index (internal only) provides a list of various types of data and their classification level. If you cannot identify the data element or are uncertain of the risk associated with the data and how it should be classified and handled, please contact the Security Risk team in Slack via @security-risk.

• To maintain our culture of security, transparency and to minimize the risk to our sensitive data and our customers, GitLab team members are required to complete Data Classification Training as part of GitLab’s Security Awareness Training to help understand the different types of data at GitLab and how to keep it SAFE. Training is available via Level Up, GitLab’s internal learning platform.

Customer Responsibilities

• GitLab customers are responsible for managing their own data, to include identification and classification according to their own internal requirements. GitLab handles Customer Data internally according to our non-disclosure obligations written in our Mutual Non Disclosure Agreement and the classifications identified in this standard.

Standard

Data Classification Definitions

• Personal Data: Any data, individually or when combined with other data, that identifies, relates to, describes or is reasonably capable of being associated with or linked to an identifiable natural person (a ‘data subject’), whether directly or indirectly.

• Customer Data: Refers to the electronic data, originating from the GitLab platform and supporting infrastructure, that was uploaded/created/generated by GitLab customers and processed in the GitLab application with a label of Private, Confidential, or Internal by the customer and subject to legal or contractual obligations.

Data Classification Levels

Examples of each data type: See Data Classification Index (internal only)

RED

Restricted and must remain confidential. This is GitLab’s most sensitive data and access to it should be considered privileged and must be explicitly approved. Exposure of this data to unauthorized parties could cause extreme loss to GitLab and/or its customers. In the gravest scenario, exposure of this data could trigger or cause a business extinction event.

Examples include:

• Customer Data (see definition above in the Data Classification Definitions section)

Red Data may not be transmitted from an approved Red data source to any other systems or solutions without first obtaining approval from the Privacy and Security teams. Any Vendors that process Red Data must first undergo a factual and legal analysis that justifies their processing in accordance with our Customer agreements, as well as global privacy and data security laws. For any questions or concerns related to the transmission of Red data between systems, please reach out to @Security-Risk within the #Sec-Assurance channel.

ORANGE

Data subject to laws and regulation that should not be made generally available. Unauthorized access or disclosure could cause significant or financial material loss, risk of harm to GitLab if exposed to unauthorized parties, break contractual obligations, and/or adversely impact GitLab, its partners, employees, contractors, and customers.

Examples include:

• Personal Data
  • Any vendor who is in possession of any form of Personal Data must have appropriate contractual terms that address GitLab data protection requirements (e.g. a Data Processing Agreement).
  • If Personal Data comprises a part of the data set to be processed, then the data classification for that data set should be Orange and the classification cannot be Yellow or Green, even if the majority of the data set is Yellow or Green data.
  • The source of the Personal Data should not change its classification to a level below Orange since Personal data gathered from public sources is not exempt from protection under certain data protection laws.
  • If you have doubts as to whether something is Personal Data, please see an exhaustive list of Personal Data elements in the Data Classification Index (internal only)
• GitLab Intellectual property
• Customer metadata
• Audit logs
• Open security incidents, vulnerabilities and risks

YELLOW

Data and information that should not be made publicly available that is created and used in the normal course of business. Unauthorized access or disclosure could cause minimal risk or harm and/or adversely impact GitLab, its partners, employees, contractors, and customers.

Examples include:

• Asset registers
• General internal company communications
• Vendor contracts
• GitLab runbooks/work instructions/manuals/policies/procedures containing data NOT appropriate for public consumption
• GitLab Team Member names

GREEN

Data that is publicly shareable, and does not expose GitLab or its customers to any harm or material impact.

Examples include:

• GitLab handbook
  • Including most GitLab runbooks/work instructions/manuals/policies/procedures
• Public announcements
• Public product information

Data Classification Standards

Credentials and access tokens are classified at the same level as the data they protect

Credentials such as passwords, personal access tokens, encryption keys, and session cookies derive their classification from the highest classification of the data they protect.

Combinations of data types may result in a higher system classification level

If there is more than one data type residing in a system, the system should be classified at the highest data classification level of the data being stored, transmitted or processed on that system.

Labeling

There is currently no internal requirement to label data according to this standard, however labels are encouraged. By labeling data according to classification level, individuals can quickly refer to this policy for proper handling.

Exceptions

Exceptions to this policy will be tracked as per the Information Security Policy Exception Management Process.

References

• Controlled Document Procedure
• Data Classification Index (internal only)

View page source - Edit this page - please contribute.