# Stale pull request approvals dismissed when new commits are pushed

- Source: https://support.icompaas.com/support/solutions/articles/a_1781198558435947-stale-pull-request-approvals-dismissed-when-new-commits-are-pushed
- 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 is configured to automatically dismiss stale pull request approvals when new commits are pushed to a pull request. When additional commits are added after a review has been approved, previous approvals are invalidated, requiring reviewers to re-evaluate the updated code before it can be merged.

  

Rationale:

Code changes introduced after a review may alter the functionality, security posture, or quality of the pull request. If prior approvals remain valid after new commits are added, unreviewed changes could be merged into protected branches. Automatically dismissing stale approvals ensures that all code modifications receive appropriate review and approval before merging.

  

Impact:

Enabling this control may:

-   Require reviewers to re-approve pull requests after new commits are pushed.
    
-   Increase the time required to merge pull requests with frequent updates.
    
-   Improve code review effectiveness and change management controls.
    
-   Reduce the risk of unreviewed code being merged into protected branches.
    

  

Default Value:

By default, GitHub does not dismiss stale pull request approvals when new commits are pushed. Repository administrators must explicitly enable this setting within branch protection rules.

  

Remediation:

Test Plan:

1.  Log in to GitHub with access to the repository.
    
2.  Navigate to the target repository.
    
3.  Select Settings.
    
4.  Click Branches.
    
5.  Locate the branch protection rule applied to the default branch.
    
6.  Review the pull request review requirements.
    
7.  Verify that Dismiss stale pull request approvals when new commits are pushed is enabled.
    

  

Expected Result:  
The branch protection rule is configured to automatically dismiss existing approvals whenever new commits are pushed to a pull request.

  

Implementation:

1.  Log in to GitHub with repository administrator privileges.
    
2.  Navigate to the target repository.
    
3.  Select Settings And select Click Branches.
    
4.  Create a new branch protection rule or edit the existing rule for the default 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.  Under pull request review requirements, enable Dismiss stale pull request approvals when new commits are pushed.
    

8.  Save the branch protection rule.
    

  

Backout Plan:

1.  Log in to GitHub with repository administrator privileges.
    
2.  Navigate to the target repository.
    
3.  Select Settings and click Branches.
    
4.  Locate the branch protection rule associated with the default branch.
    
5.  Edit the rule.
    
6.  Disable Dismiss stale pull request approvals when new commits are pushed.
    

7.  Save the changes.
    

  

References:

-   [https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-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/about-protected-branches)
    
-   [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)
    
-   [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)

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