@@ -45,9 +45,19 @@ In the Data Platform at GitLab we have multiple categories. Its good to highligh
| Data Classification | The type and level of data. | Red, Orange, Yellow, Green. | Red data is not allowed to be stored in the Data Platform. Follow the [general data security controls](/handbook/enterprise-data/data-governance/data-management/#general-data-security-controls). | No particular controls in place. |
| MNPI | This is material non public information. | MNPI or not MNPI. | Follow the [SAFE Data guide](/handbook/enterprise-data/platform/safe-data/). | Access is granted by Permifrost. GitLab Team Members will become a designated insider. |
| Sensitive data | Data that is considered to be kept sensitive and not be shared with all GitLab Team members by default. | Sensitive or not Sensitive. | Sensitive data is [masked](/handbook/enterprise-data/platform/dbt-guide/#sensitive-data) via DBT | Access is granted by Permifrost. |
| Personal data | Sometimes also referenced as PII. Any data that describes or is reasonably capable of being associated with or linked to an identifiable natural person. Full description on the [security handbook page](/handbook/security/policies_and_standards/data-classification-standard/#data-classification-definitions). | Personal data or not personal data | Work with our Legal Privacy team to obtain approval for processing personal data | Depends on legal guidance. [Masking](/handbook/enterprise-data/platform/dbt-guide/#sensitive-data) could be used (static or dynamic) if needed. |
| Personal data | Sometimes also referenced as PII. Any data that describes or is reasonably capable of being associated with or linked to an identifiable natural person. Full description on the [security handbook page](/handbook/security/policies_and_standards/data-classification-standard/#data-classification-definitions). | Personal data or not personal data | Work with our Legal Privacy team to obtain approval for processing personal data | See [Personal Data Handling Section](/handbook/enterprise-data/data-governance/data-management/#personal-data-handling) |
| Sensitive Personal data | Data related to race/ethnicity, health or medical details, biometric or genetic data, religion, political affiliation or philosophy, sexual orientation, criminal offenses, citizenship/immigraion, or trade unions. | Sensitive personal data or not sensitive personal data | Privacy legislation prohibits the processing of these types of data elements, except in limited circumstances. Work with our Legal Privacy team to obtain approval for processing personal data and include People Operations, if sensitive Personal Data is related to GitLab Team Members | Depends on legal guidance. [Masking](/handbook/enterprise-data/platform/dbt-guide/#sensitive-data) could be used (static or dynamic) if needed. |
### Personal Data Handling
Personal data (PII) requires special handling across the Enterprise Data Platform. The following principles guide how we manage personal data:
***Data Minimization**: Do not include personal data in data products unless it is necessary for a specific business purpose.
***Dynamic Masking**: Always apply [dynamic masking policies](/handbook/enterprise-data/platform/dbt-guide/#sensitive-data) to personal data fields in the `PREP` and `PROD` layers of Snowflake.
***Unified Approach**: Handle all personal data (both GitLab Team Member data and external user/customer data) with the same highest sensitivity standards. Do not create distinctions between employee and external user PII, as this complicates compliance and implementation.
***Public Data Exception**: The following Team Member data elements don't require masking in isolation since they are effectively public: Team Member name, work email address, and GitLab username. However, when these elements are paired with other data (for example, Team Member name + location for event attendnace or username + MR response time), they become personal data and must be masked.
***Permission Alignment**: Access permissions for dynamically masked personal data should loosely mirror the permissions of the underlying data sources to the best extent possible. This means we will have masking roles per business function (for example, Marketing Personal Data, Sales Personal Data, PeopleTeam Personal Data) which team members can request access to via the regular Access Request process.
### General Data Security Controls
* For the purpose of defining Data Controls, the Enterprise Data Platform is a [Tier 1 system](/handbook/security/security-assurance/security-risk/storm-program/critical-systems/).
