# Required status checks configured before merge

- Source: https://support.icompaas.com/support/solutions/articles/a_178120185877229-required-status-checks-configured-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 requires successful status checks (such as CI/CD pipeline builds, automated tests, or quality gates) before a pull request can be merged. This ensures that code changes are validated and meet defined quality standards prior to integration.

Rationale:

Status checks help verify that code changes have passed automated validation processes, including builds, tests, and security scans. Requiring successful status checks before merge reduces the risk of introducing defective, unstable, or insecure code into protected branches.

Impact:

Enforcing required status checks may:

-   Prevent pull requests from being merged when validation checks fail.
    
-   Increase merge times while builds and tests complete.
    
-   Improve code quality and reliability.
    
-   Reduce the likelihood of production issues caused by untested code.
    

Default Value:

Disabled

By default, Bitbucket does not require successful builds or status checks before pull requests can be merged. Repository administrators must explicitly configure merge checks.

Remediation:

Test Plan:

1.  Log in to Bitbucket with access to the repository.
    
2.  Navigate to Repository Settings → Branch Restrictions.
    
3.  Confirm Bitbucket Pipelines is enabled, or an external CI tool is integrated and posting build statuses.
    
4.  Locate the restriction configured for the default branch (or \*, if scoped to all branches).
    
5.  Review the Merge Checks section.
    
6.  Verify "Minimum number of successful builds for the last commit with no failed builds and no in progress builds" is enabled, with value ≥ 1.
    

  

Implementation:

1.  Log in to Bitbucket with repository administrator privileges.
    
2.  Navigate to the target repository.
    
3.  Select Repository Settings.
    

4.  Open Branch Restrictions.
    

5.  Edit or create a branch restriction for the default branch.
    
6.  In the branch Restriction, select by branch name or pattern add “\*” value (it will include all branches).
    

7.  Under Merge Checks, enable:
    

-   Minimum number of successful builds for the last commit with no failed builds and no in progress builds
    

8.  Set the required value to 1 or greater.
    
9.  Save the configuration.
    

Backout Plan:

1.  Log in to Bitbucket with repository administrator privileges.
    
2.  Navigate to Repository Settings.
    
3.  Open Branch Restrictions.
    
4.  Edit the branch restriction associated with the default branch.
    
5.  Disable the minimum number of successful builds for the last commit with no failed builds and no in-progress builds.
    
6.  Save the changes.
    
7.  Confirm that repository operations are normal 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/use-branch-permissions/](https://support.atlassian.com/bitbucket-cloud/docs/use-branch-permissions/)
    
-   [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.