# Branch protection enabled on default branch

- Source: https://support.icompaas.com/support/solutions/articles/a_1781188923966490-branch-protection-enabled-on-default-branch
- 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 branch restrictions are configured on the default branch of a Bitbucket repository. Branch restrictions help protect critical branches by controlling who can push, merge, delete, or rewrite branch history, ensuring that changes follow the organization's development and review processes.

  

Rationale:

The default branch typically contains stable or production-ready code. Without branch restrictions, users with repository access may directly push changes, bypass pull request reviews, overwrite commits, or accidentally modify critical code. Enabling branch protection reduces the risk of unauthorized changes and helps maintain code quality and repository integrity.

  

Impact:

Enabling branch restrictions on the default branch may:

-   Prevent direct commits to the default branch.
    
-   Require pull requests before changes can be merged.
    
-   Enforce minimum approval requirements.
    
-   Restrict branch deletion and history rewrites.
    
-   Introduce additional review requirements before code changes are accepted.
    

  

Default Value:

By default, Bitbucket repositories do not have branch restrictions configured. Repository administrators must manually create branch restriction rules to protect the default branch.

  

Remediation:

Test Plan:

1.  Log in to Bitbucket with access to the repository.
    
2.  Navigate to the target repository.
    
3.  Select Repository settings.
    
4.  Click Branch restrictions under the Workflow section.
    
5.  Verify whether a branch protection rule exists for the default branch
    
6.  If a branch protection rule is not created for the default branch(typically main or master), follow the implementation steps.
    

  

Expected Result:  
The default branch has branch restriction rules configured that prevent unauthorized direct changes and enforce the organization's review requirements.

  

Implementation:

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

3.  Click Branch restrictions under the Workflow section.
    
4.  Select Add a branch restriction.
    
5.  Select by branch name or pattern and enter the default branch name (main)
    
6.  Under Write Access, select : “Only specific people or groups have write access" 
    
7.  Ensure the following options remain unchecked (Allow rewriting branch history & Allow deleting this branch). Under Merge Access via Pull Requests, select (Only specific people or groups have merge access)
    

8.  Add the required administrator, maintainer, or repository owner group that is authorized to merge pull requests.
    

  

9.  Click Merge Settings and configure the required protections depending on the organization's requirements.
    

  Required

☑ Minimum number of approvals = 1

☑ No changes are requested

☑ No unresolved pull request tasks

Optional (if you have CI/CD builds configured)

☑ Minimum number of successful builds for the last commit = 1

10.  Click Save.
     

  

Backout Plan:

If the branch restriction rule was enabled as part of this remediation and needs to be reverted:

1.  Log in to Bitbucket with repository administrator privileges.
    
2.  Navigate to the target repository.
    
3.  Select Repository settings.
    
4.  Click Branch restrictions.
    
5.  Locate the branch restriction rule that was enforced for the default branch protection
    
6.  Click on Remove to delete the branch protection rule
    

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

  

References:

-   [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/suggest-or-require-checks-before-a-merge/](https://support.atlassian.com/bitbucket-cloud/docs/configure-a-projects-branch-restrictions/)
    
-   [https://support.atlassian.com/bitbucket-cloud/docs/work-with-pull-requests/](https://support.atlassian.com/bitbucket-cloud/docs/work-with-pull-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.