Critical System Tiering Methodology

Purpose

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.

Scope

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.

Roles and Responsibilities

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.

Critical System Tiering Procedure

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:

1. If the system experienced a disruption or outage, would there be an immediate impact to GitLab.com SaaS subscriptions?
2. If the system experienced a disruption or outage, which of the following would describe the impact to GitLab?
   • Critical business functions (i.e., indirectly affects revenue generation, requires constant availability for effective business operation)
   • Operational business functions (i.e., affects efficiency/cost of operation)
   • Administrative functions (i.e., affects GitLab team members only on an individual basis (e.g., quality of life, individual productivity))

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.

Determining Critical System Tiers

Systems are assigned a critical system tier based on the following matrix:

Critical System Tier (CST) *	CST Description	Examples	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 (See Data Classification Standard for definitions).	GitLab.com, Google Cloud Platform, Devo	Tier 1 Product
Tier 2 Business Critical***	Disruption has an immediate and significant impact to critical business functions and customer service.	Okta, Salesforce, Workday	Tier 1 Business and Tier 2 Core
Tier 3 Business Operational	Disruption affects operational business functions, negatively impacting efficiency/cost of operation across departments	DocuSign, Figma, Tableau	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)	Clockwise, Donut, LinkedIn Learning	Combination of Tier 2 Support and Tier 3 Non-critical and influenced by responses to BIA

Why does GitLab need this methodology?

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.

Maintaining Critical System Tiers

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.

Exceptions

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.

References

• Business Impact Analysis
• Data Classification Standard