Highlight FCL requirement on policy exceptions.

### Exception Process

> [!IMPORTANT]

> Every approved exception **requires** a [Feature Change Lock (FCL)](/handbook/engineering/#feature-change-locks) and a post-release [incident review](/handbook/engineering/infrastructure-platforms/incident-review/). **These are not optional**.

Exceptions to release policy are rare and require explicit approval outside the Release team.

**Release Managers are authorized to decline requests that violate release policies.** Pressure from Customer Success, Sales, or other teams does not constitute approval for policy exceptions.

If an exception is believed necessary:

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** escalates to their Director/VP for sponsorship. The approving leader provides written approval acknowledgment of policy violation

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

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

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

5. **Post-release:** [Incident review](/handbook/engineering/infrastructure-platforms/incident-review/) to address the root cause of the exception request and a [FCL](/handbook/engineering/#feature-change-locks) to protect platform stability. **These items are mandatory.**

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**)

Exceptions approved without this process set precedent that undermines all release policies.

## Internal Release Policy

> [!IMPORTANT]

> All internal releases **require** a declared [incident](/handbook/engineering/infrastructure-platforms/incident-management/#reporting-an-incident)

> and a post-release [incident review](/handbook/engineering/infrastructure-platforms/incident-review/). **These are not optional**.

>

> Internal releases addressing critical bug fixes **additionally require** a [Feature Change Lock (FCL)](/handbook/engineering/#feature-change-locks) driven

> by the engineering team of the affected area.

Internal releases adhere to the same policy requirements as [patch releases](/handbook/engineering/releases/patch-releases/#patch-release-policy): they are limited to critical bug fixes and security patches only.

Internal releases do not contain new features, feature flag changes, or incomplete work, nor may be used for testing purposes.

For the general release policy framework including ownership, exception process, and escalation paths, see the [Release Policy](/handbook/engineering/releases/#release-policy) section.

  If the internal release is not the result of a security incident, an [incident must be declared](/handbook/engineering/infrastructure-platforms/incident-management/#reporting-an-incident).  The incident should be marked "Planned Activity" and be S1 or S2 given the need for an out-of-band patch.  To uphold the reliability and availability of the GitLab platform, completing an [incident review](/handbook/engineering/infrastructure-platforms/incident-review/) and an [FCL] is mandatory.

If the internal release is not the result of a security incident, an [incident must be declared](/handbook/engineering/infrastructure-platforms/incident-management/#reporting-an-incident).  The incident should be marked as "Out-of-band" and be S1 or S2 given the need for an internal release.

## Internal release overview

and 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.

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

   - 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 unplanned release. There are no exceptions to this accountability.

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

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

   - For **Bug fixes** - An [exception process](/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. Since bug-driven out-of-band patches are not the result of a security incident, an

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

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

   with the following attributes:

      - Marked as "Out-ofBand Patch"

      - Marked as "Out-of-Band Patch"

      - Severity S1 or S2

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

      To uphold the reliability and availability of the GitLab platform, completing an

      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.

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

## Patch release process