Extend exception request to security OOB patches

1. [**Requestor** documents](https://gitlab.com/gitlab-org/release/tasks/-/work_items/new?issuable_template=Exception-request) the business justification and customer impact assessment

2. **Requestor** starts a [Feature Change Lock (FCL)](/handbook/engineering/#feature-change-locks) to protect platform stability (**mandatory**)

3. **Requestor** escalates to their Director/VP for sponsorship. The approving leader provides written approval acknowledgment of policy violation

4. **Sponsoring Director/VP** requests exception from Engineering leadership within the Delivery/Platforms organization:

   * **Backport exceptions (N-3+)**: Senior Engineering Manager or above

   * **Out-of-band releases**: Director of Infrastructure (Delivery Enablement) or above

   * **Policy violations (features in patches, monthly redos)**: VP of Engineering, Infrastructure Platforms or above

3. **Requestor** escalates to VP of your organization for sponsorship. The approving leader provides written approval acknowledgment of policy violation

4. **Sponsor VP** requests exception from [Software Delivery Engineering Leadership](/handbook/engineering/infrastructure-platforms/gitlab-delivery/delivery/#software-delivery-engineering-leadership) or Infrastructure VP Platform.

5. **Release Manager** executes only after receiving written approval

6. **Post-release:** [Incident review](/handbook/engineering/infrastructure-platforms/incident-review/) to address the root cause of the exception request (**mandatory**)

### SLO Commitments

Planned patch releases are scheduled to meet target release dates without requiring emergency releases.

Scheduled patch releases are designed to meet target release dates without requiring emergency releases.

- For detailed security vulnerability remediation SLAs, see [Security Remediation SLAs](/handbook/security/product-security/vulnerability-management/sla/).

- For detailed bug vulnerability remediation SLAs, see [Bug Remediation SLAs](/handbook/product-development/how-we-work/issue-triage/#severity-slos).

## Patch release types

Patch releases have multiple touchpoints between many teams to prepare, validate and publish packages containing bug and vulnerability fixes.

At GitLab, there are two types of patch releases processes:

1. **Scheduled (default)**: An SLO-driven patch to publish all available bug and vulnerability fixes per

   the Wednesday before and after the [monthly release week](/handbook/engineering/releases/monthly-releases/#monthly-release-schedule), planned patches comply

   with the [bug SLO](/handbook/product-development/how-we-work/issue-triage/#severity-slos) and

   the [security remediation SLAs](/handbook/security/product-security/vulnerability-management/sla/). Patches that include

   [`critical` vulnerabilities](/handbook/security/product-security/vulnerability-management/sla/) will be considered critical patches.

2. **Out-of-band**: A patch outside of the regular [patch release cadence](#patch-release-cadence)

reserved strictly for mitigating a high-severity bug or critical vulnerability. These ad-hoc patches

arise exclusively from a declared [incident](/handbook/engineering/infrastructure-platforms/incident-management/#reporting-an-incident)

and must never be used to accommodate missed deadlines or bypass standard release policy.

   [`critical` vulnerabilities](/handbook/security/product-security/vulnerability-management/sla/) are considered critical patches.

1. **Out-of-band**: A patch outside of the regular [patch release cadence](#patch-release-cadence)

   reserved strictly for mitigating a high-severity bug or critical vulnerability. These ad-hoc

   patches must never be used to accommodate missed deadlines or bypass standard release policy.

   Following the patch release cadence, out-of-band patches are delivered on Wednesdays.

   - For **Critical security vulnerabilities** - A [security RCA](/handbook/security/root-cause-analysis/)

   is **required** and must be completed by the team responsible for introducing the vulnerability

   that forced the out-of-band release. There are no exceptions to this accountability.

   All out-of-band patches, whether for bug fixes or security vulnerabilities, must satisfy the

   following:

   - For **Bug fixes** - An [exception process](/handbook/engineering/releases#exception-process)

   - **Exception process**: An [exception request](/handbook/engineering/releases#exception-process)

     is **mandatory** and must be followed before any out-of-band patch is executed. Release Managers

     are authorized to decline requests that have not completed this process, regardless of business

   pressure. An [incident must be declared](/handbook/engineering/infrastructure-platforms/incident-management/#reporting-an-incident)

     pressure.

   - **Incident declaration**: An [incident must be declared](/handbook/engineering/infrastructure-platforms/incident-management/#reporting-an-incident)

     with the following attributes:

     - Marked as "Out-of-Band Patch"

     - Severity S1 or S2

     - A Contributing Factor of 'Inadequate testing or QA' or 'Miscommunication or coordination gap'

   - **FCL and incident review**: To uphold the reliability and availability of any GitLab platform,

     completing an [incident review](/handbook/engineering/infrastructure-platforms/incident-review/)

     and an [FCL](/handbook/engineering/#feature-change-locks) is **mandatory**.

      For bug fixes to uphold the reliability and availability of any GitLab platform, **completing an

      [incident review](/handbook/engineering/infrastructure-platforms/incident-review/) and an

      [FCL](/handbook/engineering/#feature-change-locks) is mandatory**.

   Additionally, for **critical security vulnerabilities**, a [security RCA](/handbook/security/root-cause-analysis/)

   is **required** and must be completed by the team responsible for introducing the vulnerability that forced the

   out-of-band release. There are no exceptions to this accountability.

## Patch release process

The process for a patch release is the same for all types with one important distinction: planned patches include all bug and security fixes ready at the time

of the patch release preparation, while unplanned patches will likely only include the security fix for high-severity vulnerability.

The process for a patch release is the same for all types with one important distinction: scheduled patches include all bug and security fixes ready at the time

of the patch release preparation, while out-of-band patches will likely only include the fix for high-severity bug or critical vulnerability.

The end-to-end patch release process consists of the following stages: