Add template link for release policy exceptions

If an exception is believed necessary:

1. **Requestor** documents the business justification and customer impact assessment

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:

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

To request a backport exception:

1. Raise a [backport request](https://gitlab.com/gitlab-org/release/tasks/-/issues/new?issuable_template=Backporting-request)

1. Raise a [backport request](https://gitlab.com/gitlab-org/release/tasks/-/work_items/new?description_template=Exception-request)

1. Further instructions are located in this template.

1. Release Managers execute only after receiving written approval

1. Communicate to your stakeholders if/when the release is available on our [releases blog](https://about.gitlab.com/releases/categories/releases/)

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

   - For critical security vulnerability, 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. 

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

  **NOTE** - If the out-of-band patch 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.

  **NOTE** - If the out-of-band patch 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", be S1 or S2 given the need for an out-of-band patch, and have a Contributing Factor ('Inadequate testing or QA' or 'Miscommunication or coordination gap') describing the root cause that stemmed the 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](/handbook/engineering/#feature-change-locks) is mandatory.

## Patch release process