# Ensure Invalidate Prior Approvals Upon Code Change Updates

- Source: https://support.icompaas.com/support/solutions/articles/62000234903-ensure-invalidate-prior-approvals-upon-code-change-updates
- Section: [Solutions](https://support.icompaas.com/support/solutions) › [CIS GitHub Benchmark v1.0.0](https://support.icompaas.com/support/solutions/62000112695) › [CIS GitHub Benchmark v1.0.0](https://support.icompaas.com/support/solutions/folders/62000169264)
- Last updated: 2026-05-29
- Publisher: iCompaas, Inc. (https://www.icompaas.com)

**Profile Applicability:  
Level 1**

**Description:** When a code change proposal (such as a pull request or merge request) is updated with new commits or modifications, any prior approvals must be dismissed or revoked. This ensures that reviewers re-evaluate the updated changes, maintaining the integrity of the review process and preventing unreviewed code from being merged.

**Rationale**:  
 Dismissing previous approvals after updates guarantees that reviewers assess all the latest changes thoroughly. It reduces the risk of introducing defects, vulnerabilities, or unintended behavior into the codebase without proper oversight. This practice strengthens code quality and compliance with secure development policies.

**Impact:  
 Pros:**

-   Ensures comprehensive review of all code changes.  
      
    
-   Prevents accidental merging of unreviewed updates.  
      
    
-   Enhances code quality and security posture.  
      
    

**Cons:**

-   May increase review time due to repeated approvals.  
      
    
-   Requires consistent enforcement in development workflows.  
      
    

**Default value:** Some version control systems or repositories may allow prior approvals to persist despite new changes, leading to potential oversight.

**Audit:** Check pull request or merge request settings to verify if approvals are dismissed automatically upon new commits. Review approval logs to confirm dismissal behavior.

**Remediation:** Configure repository settings or enforce policies that automatically dismiss prior approvals when code changes are pushed to an existing code change proposal. Educate development teams on this process to ensure compliance.

**References:**

1.  GitHub Documentation - Require review from Code Owners: [https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/about-protected-branches#require-review-from-code-owners](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/about-protected-branches#require-review-from-code-owners)
    
2.  GitLab Merge Request Approval Rules: [https://docs.gitlab.com/ee/user/project/merge\_requests/approvals/#resetting-approvals-when-pushing-new-commits](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/#resetting-approvals-when-pushing-new-commits)
    
3.  CIS Controls v8, Control 6 - Maintenance, Monitoring, and Analysis of Audit Logs: [](https://www.cisecurity.org/controls/maintenance-monitoring-and-analysis-of-audit-logs/) [https://www.cisecurity.org/controls/maintenance-monitoring-and-analysis-of-audit-logs/  
    ](https://www.cisecurity.org/controls/maintenance-monitoring-and-analysis-of-audit-logs/)

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