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.
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 System 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. |
BIAs are performed once per fiscal year for each system listed on GitLab's Tech Stack. The Security Risk Team is responsible for the periodic review and reconciliation of systems which require a BIA year over year. Additionally, the BIA is also integrated with GitLab's process for adding net-new systems to the tech stack to ensure that BIA data is captured at the time that new systems have been implemented/onboarded to the organization. The steps listed below summarize how BIAs are completed.
A formal BIA questionnaire is distributed to the technical system owners for each system, as listed in the tech stack. If there are multiple individuals listed, one team member will be selected. The questionnaire will be sent to the team member's GitLab email directly from GitLab's GRC Application, ZenGRC. Additional information on completing this questionnaire can be found on the ZenGRC Activities handbook page. More info on the questionnaire is available in the video below.
Once all responses have been received, the data will be sanitized and aggregated. Follow-ups with technical owners will be completed as required to ensure the data used is accurate, complete, and objective.
Mission critical systems are identified and next steps are taken to ensure that a system recovery/business continuity plan is documented accordingly.
On a periodic basis, the BIA is reviewed and will be reperformed. While we do not anticipate significant changes year over year, as part of our due diligence and compliance needs, the Security Risk Team ensures that the data obtained from BIA questionnaires does not become stale through periodic review and reperformance.
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.