Clarify backporting details

Co-Authored-By: Yorick Peterse <yorick@yorickpeterse.com>

doc/policy/maintenance.md

@@ -5,12 +5,16 @@ type: concepts
 # GitLab release and maintenance policy
 
 GitLab has strict policies governing version naming, as well as release pace for major, minor,
-patch, and security releases. New releases are usually announced on the [GitLab blog](https://about.gitlab.com/releases/categories/releases/).
+patch, and security releases. New releases are announced on the [GitLab blog](https://about.gitlab.com/releases/categories/releases/).
 
 Our current policy is:
 
 - Backporting bug fixes for **only the current stable release** at any given time. (See [patch releases](#patch-releases).)
-- Backporting **to the previous two monthly releases in addition to the current stable release**. (See [security releases](#security-releases).)
+- Backporting security fixes **to the previous two monthly releases in addition to the current stable release**. (See [security releases](#security-releases).)
+
+In rare cases, release managers may make an exception and backport to more than
+the last two monthly releases. See [Backporting to older
+releases](#backporting-to-older-releases) for more information.
 
 ## Versioning
 
@@ -177,7 +181,7 @@ accessible.
 
 ### Backporting to older releases
 
-Backporting to more than one stable release is reserved for [security releases](#security-releases).
+Backporting to more than one stable release is normally reserved for [security releases](#security-releases).
 In some cases, however, we may need to backport *a bug fix* to more than one stable
 release, depending on the severity of the bug.
 
@@ -188,16 +192,13 @@ based on *all* of the following:
 
 1. Estimated [severity](../development/contributing/issue_workflow.md#severity-labels) of the bug:
    Highest possible impact to users based on the current definition of severity.
-
 1. Estimated [priority](../development/contributing/issue_workflow.md#priority-labels) of the bug:
    Immediate impact on all impacted users based on the above estimated severity.
-
 1. Potentially incurring data loss and/or security breach.
-
 1. Potentially affecting one or more strategic accounts due to a proven inability by the user to upgrade to the current stable version.
 
 If *all* of the above are satisfied, the backport releases can be created for
-the current stable release, and two previous monthly releases.
+the current stable release, and two previous monthly releases. In rare cases a release manager may grant an exception to backport to more than two previous monthly releases.
 For instance, if we release `11.2.1` with a fix for a severe bug introduced in
 `11.0.0`, we could backport the fix to a new `11.0.x`, and `11.1.x` patch release.