# At least one reviewer required before merge

- Source: https://support.icompaas.com/support/solutions/articles/a_1781193531784236-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) › [GitHub](https://support.icompaas.com/support/solutions/folders/f_1781179116560328)
- Last updated: 2026-06-11
- Publisher: iCompaas, Inc. (https://www.icompaas.com)

Description:

This check verifies that GitHub repositories require at least one approval review before pull requests can be merged into protected branches. Requiring reviewer approval ensures that code changes are evaluated by another contributor before being incorporated into the codebase.

  

Rationale:

Peer review is an essential software development practice that helps identify coding errors, security vulnerabilities, design issues, and unintended changes before code is merged. Requiring at least one reviewer approval strengthens change management controls, improves code quality, and reduces the risk of introducing defective or unauthorized code into protected branches.

  

Impact:

Enforcing reviewer approval requirements may:

-   Increase the time required to merge pull requests.
    
-   Require collaboration between developers before code integration.
    
-   Improve code quality and maintainability.
    
-   Reduce the likelihood of defects and security vulnerabilities reaching production environments.
    

  

Default Value:

By default, GitHub does not require pull request reviews before merging. Repository administrators must configure branch protection rules or rulesets to enforce reviewer approval requirements.

  

Remediation:

Test Plan:

1.  Log in to GitHub with access to the repository.
    
2.  Navigate to the target repository.
    
3.  Select Settings → Branches.
    
4.  Review the Branch protection rules section.
    
5.  Locate the branch protection rule or ruleset applied to the target branch.
    
6.  Review the pull request requirements.
    
7.  Verify that Require a pull request before merging is enabled.
    
8.  Verify that Require approvals is enabled.
    
9.  Confirm that the Required number of approvals before merging is set to 1 or greater.
    

  

Expected Result:  
The protected branch requires at least one approving review before a pull request can be merged.

  

Implementation

1.  Log in to GitHub with repository administrator privileges.
    
2.  Navigate to the target repository.
    
3.  Select Settings and click Branches.
    
4.  Create a new branch protection rule or edit an existing rule for the target branch.
    
5.  Enter a meaningful ruleset name  Set Enforcement Status to Active.Under Target Branches, click Add Target. And select include all branches
    

  

6.  Enable Require a pull request before merging.
    
7.  Enable Require approvals and Set the required number of approvals before merging to 1 or greater.
    

8.  Save the branch protection rule.
    

  

Backout Plan

If the reviewer approval requirement was enabled as part of this remediation and needs to be reverted:

1.  Log in to GitHub with repository administrator privileges.
    
2.  Navigate to the target repository.
    
3.  Select Settings and select Branches.
    
4.  Locate the branch protection rule associated with the target branch.
    
5.  Edit the rule.
    
6.  Uncheck Require a pull request before merging  
    

7.  Save the changes.
    
8.  Confirm that repository operations function as expected after the rollback.
    

  

References:

-   [https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/about-protected-branches](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/about-protected-branches)
    
-   [https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests)
    
-   [https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/code-reviewing-pull-requests/about-pull-request-reviews](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/code-reviewing-pull-requests/about-pull-request-reviews)

## 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.