This is a Controlled Document
Inline with GitLab's regulatory obligations, changes to controlled documents must be approved or merged by a code owner. All contributions are welcome and encouraged.
The Business Impact Analysis (BIA) is developed as part of the Business Continuity Plan process and is a point-in-time analysis of system components that determines the criticality and potential impact to GitLab's mission-critical processes and data as well as impact to GitLab should the system component become unavailable. This quantitative analysis allows GitLab to establish priority levels for sequencing recovery activities and resources.
The purpose of the BIA is to identify and prioritize system components by correlating them to mission critical processes that support ongoing business operations and the GitLab product. Using this information to characterize what would be the impact to GitLab, if any of these systems were to be unavailable. This is considered a bottom-up approach to risk management which is complementary to the top-down approach of the Annual Risk Assessment.
The scope of the BIA is the entirety of systems utilized across GitLab as documented in the Tech Stack.
| Role | Responsibility |
|---|---|
| Security Risk Team | Responsible for implementing and executing this procedure annually. For new systems that have not previously undergone a BIA, a holistic one will be performed. All other systems that have gone through an initial BIA will undergo a targeted BIA process to validate and obtain the most up-to-date data related about it's use at GitLab. |
| IT Compliance | Utilizes the data obtained from the BIA to drive Business Continuity Planning activities. |
| Technical Owners | Completion of annual BIA (with additional support from Business Owner or delegation to another team member, as applicable) |
| Security Assurance Management (Code Owners) | Responsible for approving significant changes and exceptions to this procedure. |
A BIA is initiated as the result of GitLab's process for adding net-new systems to the Tech Stack to ensure that BIA data is captured at the time of new system implementation. The steps listed below summarize how BIAs are completed for new systems:
Additional information on completing a questionnaire (recipient's perspective) can be found on the ZenGRC Activities handbook page. More info on the questionnaire is available in the video below.
Security Risk should use discretion when actioning these steps (e.g. consider progress made in completing Tech Stack MR/BIA Questionnaire).
A BIA is performed or existing BIA data are validated once per fiscal year for each Tier 1 system listed on GitLab's Tech Stack. BIA data for Tier 2 and 3 systems will be refreshed or validated every 2 years. BIA data for existing Tier 4 systems will not be periodically refreshed or validated due to the low risk they represent to GitLab. In addition to BIA data/response validation, additional questions may be incorporated for the Technical Owner to answer (e.g., questions regarding Technical Debt). The Security Risk Team is responsible for the periodic review and reconciliation of systems which require a BIA year over year. System BIAs will be performed in waves and prioritized by Tier and regulatory need.
The results of the questionnaire will be imported into the relevant System Object within GitLab's GRC system to support on-going maintenance, quality/areas of concern reviews, and reporting. Any material change to the Technical Owner's questionnaire response will be accompanied by a communication/acknowledgement to/from the Technical Owner via comment within GRC system, Slack communication, or within GitLab issue. If leveraging Slack, please attach a screenshot of communication to the System Object within the GRC system. The Security Risk team will review the responses to the BIA questionnaires to support completeness and accuracy of the information. Quality checks will include:
Data Classification field with the Data Collected field to ensure alignment. If changes to the Technical Owner's response are required, perform the update with the relevant GRC System Object and communicate the changes to the Technical Owner for acknowledgement.Data Classification field with the Data Classification field in the Tech Stack. If there is a difference, work with the Technical Owner to update the Tech Stack accordingly.As BIA response values are reviewed within System Objects, labels will be applied in the GRC application indicating the fiscal year they were reviewed (e.g., FY24 BIA QR Complete).
We include some questions in our questionnaire that may lead to the creation of Tier 3 Observations. The Security Risk team will review BIA questionnaire responses to identify potential risks to GitLab. Responses that may result in Tier 3 Observations are listed below:
Shared Administrative Accounts = YesSystem Specific Recovery Plans = Insufficient detail in responseAuthentication Mechanism ≠ OktaNumber of Administrators of the system < 2The Security Risk team will follow the observation intake and management process described here for ad-hoc observations.
The data obtained from BIA questionnaires results in:
BIA results are reported via updates to GitLab's Tech Stack. Specific attributes like data_classification and critical_systems_tier are updated accordingly for each system's record should the information from the BIA lead to changes to data classification and/or assignment of a new critical system tier.
There are no systems that are exempt from the BIA procedures. Note that GitLab may procure new systems throughout an annual period. While the Security Risk Team will work towards performing a BIA for new systems in a timely manner, systems may periodically not have a BIA performed until the next annual BIA.