Incident Response Guidance

This guidance will provide all in scope individuals the information they need to help GitLab ensure incidents are reported, investigated and handled.

This is a Controlled Document

In line with GitLab’s regulatory obligations, changes to controlled documents must be approved or merged by a code owner. All contributions are welcome and encouraged.

To provide guidance and insight into our incident response process. Incident response is a key aspect of GitLab’s overall security program. This guidance will provide all in scope individuals the information they need to help GitLab ensure incidents are reported, investigated and handled in such a way that minimize security events or data loss.

Definition

The definition of an incident is the first step in determining how to report an incident.

Security Team Incident: Any violation, or threat of violation, of GitLab security, acceptable use or other relevant policies.
Infrastructure Team Incident: Anomalous conditions that result in, or may lead to, service degradation or outages.

Scope

This guidance is meant to support all GitLab team members, contractors, advisors, contracted parties interacting with GitLab, customers, individual contributors or any external entity that has a need to report an identified or suspected incident.

Workflows

Incidents at GitLab are separated into two workflows depending on the type of incident reported. This guidance provides links to the associated handbook pages that define specific actions or processes from either our Security Team or our Infrastructure Team. Actions from either of these processes are meant to minimize the impact, operationally or financially, of critical business operations.

Process

1. Identification

A. If you are able to determine the type of incident that has been suspected or identified, report your incident to either Security or Infrastructure.

Note: GitLab takes any and all incidents seriously. If you are uncertain who to report an incident to, please report your incident using the support web form and your incident report will be internally forwarded accordingly.

2. Reporting Incidents

A. Security:

Internally or externally through various pathways
Internally only via Slack or Email

B. Infrastructure:

Externally through the support web form. Incident response times are based on your SLA
Internally via on-call

3. Coordination

A. Security:

The Application Security Team uses the triage rotation to coordinate and respond to security incidents.

B. Infrastructure:

The Reliability Team Engineer on Call is the first person alerted and is generally a Site Reliability Engineer (SRE) that is responsible for coordination and response to infrastructure related incidents.