GitLab performs business continuity and disaster recovery tests annually and ensures the following:
Tests are executed with relevant contingency teams.
Test results are documented.
Corrective actions are taken for exceptions noted.
Plans are updated based on results.
Context
The business continuity plan is only useful if it is both maintained and validated. The testing part of this process is meant to be that validation and determines the efficacy of the plan. The purpose of this control is to determine if the business continuity plan would work in the event of a disruption to normal GitLab operations. The business continuity test must have these three main categories:
Recovery Planning: Ensuring that Recovery processes and procedures are executed and maintained to timely restoration of systems or assets affected by any disruptive event.
Improvements: Recovery planning and processes are improved by incorporating lessons learned into future activities.
Communications: Restoration activities are coordinated with internal and external parties: such as coordinating centers, Internet Service Providers, system owners, victims and vendors.
Scope
This control is a subset of the Business Continuity control. It defines that, a Business Continuity Plan (BCP) must be tested and updated on a regular basis to ensure its effectiveness in the event of a disaster and its continuing relevance to the Business. The process should include the testing of data recovery, information asset management, leadership response and recovery procedures. A process to do a full simulation of these, at least once each year with different, realistic scenarios that test the effectiveness of GitLab's Business Continuity plan should be the goal.
All parts of the business continuity plan should be tested. All teams and services that have a documented business continuity plan should have a corresponding documented test.
Ownership
Business Operations owns this control.
Infrastructure will provide implementation support for .com
Guidance
Tabletop exercises would be a reasonable way to test yearly
But a full simulation should take place at least biennially for each team and service
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 Continuity Testing control issue.
