diff --git a/doc/development/deprecation_guidelines/_index.md b/doc/development/deprecation_guidelines/_index.md
index f3f0a812c17b6902da0ab237b8e36a5b9631b702..f4b6b7d4456aa69cd595dc72631249d0f36b6980 100644
--- a/doc/development/deprecation_guidelines/_index.md
+++ b/doc/development/deprecation_guidelines/_index.md
@@ -23,6 +23,16 @@ Product and Engineering Managers are responsible and accountable for customer im
 
 **We aim to eliminate all breaking changes from GitLab.** If you have exhausted the alternatives and believe you have a strong case for why a breaking change should be allowed, you can follow the process below to seek an exception.
 
+## When a deprecation approval and deprecation issue is not needed
+
+A breaking change exception is **not required** in the following cases:
+
+1. **Feature flag that was always disabled by default**: If the feature being removed was behind a feature flag that was always disabled by default, no exception process is needed. Customers who enabled such features did so at their own risk, as outlined in the [feature flag documentation](../../administration/feature_flags/_index.md).
+
+1. **Experimental GraphQL fields or mutations**: If a GraphQL field or mutation is marked as experimental, it can be removed without following the standard breaking change process.
+
+For all other cases, you must follow the breaking change exception process outlined below.
+
 ## How do I get approval to move forward with a breaking change?
 
 **By default, no breaking change is allowed unless the breaking change implementation plan has been granted explicit approval by following the process below.**