You require multiple approvals by configuring merge request approval rules so at least two approved reviews are needed before merge. Set the rule at the group or project level, then verify it applies to protected branches and is not bypassed by maintainers or direct pushes. Also check who can approve, because self-approval and approval reset behaviour can affect enforcement.
How merge request approval rules enforce a second review
GitLab does not rely on a generic “review required” idea alone. Multiple approvals are enforced through merge request approval rules, which define how many approved reviews must exist before a merge can happen. The practical test is simple: the rule must be configured where GitLab will actually evaluate it, and it must apply to the branch and role model you use.
For teams that want a true two-person gate, the approval rule should be explicit rather than implied. That means setting the required approver count at the right scope, then confirming that merge permission still depends on the rule and not on informal team practice. If the policy only exists in documentation, it can be bypassed by a normal merge path.
GitLab merge request approval rules are part of broader code review control, so they work best when they are tied to branch protection and enforced consistently across the project. The CI/CD Security Guide covers the surrounding controls that make required reviews meaningful, including branch rulesets, runner isolation, and code review bypass prevention.
What must be true for the approval count to hold
The approval count is only as strong as the conditions around it. You need to confirm that the rule applies to protected branches, because an approval policy that does not bind to the merge target can look correct while still leaving a bypass path. You also need to check whether maintainers can override the rule, whether direct pushes are allowed, and whether the project allows alternative merge paths that skip the review step.
Who can approve matters just as much as how many approvals are required. If the same person can both author and approve their own change, or if approval resets are not configured in a way that clears stale approvals after a new commit, the rule may satisfy the UI while failing the control objective. Review enforcement should therefore be validated against actual merge behavior, not just against the settings page.
Use the approval rule as a control over change authority, not just as a workflow preference. The strongest implementation is one where branch protection, reviewer eligibility, and approval reset behavior all reinforce the same gate, so a merge cannot proceed after the control has been logically invalidated by new code.
When teams think they have two approvals but do not
The most common failure is confusing “two people looked at it” with “two approvals are still valid at merge time.” If a new push resets approvals, one approval can silently disappear. If a maintainer can merge without satisfying the rule, the approval count becomes advisory rather than mandatory. If self-approval is allowed, the process no longer provides meaningful separation of duties.
Another common issue is scope mismatch. A rule set at the project level may not reflect the branch structure you actually use, especially when protected branches, release branches, or mirrored workflows are involved. In that case, the control exists, but it is not governing the exact change path you care about.
For teams operating CI/CD at scale, merge approval is part of a larger control plane around code integrity and release integrity, not an isolated checkbox. The same discipline that prevents pipeline abuse also helps prevent review bypass through alternate merge paths. That is why required reviewers should be treated as a change-control mechanism, not just a collaboration setting.
Risk and Threat Considerations
Weak approval enforcement turns a review control into a false assurance control. The exposure is not only accidental mistakes, but also deliberate bypass of peer review through self-approval, maintainer override, stale approvals after a code change, or direct push paths that never hit the merge gate.
Failure mechanism: The approval rule exists in configuration, but the merge path, branch protection, or approval-reset behavior lets a change reach the protected branch without the intended second independent review.
Impact: Undetected defects, policy violations, or malicious code can be merged with a veneer of compliance, reducing the value of review as a prevention and detection control.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | Merge approvals depend on controlled review authority and privileged bypass paths. |
| Recommendation — Restrict merge authority and review permissions to approved roles, then remove any bypass-capable accounts. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Multiple approvals enforce limited change authority before code reaches protected branches. |
| Recommendation — Limit merge and override privileges so no single account can unilaterally approve or merge protected changes. | ||
| ISO/IEC 27001:2022 | A.8.32 — Change management | Merge request approvals are a change-control gate for software changes. |
| Recommendation — Require documented approval and verification steps before production-bound code changes are merged. | ||
Practitioner Guidance
What to verify: Test the actual merge flow for the target branch, including new commits after approval, maintainer privileges, and any direct-push exceptions. The right question is not “Is the rule configured?” but “Can a change still merge without two valid approvals at the point of merge?”
Decision rule: If the rule can be bypassed by role, branch path, or stale approval behavior, treat the configuration as incomplete and fix the enforcement path before relying on it for release control. If enforcement only holds under ideal user behavior, it is not a dependable gate.
Practitioner takeaway: Multiple approvals are only meaningful when GitLab enforces them at the protected merge path, with no role-based shortcut and no stale approval loophole.
Related resources from NHI Mgmt Group
- What is the difference between protected branches and merge request approvals in GitLab security controls?
- How do you manage access when field personnel use multiple devices and channels?
- How should security teams handle privacy rights requests when customer data is spread across multiple systems?
- What breaks when service requests are not tied to access approvals?