The purpose of the Critical Systems Tiering Methodology is to support GitLab in categorizing systems based on their effect on GitLab's SaaS subscriptions and the achievement of Gitlab's mission and strategy. Ultimately, this provides GitLab with a mechanism to take a proactive approach to comprehensive risk management which considers risks, such as information security and privacy risks, impacting business operations across the organization. Additionally, by classifying systems into specific tiers, GitLab will be in a better position to appropriately prioritize risk mitigation activities and tailor internal controls based on a system's related tier.
The critical systems tiering methodology is applicable to all systems utilized across GitLab which are tracked within the Tech Stack to ensure that all systems are vetted completely and accurately using a consistent and standardized methodology.
| Role | Responsibility |
|---|---|
| Security Risk Team | Executes an annual review of critical system tiers and makes adjustments as necessary. Owns the Critical System Tiering Methodology and supports the identification of and assignment of a critical system tier as needed. |
| IT Compliance | Supports defining of critical system tier in conjunction with the Security Risk Team when new systems are added to the tech stack. |
| Business and Technical Owners of Systems | Provide complete and accurate data about the systems that they own so that an accurate tier is assigned. |
Defining what a critical system means at GitLab can be complex given the nature of our environment and the number of integrations that exist across the many systems that are used to carry out business activities. As part of Gitlab's Business Impact Analysis (BIA) process, we obtain inputs that enable the assignment of a critical system tier per system. The inputs used to determine system criticality tiers include, but are not limited to, the following:
Once the information is obtained, it is reviewed by the Security Risk and/or IT Compliance Team to determine which system tier should be assigned to the system. The guidelines used to assign a tier are described in the Determining Critical System Tiers section below.
Why do we differentiate between impact to the SaaS subscriptions vs Critical internal business operations?
Critical system tiers are meant to be leveraged as a driver for prioritizing work that impacts a large number of systems. Utilizing the system tiers provide a meaningful mechanism to prioritize work for systems which are essential to GitLab and its customers. Furthermore, because the core service offering is GitLab.com, systems which have an impact on GitLab's ability to maintain/sustain the continued delivery of GitLab.com are given their own dedicated tier, Tier 1 Mission Critical, because of potential impact to all SaaS subscription customers.
Systems are assigned a critical system tier based on the following matrix:
| Critical System Tier (CST) * | CST Description | Example | Previous CST Tier Mapping |
| Tier 1 Mission Critical** | Disruption or breach has an immediate and significant impact to the availability/security of GitLab subscriptions and [customer data](https://about.gitlab.com/handbook/security/data-classification-standard.html#data-classification-definitions). | Cloudflare, GitLab.com, Teleport | Tier 1 Product |
| Tier 2 Business Critical*** | Disruption has an immediate and significant impact to critical business functions and customer service. | customers.gitlab.com/subscription, NetSuite, Salesforce | Tier 1 Business and Tier 2 Core |
| Tier 3 Business Operational | Disruption affects operational business functions, negatively impacting efficiency/cost of operation across departments | Clearwater, PagerDuty, ZenGRC | Combination of Tier 2 Support and Tier 3 Non-critical and influenced by responses to BIA |
| Tier 4 Administrative | Affects GitLab team members only at an individual level (e.g., quality of life, individual productivity) | Donut, JetBrains, LinkedIn Learning, Modern Health | Combination of Tier 2 Support and Tier 3 Non-critical and influenced by responses to BIA |
Notes
* As an extension of tiering methodology, the Data Classification Standard prescribes specific Security and Privacy control requirements for each data classification level. These requirements should be followed based on a system's data classification, regardless of the system's tier.
** By default, any system that contains RED Data per the Data Classification Standard OR is a Third Party Sub-Processor will be a Tier 1 Mission Critical system. This is due to the fact that this data is customer owned and uploaded and as such, has been deemed to be mission critical in nature.
*** By default, any system in-scope for SOX will be a Tier 2 Business Critical system, at minimum.
Tiering systems utilized across GitLab enables team members to make decisions on prioritizing work related to a specific system(s) based on the assigned tier. As an example, if multiple risks have been identified over a wide variety of systems and require remediation, impacted team members can leverage the assigned critical system tiers to make a decision on how to prioritize remediation activities. This methodology will also provide GitLab with a mechanism to easily identify those systems which are most critical across the organization so that we can proactively protect and secure those systems.
The Critical System Tier for existing systems is re-evaluated as part of the periodic BIA process. A system's assigned tier can be found in the tech_stack.yml file which is the Single Source of Truth for all systems used at GitLab.
Systems that are exempt from this methodology include any system which carries a data classification of Green. All remaining systems which store or process YELLOW, ORANGE, or RED data are required to have a critical system tier assigned. Data classification will be validated to corroborate that the data stored or processed by the system is truly Green data, per the Data Classification Standard.
