Commit 2334f0fb authored by Usha Swaminathan's avatar Usha Swaminathan
Browse files

Update BC.1.01_business_continuity_plan.html.md

parent bca7cd10
Pipeline #81696742 passed with stages
in 29 minutes and 21 seconds
......@@ -2,56 +2,68 @@
layout: markdown_page
title: "BC.1.01 - Business Continuity Plan Control Guidance"
---
## On this page
{:.no_toc}
- TOC
{:toc}
# BC.1.01 - Business Continuity Plan
## Control Statement
GitLab's business contingency plan is reviewed, approved by management and communicated to relevant team members biannually.
GitLab's business continuity plan is reviewed, approved by management and communicated to relevant team members biannually.
## Context
The review cycle for business continuity plans are designed to ensure all information in the plan is as up-to-date as possible. A business continuity plan is only effective if users can trust the accuracy of the information in the plan. The business continuity plan is meant to be a comprehensive runbook that can walk all GitLab team-members through exactly what their individual responsibilities are in the event of a disruption to GitLab operations. This triggering event can be anything from a malicious breach of our systems to a global datacenter disruption.
The review cycle for business continuity plans are designed to ensure all information in the plan is as up-to-date as possible. A business continuity plan is only effective if users can trust the accuracy of the information in the plan. The business continuity plan is meant to be a comprehensive runbook that can walk all GitLab team-members through exactly what their individual responsibilities are, in the event of a disruption to GitLab operations. This triggering event can be anything from a malicious breach of our systems to a global datacenter disruption.
## Scope
The business continuity plan is comprehensive by nature and will impact all GitLab stakeholders.
The scope of a Business Continuity Plan can be categorized into the following seven steps:
The business continuity plan is comprehensive by nature and will impact all GitLab stakeholders. The scope of a Business Continuity Plan can be categorized into the following seven steps:
* Identify the critical business functions
* Identify the critical systems & its dependencies
* Identify the risks to business
* Specify and confirm the data backup and recovery plan are working efficiently.
* Clearly document the functions and procedures of the BC plan, who should lead the effort and who are all the players involved
* Specify and confirm the data backup and recovery plans are working efficiently.
* Clearly document the functions and procedures of the BC plan, who should lead the effort and who are all the players involved.
* Prepare a detailed communication plan
* Test, assess, learn and improve
## Ownership
* Business Operations owns this control.
* Infrastructure - will provide implementation support for .com.
## Implementation Guidance
For detailed implementation guidance relevant to GitLab team-members, refer to the [full guidance documentation](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/blob/master/controls/guidance/BC.1.01_business_continuity_plan.md).
## Reference Links
For all reference links relevant to this control, refer to the [full guidance documentation](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/blob/master/controls/guidance/BC.1.01_business_continuity_plan.md).
## Examples of evidence an auditor might request to satisfy this control
For examples of evidence an auditor might request, refer to the [full guidance documentation](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/blob/master/controls/guidance/BC.1.01_business_continuity_plan.md).
* Infrastructure will provide implementation support for .com.
## Guidance
The GitLab business continuity plan will have team and departmental pieces that roll up into a comprehensive plan. Each team knows best, as to what steps are needed in the event of a disruption to operations. Hence this overall plan is really more of a collection of individual plans and the packaging of these individual plans together. The plan should include the following:
* Business decided and approved, RTO (recovery time objective) and RPO (recovery point objective)
* This Plan has to be approved and signed off by senior management
* Documentation on critical business requirements, including backup plans, business contingency and other related needs and logistics surrounding these plans.
* High-level steps/procedures that addresses how to respond in the event of the most likely disaster scenarios.
* Once we have a high-level plan we can push this out to teams and have them create team-level plans.
* Ensure backups are running and include an additional full local backup on all servers and data as part of the BCDR plan and test this annually.
* Line of Communication and role assignments at each step. Document this list and make it readily available in times of need.
* Vendor communication and service restoration plan of action steps.
* Run a DR test annually, to ensure that the plan is working efficiently.
#### Reference Links
* [Business Continuity Plan in Handbook](https://about.gitlab.com/security/#business-continuity-plan)
* [Handbook listing of DR for Databases](https://about.gitlab.com/handbook/engineering/infrastructure/database/disaster_recovery.html)
* [GitLab Development Guides](https://docs.gitlab.com/ee/development/README.html#databases)
* [GitLab High Availability](https://about.gitlab.com/solutions/high-availability/)
* [Infra Epic for Geo](https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/1)
* [NIST Guidance on Business Continuity](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-34r1.pdf)
* [PCI DSS v3.2.1 - Business Continuity Plan](https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2-1.pdf?agreement=true&time=1551196697261#page=113)
#### Examples of evidence an auditor might request to satisfy this control
We will need some kind of reasonably comprehensive plan to show auditors that has sufficient detail to get GitLab's backup and restoreation in the event of a disruption, even if some GitLabbers are not able to participate in the process. This might actually be easier for us, as a fully remote company since a part of most business continuity plans involve what to do if certain offices are struck by outages or natural disasters.
## Additional control information and project tracking
Non-public information relating to this security control as well as links to the work associated with various phases of project work can be found in the [Business Continuity Plan issue](https://gitlab.com/gitlab-com/gl-security/compliance/compliance/issues/765) .
## Framework Mapping
* ISO
* A.17.1.1
* A.17.1.2
......@@ -62,3 +74,4 @@ For examples of evidence an auditor might request, refer to the [full guidance d
* A1.2
* PCI
* 12.10.1
\ No newline at end of file
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment