Incident Response Guidance is available in the Handbook that outlines GitLab's security incident response process. It also provides information to internal and external users on how to report breaches, security and availability failures, incidents, concerns, identified vulnerabilities and other security complaints to appropriate personnel.
The purpose of this control is to ensure GitLab creates, implements, and maintains an effective plan to identify, resolve, and prevent security incidents within its application, systems, and services. By having an organized and continually evolving security incident response plan, GitLab can maintain the availability, reliability, performance, and confidentiality offered to GitLab customers, GitLab team-members, and partners. This control can be tested by first proving that GitLab has sufficient documentation in place for an efficient Incident Response plan. This can include documentation pertaining to the handbook pages, Merge requests, and issues opened in reference to and in adherence to the IR plan. It can then be confirmed that any security incident that was reported (if applicable) followed the IR plan documentation.
This control applies to all systems within our production environment. The production environment includes all endpoints and cloud assets used in hosting GitLab.com and its subdomains. This may include third-party systems that support the business of GitLab.com.
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 Incident Response Plan control issue.
Examples of evidence an auditor might request to satisfy this control:
#incident-managementSlack channel is used for synchronous incident communication via chat
Production-watchapp monitors the aforementioned
productionproject and notifies channel participants of the issue
Situation Roompermanent Zoom channel is used for synchronous communication via audio/video conference