GitLab merge request approval settings: how they support separation of duties
An auditor or security lead asking who can approve a change and whether the author can approve their own work is asking about separation of duties, and in GitLab the answer is set in the project or group approval settings, not in habit. On Premium and Ultimate you can prevent the merge request creator from approving, prevent approvals by users who have added commits to the merge request, and stop anyone from editing approval rules inside a merge request. Those three settings close the most common self-approval paths. Teams that need them are usually those with change advisory obligations, regulated production code, or a requirement that a second person who did not write or commit the change signs off on it.
Two further settings strengthen the evidence. Requiring re-authentication to approve, with a password or SAML login, is what GitLab describes as an electronic signature for approvals, so the approver's identity is confirmed at the moment of sign-off. Removing approvals when new commits are pushed means an approval always refers to the exact code that was reviewed. Confirm with your own identity provider team that SAML re-authentication behaves as expected for your users before you rely on it as a signature control.
These settings govern merge requests. They do not replace your change process: they cannot tell you whether a change was risk-assessed, scheduled or authorized outside GitLab. Set the approval settings at instance or top-level group level, because those cascade down and lock the matching project settings, so a project owner cannot quietly relax them. Then test the rules with a non-privileged account in a sample project and record the results, since that test is the evidence an auditor will ask to see. Plan the approval rules alongside your GitLab documentation review and your change policy together.
Which approval setting fits each separation-of-duties risk
This table maps each Premium approval setting to the separation-of-duties risk it addresses, when a team would turn it on, and the friction it adds. Read each row as a question: which risk does your change process carry, and is the cost of the control acceptable for that project? The main takeaway is that the settings solve different problems, so enabling all of them everywhere is rarely the right first step.
| Setting | Risk it addresses | When to turn it on | Trade-off |
|---|---|---|---|
| Block merge request creator approval | The author of a change approves their own work, so no second person reviews it | Production-facing projects where an assessor expects a reviewer independent of the author | Solo maintainers cannot approve their own merge requests and need another approver available |
| Block approvals from users who added commits | A reviewer approves code they also wrote or pushed, which weakens independent review | Projects where pair programming or co-authored fixes are rare, or where reviewers should only inspect | Pairing or emergency fixes by a senior engineer may need a different approver, adding wait time |
| Prevent edits to approval rules in merge requests | A contributor changes who must approve within the same merge request that needs approval | Once approval rules are defined centrally and must stay stable for audit evidence | Teams that adjust rules per change lose that flexibility and must go through an owner |
| Require re-authentication to approve | An approval is recorded without proof that the approver actively confirmed it | When approvals are meant to act as an electronic signature for change records | Adds a sign-in step for each approval; confirm how your identity provider handles password or SAML prompts |
| Remove approvals on new commits | Code changes after approval, so the reviewed version differs from the merged version | Regulated release paths where the approved diff must match what is deployed | Small fixes after approval force a new review cycle, which can slow down merges |
How re-authentication turns an approval into an electronic signature
GitLab states that requiring password or SAML re-authentication enables an electronic signature for approvals. In practice, this means a reviewer cannot approve a merge request on the strength of an existing browser session alone. The approval action itself requires the reviewer to prove their identity again at that moment, and the approval record reflects that step. For an auditor reviewing approval evidence, the question shifts from "who clicked approve" to "was the person who clicked approve verifiably the named reviewer, at the time they approved." Confirm with your auditor that this re-authentication model satisfies your signature requirements before you cite it as evidence. Whether an electronic signature meets a given regulatory or internal standard is a judgment for the auditor and your legal or compliance function, not something the platform decides.
The choice between password and SAML re-authentication is a dependency on your identity setup, so make it with your identity team rather than in the project settings alone. Password re-authentication depends on GitLab holding a usable local password for each approver, which may conflict with a policy of disabling local passwords for users who sign in through corporate single sign-on. SAML re-authentication depends on your identity provider being configured for GitLab and on the approver's SAML session being able to challenge them again during the approval. Test both paths with a reviewer account before rollout, and record which method applies to which user population, since a reviewer who only ever signs in through SSO may be unable to satisfy a password prompt. Check the current behavior of each option against the approval settings documentation for your GitLab version.
Treat the re-authentication setting as one control among several in the approval chain, and document it as such. Pair it with the settings that block approvals by merge request authors and by users who added commits, and with the setting that removes approvals when new commits arrive, so that the signed approval refers to the exact code under review. Keep an export or screenshot of the effective settings at each approval evidence point, and record the identity method used for each reviewer. The compliance evidence then shows the signature mechanism, the identity source and the code state together.
Where GitLab merge request approval settings cascade and who controls them
At the instance level, the administrator sets approval defaults that apply across the whole self-managed GitLab installation. Settings made here are the outermost layer of control and are the first thing an assessor will ask to see. Because they cascade downward, a single instance-level choice can lock the matching project setting everywhere below it.
- Central baseline: Decide which separation-of-duties controls are non-negotiable for every project, such as blocking self-approval and blocking approval by users who added commits.
- Locking effect: A value set here locks the matching project setting, so project owners cannot relax it.
- Re-authentication: Requiring password or SAML re-authentication for approvals is best decided once here so the electronic signature behavior is consistent.
- Change control: Restrict who holds administrator rights, since those users can change the baseline for the whole instance.
- Scope check: Confirm which settings your edition and tier expose at this level, because Premium and Ultimate features differ.
Before you go further, confirm in your own test instance which approval settings are visible and locked at this level, and record the result as audit evidence.
A top-level group is where most organizations place a business unit, product line or regulated application family. Owners at this level can set approval rules that flow to every subgroup and project beneath them. This is the right place for controls that differ by division but must still be uniform within it.
- Division policy: Set the approval controls that a business unit must meet, such as removing approvals when new commits arrive.
- Inherited locks: Settings made here lock the matching project settings in every project within the group.
- Instance precedence: A stricter instance-level setting takes priority over anything a group owner chooses, so groups can only tighten the baseline in practice.
- Owner accountability: Name a specific group owner responsible for the division's approval posture and review it on a set schedule.
- Membership control: Limit Owner and Maintainer roles at this level, since those roles can manage group-wide configuration.
Ask the platform team to document which controls are set at the group and which are left open, so the boundary is clear to both developers and auditors.
Subgroups let teams organize projects by product, team or environment under a top-level group. Settings configured on a parent group flow into the subgroup and lock the matching options there. A subgroup owner can therefore manage team-level workflow, but only within the room left by the levels above.
- Inherited controls: Approval settings from the parent group apply automatically and cannot be loosened by the subgroup owner.
- Team workflow: Subgroup owners can shape everything the parent leaves open, such as the approval rules that define reviewers for each repository.
- Structure risk: Moving a project between groups can change which settings apply, so treat group moves as a controlled change.
- Nested depth: Keep the hierarchy shallow enough that reviewers can trace which setting governs which project.
- Review of rules: Check that approval rules at this level still name real reviewers and roles after team changes.
Confirm with your team how subgroups are created and who may create them, since that decision determines how much control flows down to each team.
The project level is where individual repositories set their merge request approval rules. When a higher level has already set a value, the project setting is locked and the project owner cannot change it. Where the higher level leaves a setting open, the project owner decides, which makes this the place for repository-specific reviewers and rules.
- Locked settings: Controls inherited from the instance or groups appear as fixed values and cannot be edited in the project.
- Open settings: Owners choose reviewers, required approval counts and rules only where the parent left room.
- Rule editing: Whether merge request approval rules can be edited within a merge request depends on the locking settings above, so confirm this in your own configuration.
- Ownership: Assign project maintainers who understand the separation-of-duties model and can explain it to auditors.
- Evidence: Record project approval configuration as part of change management records for regulated repositories.
Ask for a walkthrough of one regulated project to confirm which settings are locked and which the owner can still decide.
Configuring GitLab merge request approval settings on a self-managed instance
This sequence takes a self-managed GitLab instance from edition check to tested separation of duties, so the approval settings an auditor will ask about are set at the right level, enforced, and proven with evidence.
Confirm the edition includes approval settings
A GitLab administrator checks the installed tier in the Admin area before anything else. The approval settings described here are documented for Premium and Ultimate, so an instance on Free needs an upgrade or a different control plan before the work starts. Confirm the license with the vendor or in the instance's own license view, and record the tier in the change ticket. Done means the tier is written down and matches what the licensing contract says.
Agree the separation-of-duties policy with the control owner
Before any setting changes, the control owner, usually the person accountable for change management, and the engineering lead agree which rules the policy requires. Typical decisions include whether a merge request author may approve their own change, whether a user who pushed commits may count as an approver, whether approval rules can be edited on a merge request, whether approvals survive new commits, and whether approval must be re-authenticated. Write each decision as a yes or no with an owner. Done means a signed policy record maps each setting to a named control objective.
Set approval rules at instance or top-level group
An administrator sets the agreed values at the instance level or on the top-level group, since settings there cascade down and lock the matching project settings. Setting them at a sub-group or project instead leaves room for drift, so use the highest level the policy allows. Record which settings are enabled, the date, and the person who made the change. Done means a project under the group shows the inherited values as locked and cannot override them.
Confirm re-authentication through the identity provider
If the policy requires an electronic signature for approvals, the instance must ask approvers to re-authenticate with their password or through SAML. Work with the identity team to confirm that the configured identity provider returns a fresh authentication event that GitLab accepts. Test with a standard user account and a user who signs in through SSO, because the two paths can behave differently. Done means a test approver is prompted at approval time and the attempt is recorded in the approval record.
Prepare a test project with protected branches
Create a dedicated test project in the group so that the production repositories are not affected. Add a protected target branch, a second test account for approval, and an author account. Keep the project free of production secrets and sensitive code. Done means the project inherits the locked approval settings and a merge request can be opened against the protected branch.
Test each blocked approval path
Using the test project, the tester runs one merge request for each rule. The author tries to approve their own merge request, a committer who pushed a commit tries to approve, a user tries to edit approval rules on the merge request, and a reviewer approves before a new commit is pushed to confirm approvals are removed. Each attempt should be refused or reset as the settings require. Record the outcome, the screenshot or API response, and the merge request link. Done means every blocked path has a documented expected result and an observed result that matches it.
Retain the evidence and schedule a review
Export the approval settings, the test results and the policy record, and store them in the evidence location the control owner names. Ask the control owner to confirm the retention period and who may read the evidence, because those terms come from the organization's own policy. Schedule a periodic review of the settings and of the audit events that show setting changes. Done means the control owner accepts the evidence package and the review date is in the change calendar.
Security and operational considerations for approval controls
Approval settings only protect separation of duties if the people who can change them, the identity provider behind re-authentication, and the upgrade process all stay under control. The cards below cover the operational questions auditors and security teams tend to raise after the settings are first switched on.
Who can change approval settings
Approval settings sit at the instance, group and project levels, and a higher-level setting cascades down and locks the matching project setting. That makes the owner of the top-level group or the instance administrator the most consequential account in the approval model. Confirm who holds those roles, how role changes are approved, and whether changes to these settings appear in your audit trail before you rely on the lock.
Identity provider changes and re-authentication
When re-authentication to approve is enabled, GitLab treats a password or SAML sign-in as the electronic signature for an approval. If your identity provider changes its SAML configuration, certificates, or the users' authentication methods, approvals may stop working or may be accepted without the strength you expected. Test an approval with a non-production account after every identity change, and record the test result.
Emergency changes without weakening the control
Urgent production fixes often tempt teams to disable a blocking setting for a single change. Because the setting is enforced from above, a project owner usually cannot switch it off locally, which means the exception path has to be planned at the instance or top-level group. Define in advance who may approve an emergency exception, how it is recorded, and when the blocking setting is restored, so the exception does not become the default.
Reviewing evidence after a rule change
A change to approval rules or to the approval settings changes what a later merge request needs before it can merge. Sample merge requests from the period before and after each change and check the approvers, the approval rule used, and whether any approvals were removed by new commits. Keep the sampled records with the change ticket so an auditor can follow the sequence without relying on memory.
Consistency across self-managed upgrades
Self-managed GitLab moves through required upgrade stops, and each upgrade can introduce settings or interface changes that affect how approvals behave. Record the approval settings as a baseline before each upgrade, compare them after the upgrade, and verify the cascade on a sample project. Schedule the check as part of the upgrade runbook rather than treating it as a one-time task.
Relationship to approval policies in Ultimate
Premium approval settings are one layer of control. GitLab Ultimate adds merge request approval policies and compliance features, which the GitLab pricing page places in the Ultimate tier. Decide early whether the settings alone meet your separation-of-duties requirement or whether policies are needed, and confirm with your GitLab representative which features your chosen tier includes before you design the control around them.
What approval settings do not prove on their own
Approval settings enforce a rule inside each merge request, but they do not produce a complete change management record by themselves. A setting that blocks author approval or removes approvals on new commits shows how GitLab was configured at the moment someone looked. It does not show who was allowed to change that configuration over the audit period, whether the change was approved, or whether the people holding approval rights still need them. Auditors usually want those answers too, so the team should expect to supply evidence around the setting, not only a screenshot of it. The evidence an auditor may request tends to fall into a few groups. Access reviews show that the users and groups with Maintainer or Owner rights on protected projects, and the people able to edit approval rules, were checked on a schedule and that stale access was removed. Audit events record administrator, group and project changes, including changes to approval settings at the instance, group or project level, and they need to be retained and exported somewhere the platform team cannot silently alter. Documented ownership of each approval rule names who proposed it, who approves changes to it, and which control objective it serves. The team should confirm with its auditor which of these artifacts, and which sampling period, it will accept as sufficient before the configuration is treated as final. The practical decision is where to keep this evidence and who signs it. Ask the auditor whether a configuration export, a change ticket linked to each settings change, and quarterly access review records are enough, or whether they expect continuous logs in a SIEM. Then confirm with your own platform team that audit event retention and export are in place for the period under review, because the approval settings page cannot prove that a rule existed last quarter if the log of its change has already expired.
Limits to confirm before you rely on these settings
Approval settings only enforce separation of duties if your edition, login method, group structure and pipeline design support them as you expect. Each item below is a check to complete with GitLab documentation or your own test instance before an auditor sees the configuration.
Edition and tier availability
The approval settings described here are documented for Premium and Ultimate, so a Free instance cannot enforce them. Confirm the tier of every instance and group in scope, and check whether any setting you plan to cite sits on a higher tier than the one you license. Record the GitLab version you tested against, because approval options change between releases and should be verified against the release you run.
Re-authentication by login method
Requiring re-authentication to approve is the basis for treating an approval as an electronic signature, but the mechanism depends on how users sign in. Confirm whether password re-authentication applies to your accounts, or whether SAML re-authentication is required through your identity provider, and test an approval for each login path your reviewers use, including accounts provisioned through LDAP or SCIM.
Cascaded locks on existing projects
Settings applied at the instance or top-level group flow down and lock the matching project settings. Before you rely on this, check how the lock presents on projects that already had different approval rules, whether any project owner can still change related rules, and whether subgroups inherit the lock as you expect. Run the change on a copy of a representative project and record what changed.
Interaction with protected branches
Approval rules control whether a merge request may merge, but protected branch settings control who may push or merge directly. Confirm that no maintainer or deploy path bypasses the approval gate, including direct pushes, pipeline triggers and API-driven merges. Test each path with a reviewer account that has the same role as your engineers.
Pipeline and commit behavior
Removing approvals on new commits and blocking approvals from users who added commits both depend on how your pipelines push, rebase and squash. Confirm how force pushes, rebases from the web interface and bot accounts that commit to branches affect existing approvals. A pipeline that rewrites history can reset approvals in ways your change records must explain.
Auditor acceptance of the signature approach
A re-authenticated approval is a configuration choice, not an independent attestation. Ask your auditor or compliance adviser whether they accept re-authentication as evidence of intent for the change types in scope, and what additional evidence they expect, such as exported approval records or audit events. Certification and audit decisions rest with the assessor, so agree the evidence set in writing before you rely on it.
What teams ask before configuring approval separation of duties
What drives the cost of configuring merge request approval separation of duties?
The cost is driven by four things: the GitLab edition you license, how much identity work is needed, how many groups and projects must follow the same rules, and how complex the approval policy design is. GitLab's published price for Premium is 29 US dollars per user per month billed annually, and the settings described on this page need Premium or Ultimate. Licensing recurs every billing period, while configuration, testing and documentation are usually one-time work. Ask any partner for a quote that separates licensing from services, lists the groups and projects in scope, and states how re-authentication and SAML settings will be tested.
How long does it take to configure and test approval settings?
The duration depends on how many top-level groups, subgroups and projects inherit the settings, how many approval rules already exist, and whether reviewers must re-authenticate through SAML. A small instance with one group structure is simpler than a multi-group estate where teams have built their own rules. Testing usually takes as long as configuration, because each setting needs a negative test showing that an author or committer cannot approve their own change. Ask for a timeline tied to a written list of groups, projects and test cases, and confirm when the audit evidence will be exported.
What do we need from our platform, identity and compliance teams?
Each team has a distinct role:
- The platform team confirms the GitLab version, edition, instance-level settings and the group hierarchy.
- The identity team confirms how users sign in and whether SAML re-authentication is available for approvals.
- The compliance team defines which separation-of-duties controls apply and what evidence an assessor will request.
Without these inputs, the approval rules may match the configuration but not the control objective. Agree on owners for each setting before work starts, and record who can change instance-level settings later.
Can our internal team configure merge request approval settings alone?
Yes, if the team has GitLab administration skills, access to the Premium or Ultimate tier, and time to test the settings properly. The configuration itself is available in the GitLab interface and API, so the main risk is not the clicks but the design. Internal teams often miss cascading effects, where an instance-level or top-level group setting locks matching project settings across the hierarchy. A useful check is to test one project per group type with a second user acting as reviewer, then document the results. Many teams do the build in-house and bring in a partner only for an independent review of the design.
Does re-authentication for approvals count as an electronic signature?
GitLab states that requiring password or SAML re-authentication enables an electronic signature for approvals. Whether that satisfies a specific regulation or internal policy is a decision for your compliance team and auditor, not for the configuration alone. Confirm which authentication method your users use, since SAML re-authentication depends on the identity provider setup. Document how the signature is linked to the approver, the merge request and the time of approval, and ask your assessor which evidence they expect to see.
What does a fixed-scope engagement for approval settings cover?
A fixed-scope engagement is agreed in writing before work starts and lists the scope, deliverables and timeline. For this topic, that typically means reviewing the current settings, designing the approval rules, configuring the instance, top-level groups and projects in scope, testing each control, and preparing documentation for your compliance team. It does not include issuing an audit report or certification, because independent auditors and certification bodies do that. Ask for the exact list of groups, projects and controls covered, and for what happens if the scope changes.
What should we check when a new commit removes an approval?
Engineers should confirm that the setting removing approvals on new commits is enabled for the relevant projects, so a reviewer must approve the final code rather than an earlier version. Test this with a merge request that receives an approval, then receives a new commit, and confirm the approval is removed. Also check the setting that prevents approvals by users who add commits, since a reviewer who pushes a fix may not be independent. Record both results as test evidence, and repeat the test after any change to the group hierarchy.
How DeployOpen scopes and delivers approval controls on self-managed GitLab
DeployOpen plans, configures and documents merge request approval settings on self-managed GitLab inside your own infrastructure, including the instance-level and group-level settings that cascade to projects. The work is scoped in writing before it starts, so your approval model, evidence and handover are agreed up front.
How we scope
- Map your change management roles, repositories and groups to the approval settings each must enforce.
- Confirm which settings your GitLab tier supports, since these controls depend on Premium or Ultimate.
- Agree in writing which projects, groups and instance settings are in scope, with the deliverables for each.
How we build
- Configure instance and top-level group approval settings so matching project settings are locked where intended.
- Set up re-authentication for approvals and test whether the approval flow behaves as your policy describes.
- Test blocked author and committer approvals, locked approval rules and removal of approvals on new commits in a non-production instance.
How we hand over
- Document each approval setting, its cascade path, its owner and the reason it was chosen for your organization.
- Provide test records showing which approval scenarios were exercised and what the result was.
- Walk your administrators and reviewers through the settings so they can explain them to auditors.
How we support
- Review approval settings after GitLab upgrades, since release changes can affect how settings behave.
- Available as a retainer for ongoing configuration changes, periodic reviews and evidence refreshes.
- Independent auditors and certification bodies assess your controls; DeployOpen prepares the systems and evidence they review.
