Business Impact Analysis

Purpose

The Business Impact Analysis (BIA) helps determine the systems critical to serving GitLab’s Customers. It also helps determine the prioritization of system restoration efforts in the event of a disruption.

A BIA is performed for a system by completing a questionnaire. Each question in the BIA Questionnaire belongs to one of three data collection categories:

1. Critical System Tier (questions that guide how a system is tiered)
2. Supplemental Information (questions that prompt important system details)
3. Security Best Practices (questions that reveal potential Information System risks)

System data obtained through the BIA may be referenced for Business Continuity planning and testing.

Note: Additionally, a subset of questions may be included in the BIA Questionnaire to satisfy global privacy legislation requirements pertaining to a system’s Personal Data processing.

Scope

The BIA covers all systems in GitLab’s Tech Stack. However, the volume and frequency of the BIA is based on Critical System Tiering. See the ‘BIA Procedures’ section for more details.

Roles and Responsibilities

BIA Procedures

New Systems (Ad-Hoc)

A BIA is initiated as the result of TPRM’s process for net new systems (guided by our report template). An associated Tracking Issue is created by the TPRM engineer to ensure that the new system has a BIA performed and is added to the Tech Stack. The steps listed below summarize how BIAs are performed for new systems:

1. A formal BIA questionnaire is distributed to the Business/Technical Owner for each system, as listed in the Tech Stack or Merge Request related to adding the system to the Tech Stack. Launch a new BIA Questionnaire from GitLab’s GRC Application, ZenGRC, by following these steps:
   1. Click ‘System of Record’ > ‘Projects’ > ‘Business Impact Analysis - New Systems’ Project (Select correct Fiscal Year)
   2. Click the 3 dots on the top right-hand corner > ‘Send New Questionnaire’
   3. Search for and select the ‘Business Impact Analysis (BIA)’ questionnaire template
   4. Populate the Recipient Details section. The Recipient is “Internal” (input name/GitLab email of one Business/Technical Owner only).
   5. Search for and select the ‘BIA Questionnaire (New System)’ email template
   6. Update the Title/Subject, Greeting, Message body, CC and Reply-To @securityrisk@gitlab.com, and Due Date accordingly. Target completion of the BIA Questionnaire is two weeks.
   7. Click ‘Review’ > ‘Submit’ when ready
   8. Map the appropriate System Object to the BIA Questionnaire by clicking the pencil icon in the ‘map:system’ column.

Escalation Path

Security Risk should use discretion when actioning these steps (e.g. consider progress made in completing Tech Stack MR/BIA Questionnaire). Most tech stack / BIA issues are due two weeks from creation.

1. Due Date +1 Business Day: Notify Business/Technical Owner or Delegate in a public Slack channel (e.g. #sec-assurance).
2. Due Date +5 Business Days: Notify Manager of Business/Technical Owner or Delegate in a public Slack channel (e.g. #sec-assurance).
3. Due Date +10 Business Days: Notify SecRisk Manager and consider issuing Risk Acceptance by following the TPRM Risk Acceptance Process.

Existing Systems (Frequency based on Critical System Tier)

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 Business/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.

Quality Reviews

The Security Risk team will review the responses to the BIA questionnaires to support completeness and accuracy of the information based on the TPRM assessment performed for the system.

For blank/unknown/obscure responses, engage the Business/Technical Owner via comment functionality within the GRC system, Slack, or a GitLab issue.

Responses that may result in Tier 3 Observations/Risks

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 = Yes
• System Specific Recovery Plans = Insufficient detail in response
• Authentication Mechanism ≠ Okta
• Number of Administrators of the system < 2

The Security Risk team will follow the observation intake and management process described here for ad-hoc observations.

Reporting

BIA results are reported via updates to GitLab’s Tech Stack. Specific fields like critical_systems_tier and collected_data are updated accordingly at a system-level should the information from the BIA lead to changes.

Exceptions

System Proof of Concepts (POC), Proof of Values (POV), and Pilots are exempt from BIA procedures. In the event Tier 1, Tier 2, or Tier 3 systems are added by actors other than Security Risk, these systems will be reviewed as part of the next periodic BIA.

References

• Critical System Tiering Methodology
• Data Classification Standard
• Business Continuity Plan