diff --git a/doc/user/project/merge_requests/authorization_for_merge_requests.md b/doc/user/project/merge_requests/authorization_for_merge_requests.md
index 1cfd66f5b2b433b49fe89c2925eb450885ce92d6..a1a77fb4d049a7940a367797bed94f7e2c1275a4 100644
--- a/doc/user/project/merge_requests/authorization_for_merge_requests.md
+++ b/doc/user/project/merge_requests/authorization_for_merge_requests.md
@@ -40,6 +40,31 @@ protected branch.
 
 - Manual setup of protected branch required for each new project
 
+To set up a protected branch flow:
+
+1. Start with ensuring that your default branch is protected with [default branch protections](../repository/branches/default.md).
+1. If your team has multiple branches, and you would like to manage who can merge changes and who
+   explicitly has the option to push or force push, consider making those branches protected:
+
+   - [Manage and Protect Branches](../repository/branches/index.md#manage-and-protect-branches)
+   - [Protected Branches](../protected_branches.md)
+
+1. Each change to the code comes through as a commit.
+   You can specify the format and security measures such as requiring SSH key signing for changes
+   coming into your code base with push rules:
+
+   - [Push Rules](../repository/push_rules.md)
+
+1. To ensure that the code is reviewed and checked by the right people in your team, use:
+
+   - [Code Owners](../codeowners/index.md)
+   - [Merge Request approval rules](approvals/rules.md)
+
+Also available in the Ultimate tier:
+
+- [Status checks](status_checks.md)
+- [Security Approvals](approvals/rules.md#security-approvals)
+
 ## Forking workflow
 
 With the forking workflow, maintainers get the Maintainer role and regular