They can, if approvals are enforced. GitLab's documentation says that on Free, anyone with the Developer role can approve, but approvals are optional and do not prevent merging without one. Required approval rules, which block merging, are in Premium and Ultimate. Evidence is only as strong as the enforcement behind it.
Optional versus required
| Plan | Behavior per GitLab documentation |
|---|---|
| Free | All users with at least Developer role can approve, approvals are optional and do not prevent merging |
| Premium, Ultimate | Required approval rules by number and type of approver, code owners, instance and group settings |
If a control states that every change is peer reviewed, optional approvals leave a hole. A merge without approval is allowed and leaves no signal other than the absence of one.
What required approvals can do
Per the documentation, required approvals can enforce review of all merged code, specify reviewers and a minimum number, define categories such as backend or database, use the CODEOWNERS file, and require approval for declining test coverage. On Ultimate, you can require security team approval for potential vulnerabilities.
How to build the evidence
- Open Settings, then Merge requests, then the approvals section on a project.
- Set a rule with at least one required approval, and name the approvers.
- Add code owners for sensitive paths such as authentication and deployment configuration.
- Check the merge request page: the approval status appears in the widget, and the list views show it per merge request.
- Pull the approval rules with the merge request approvals API and save them monthly.
- Sample five merged requests each month and note approver, time and whether the approver differed from the author.
If you are on Free
You can still build a reasonable control with discipline, but say so honestly:
- Make the team agreement written.
- Sample merged requests regularly and record the result.
- Treat any unapproved merge as an exception with a note.
Do not describe approvals as "required" when the product setting is optional. An auditor will read your configuration, and mismatched wording is an avoidable finding.
Worked example
Say your control states that every change to the payments service is reviewed by someone other than the author. On a Premium project you set a rule requiring one approval and add a code owner for the payments folder. Each month you save the approval rules from the API and sample five merged requests. The saved rules show the control was configured, and the sample shows it operated. On a Free project the same sentence in your policy would rest on habit alone, so the sample would need to be larger and every unapproved merge would need an explanation.
For the GitHub equivalent, read pull request approvals as change evidence.
Try it yourself
Click through it at your own pace, or open it full screen. Watch which result blocks a merge and which only warns.
Where Safeguard fits
Safeguard provides policies, gates and guardrails on pull requests and compliance and evidence automation. A free scan covers dependencies.
Quick check
Can Free tier approvals block a merge?
No. The documentation says Free approvals are optional and do not prevent merging without approval.
Can code owners be required reviewers?
In Premium and Ultimate, yes, the CODEOWNERS file can determine reviewers for required approvals.
Sources
Last reviewed: 19 October 2026.
