# At least one reviewer required before merge

- Source: https://support.icompaas.com/support/solutions/articles/a_1781196082084235-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) › [Bitbucket](https://support.icompaas.com/support/solutions/folders/f_1781179159125832)
- Last updated: 2026-09-08
- Publisher: iCompaas, Inc. (https://www.icompaas.com)

Description:

This check verifies that Bitbucket repositories are configured to require at least one approval before a pull request can be merged. This control ensures that code changes are reviewed by another team member before being incorporated into the target branch.

  

Rationale:

Requiring at least one reviewer approval helps improve code quality, detect defects early, enforce development standards, and reduce the risk of introducing security vulnerabilities or unauthorized changes. Peer review also promotes knowledge sharing and accountability within development teams.

  

Impact:

Enabling this control may:

-   Increase the time required to merge pull requests.
    
-   Require developers to obtain approval from another contributor before merging changes.
    
-   Improve code quality and governance.
    
-   Reduce the likelihood of defects and security issues reaching production environments.
    

  

Default Value:

By default, Bitbucket does not require pull request approvals before merge. Repository administrators must configure merge checks to enforce approval requirements.

  

Remediation:

Test Plan:

1.  Log in to Bitbucket with access to the repository.
    
2.  Navigate to the target repository.
    
3.  Select Repository settings.
    
4.  Under Workflow, click Branch Restriction.
    
5.  Review the existing or create a new Branch Restriction configuration.
    
6.  Verify that the minimum number of approvals is enabled.
    
7.  Confirm that the value is configured as 1 or greater.
    
8.  If a branch protection rule is not created with the minimum number of approvals, follow the implementation steps
    

  

Expected Result:  
The repository requires at least one approval before a pull request can be merged.

  

Implementation:

1.  Log in to Bitbucket with access to the repository.
    
2.  Navigate to the target repository.
    
3.  Select Repository settings.
    

4.  Under Workflow, click Branch Restriction
    
5.  Review the existing or create a new Branch Restriction configuration.
    
6.  In the branch Restriction,Select by branch name or pattern add “\*” value (it will include all branches) .
    

  

7.  In the merge settings, check box the Minimum number of approvals value would be 1 or greater than 1.
    

  

8.  Save the configuration.
    

  

Backout Plan:

If this configuration was enabled as part of the remediation and needs to be reverted:

1.  Log in to Bitbucket with access to the repository.
    
2.  Navigate to the target repository.
    
3.  Select Repository settings.
    
4.  Under Workflow, click Branch Restriction.Edit the branch restriction.
    
5.  Locate the Minimum number of approvals setting.
    
6.  Disable the setting or change the value to 0 according to organizational requirements.
    

7.  Save the configuration.
    
8.  Confirm normal repository operations after the rollback.
    

  

References:

-   [https://support.atlassian.com/bitbucket-cloud/docs/checks-for-merging-pull-requests/](https://support.atlassian.com/bitbucket-cloud/docs/checks-for-merging-pull-requests/)
    
-   [https://support.atlassian.com/bitbucket-cloud/docs/work-with-pull-requests/](https://support.atlassian.com/bitbucket-cloud/docs/work-with-pull-requests/)
    
-   [https://support.atlassian.com/bitbucket-cloud/docs/configure-a-projects-merge-strategies-and-checks/](https://support.atlassian.com/bitbucket-cloud/docs/configure-a-projects-merge-strategies-and-checks/)

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