# At least one reviewer required before merge

- Source: https://support.icompaas.com/support/solutions/articles/a_1781201348377289-at-least-one-reviewer-required-before-merge
- Section: [Solutions](https://support.icompaas.com/support/solutions) › [Version Control System (VCS)](https://support.icompaas.com/support/solutions/c_1781179095087930) › [Gitlab](https://support.icompaas.com/support/solutions/folders/f_178117912544158)
- Last updated: 2026-06-12
- Publisher: iCompaas, Inc. (https://www.icompaas.com)

Description:

This check verifies that GitLab requires at least one approval before a merge request can be merged into the target branch. Requiring reviewer approval ensures that code changes are reviewed by another authorized user before being incorporated into the codebase.

  

Rationale:

Code reviews help identify defects, security vulnerabilities, violations of coding standards, and unintended changes before code reaches protected branches. Requiring at least one approval improves code quality, strengthens change management controls, and reduces the risk of unreviewed or unauthorized changes being merged.

  

Impact:

Enforcing reviewer approval requirements may:

-   Increase the time required to merge changes.
    
-   Require collaboration between developers and reviewers.
    
-   Improve code quality and security.
    
-   Reduce the likelihood of defects reaching production environments.
    

  

Default Value:

Disabled

By default, GitLab projects do not require merge request approvals. Approval requirements must be explicitly configured at the project or group level.

Default setting:

-   Approvals Required: 0
    

  

Remediation:

Test Plan:

1.  Log in to GitLab with access to the project.
    
2.  Navigate to the target project.
    
3.  Navigate to Settings → Merge requests.
    
4.  Locate the Merge Request Approvals or Approval Rules section.
    
5.  Review the configured approval requirements.
    
6.  Verify that Approvals Required is set to 1 or greater.
    

  

Implementation:

1.  Log in to GitLab with Maintainer or Owner privileges.
    
2.  Navigate to the target project.
    
3.  Select Settings → Merge requests.
    

4.  Locate Merge Request Approvals or Approval Rules.
    
5.  Edit Merge Request Approvals or create new Merge Request Approvals.
    

6.  Enter a meaningful ruleset name and select the target branch(All Branches). Set the required number of approvals to 1. Add one or more eligible reviewers or groups.
    

7.  Save the configuration.
    

  

Backout Plan:

1.  Log in to GitLab with Maintainer or Owner privileges.
    
2.  Navigate to Settings → Merge requests.
    
3.  Locate Merge Request Approvals or Approval Rules.
    
4.  Change Approvals Required from 1 to 0 (or restore the previous value). Or delete the particular rule.
    

5.  Save the changes.
    
6.  Confirm that project operations are normal after the rollback.
    

  

References:

-   [https://docs.gitlab.com/user/project/merge\_requests/approvals/](https://docs.gitlab.com/user/project/merge_requests/approvals/)
    
-   [https://docs.gitlab.com/user/project/merge\_requests/approvals/rules/](https://docs.gitlab.com/user/project/merge_requests/approvals/rules/)
    
-   [https://docs.gitlab.com/user/project/merge\_requests/](https://docs.gitlab.com/user/project/merge_requests/)

## Related compliance guidance

- [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Configuration checks like this one are the technical half of a SOC 2 / ISO 27001 programme — the guide shows where they fit, what else an auditor expects, and how to evidence them.
- [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): ISO 27001 Annex A.8 (technological controls) is where cloud hardening evidence lands; the guide shows how to run the ISMS around it.