Critical System Tiering Methodology
This is a Controlled Document
In line with GitLab’s regulatory obligations, changes to controlled documents must be approved or merged by a code owner. All contributions are welcome and encouraged.Purpose
The purpose of the Critical System Tiering Methodology is to support GitLab in categorizing systems based on their impact on GitLab’s SaaS subscriptions (delivery of GitLab.com or GitLab Dedicated). By classifying systems into specific tiers, GitLab may appropriately prioritize risk mitigation activities and tailor internal controls.
Scope
The Critical System Tiering methodology is applicable to all systems utilized across GitLab which are tracked within the Tech Stack.
Roles and Responsibilities
| Role | Responsibility |
|---|---|
| Security Risk Team | Owns the Critical System Tiering Methodology and designates Critical System Tiers for new systems through the Business Impact Analysis. |
| IT Compliance | Supports defining of Critical System Tiers in conjunction with the Security Risk Team when new systems are added to the Tech Stack. |
| Business/Technical Owners of Systems | Provide complete and accurate data about the systems that they own so that an accurate tier is designated. |
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. GitLab’s Business Impact Analysis (BIA) procedure enables the designation of a Critical System Tier for a new system by the Security Risk Team. The BIA questions used to designate Critical System Tier are:
- What is the impact of System disruption (System is unavailable)?
- Please describe the potential impact of System disruption. Specify any GitLab team(s) affected.
The Security Risk Team judgmentally designates a Critical System Tier for the new system based on answers from the Business Owner and their own understanding of the services provided by the system. The guidelines used to distinguish each tier are described in the next section.
Designating Critical System Tiers
Systems are designated a Critical System Tier based on the following matrix:
| Critical System Tier (CST) * | CST Description | Examples |
| Tier 1 Mission Critical** | Disruption or breach has an immediate and significant impact on the availability/security of GitLab SaaS subscriptions and Customer data (See Data Classification Standard for definitions). | GitLab.com, Google Cloud Platform, Devo |
| Tier 2 Business Critical*** | Disruption affects execution of major business functions or capabilities. | Okta, Salesforce, Workday |
| Tier 3 Business Operational | Disruption affects efficiency or cost in completing standard business processes. | DocuSign, Figma, Tableau |
| Tier 4 Administrative | Disruption affects productivity/well-being of individual GitLab Team Members. | Clockwise, Donut |
Note: * 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.
Note: ** 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.
Note: *** By default, any system in-scope for SOX will be a Tier 2 Business Critical system, at minimum.
Critical System Tiers help prioritize risk mitigation activities for systems critical to serving GitLab’s Customers. GitLab’s core service offerings are SaaS. Thus, the systems that have an immediate and significant impact on the availability/security of GitLab SaaS subscriptions and Customer data in the event of a disruption are priority. These are Tier 1 Mission Critical systems.
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). For example, if multiple risks have been identified across many systems and require remediation, team members can leverage the designated Critical System Tiers to make decisions on how to prioritize remediation efforts. This methodology also provides GitLab with a mechanism to easily identify systems which are most critical across the organization so that teams can proactively protect and secure those systems.
Maintaining Critical System Tiers
Critical System Tiers for existing systems are validated periodically. A system’s designated tier can be found in the tech_stack.yml file which is the Single Source of Truth for all systems used at GitLab.
References
d8295282)
