CM.1.04_emergency_changes.html.md 1.54 KB
Newer Older
1 2 3 4 5 6 7 8 9 10 11 12
---
layout: handbook-page-toc
title: "CM.1.04 - Emergency Changes"
---

## On this page
{:.no_toc .hidden-md .hidden-lg}

- TOC
{:toc .hidden-md .hidden-lg}

# CM.1.04 - Emergency Changes
13 14 15 16 17 18 19 20 21 22 23 24 25

## Control Statement

Emergency changes to the production environment follow the same change control workflow as standard changes. Approval can be retroactively applied depending on the urgency of the change.

## Context

Under certain conditions, like a zero-day vulnerability or out-of-band software patch, a change needs to escalated and applied outside of normal change management workflow and can potentially obtain approval after a change has been made.  This is done in the event a disruption or introduction of risk to business will occur.

## Scope

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.

Nik Sarosy's avatar
Nik Sarosy committed
26
* Control Owners: 
27 28
  * Infrastructure
* Process owner(s):
Nik Sarosy's avatar
Nik Sarosy committed
29
  * Infrastructure
30 31 32

## Additional control information and project tracking

Jeff Burrows's avatar
Jeff Burrows committed
33
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 [Emergency Changes control issue](https://gitlab.com/gitlab-com/gl-security/security-assurance/sec-compliance/compliance/-/issues/1692).
34 35 36 37 38 39 40 41 42 43

Examples of evidence an auditor might request to satisfy this control:



### Policy Reference

## Framework Mapping

* SOC2 CC
Nik Sarosy's avatar
Nik Sarosy committed
44
  * CC8.1