# Branch protection enabled on default branch

- Source: https://support.icompaas.com/support/solutions/articles/a_1781201324223468-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) › [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 the default branch in a GitLab project is configured as a protected branch. Protected branches restrict who can push, merge, or modify code on critical branches, helping to prevent unauthorized or accidental changes.

  

Rationale:

The default branch typically contains production-ready or business-critical code. Protecting the default branch ensures that changes are controlled through approved workflows and helps maintain the integrity, stability, and security of the codebase.

  

Impact:

Enabling branch protection may:

-   Restrict direct pushes to the default branch.
    
-   Require users to submit changes through merge requests.
    
-   Limit merge permissions to authorized users.
    
-   Improve change control and code quality.
    

  

Default Value:

In this GitLab environment, the default branch is automatically created as a Protected Branch with the following settings:

-   Allowed to Push: Maintainers
    
-   Allowed to Merge: Maintainers
    
-   Force Push: Disabled
    

The actual default value may vary based on GitLab instance-level or group-level configuration.

  

Remediation:

Test Plan:

1.  Log in to GitLab with access to the project.
    
2.  Navigate to the project.
    
3.  Select Settings → Repository.
    
4.  Locate the Protected Branches section.
    
5.  Identify the default branch (typically main).
    
6.  Verify that the default branch appears in the list of protected branches.
    
7.  Verify the branch protection settings:
    

-   Branch is marked as Protected.
    
-   Push permissions are restricted.
    
-   Merge permissions are restricted.
    
-   Force push is disabled.
    

  

Implementation:

If the default branch is not protected:

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

4.  Expand the Protected Branches section.
    
5.  Under Protect a Branch, select the default branch.
    
6.  Configure:
    

-   Allowed to Push: Maintainers or No One (recommended).
    
-   Allowed to Merge: Maintainers.
    
-   Allow Force Push: Disabled.
    

7.  Click Protect.
    
8.  Verify that the default branch appears in the protected branches list.
    

  

Backout Plan:

If branch protection was enabled as part of this remediation and must be reverted:

1.  Log in to GitLab with Maintainer or Owner privileges.
    
2.  Navigate to the project.
    
3.  Select Settings → Repository.
    
4.  Expand the Protected Branches section.
    
5.  Locate the protected default branch.
    
6.  Click Unprotect or modify the protection settings to their previous values.
    
7.  Save the changes.
    

  

References:

-   [https://docs.gitlab.com/ee/user/project/protected\_branches/](https://docs.gitlab.com/ee/user/project/protected_branches/)
    
-   [https://docs.gitlab.com/ee/user/project/repository/branches/protected/](https://docs.gitlab.com/ee/user/project/repository/branches/protected/)
    
-   [https://docs.gitlab.com/ee/user/project/merge\_requests/](https://docs.gitlab.com/ee/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.