GitLab defines availability monitoring alert criteria, how alert criteria will be flagged, and identifies authorized personnel for flagged system alerts.
In order for alerts to be configured for availability, we first have to establish what criteria we use for altering. This control simply formalizes the need for GitLab to explicitly define what criteria we use for availability alerting.
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.
InfrastructureThis control is not meant to dictate what criteria we use for our availability monitoring, only that we define what our alerting criteria is. Alerting criteria is stored in the gitlab-com/runbooks repository. This control can be tested by viewing the alerting criteria in the yml files which define the alerting critieria within the repository. To validate the history of an alerting criteria file, you can view each respective yml file's commit history. The files defining the alerting criteria contain all the information prescribed by this control, so validating the files are there and using the commit history to determine from when is sufficient to test this control.
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 Availability Monitoring Alert Criteria control issue.
Examples of evidence an auditor might request to satisfy this control:
