Why GitLab compliance frameworks decide how controls reach every project
A regulated team that runs dozens or hundreds of GitLab projects usually needs the same change controls everywhere: two reviewers on protected branches, no self-approval, and a record that the rules were applied. Relying on each project owner to configure these settings correctly does not produce that consistency, and it does not produce evidence an assessor will accept. In GitLab Ultimate, the compliance center is where a central team defines the controls once and sees where they are not met. Compliance frameworks label groups or projects with a standard or internal control set, standards adherence reports show whether each project follows the associated requirements, and violations reports list the specific merge requests or settings that fell short. Merge request approval policies then enforce the rule itself, so a change that breaks it cannot merge without the required approval.
These features are configuration and reporting inside the platform. They do not make an instance compliant, and they do not replace an audit, attestation or certification by an independent body. What they do is make the control state visible and repeatable, which is the part most assessors ask to see. A team needs them when the same control must hold across many projects, when project owners should not be able to weaken it, or when someone outside engineering must review the results. A small team with a few projects and one reviewer usually does not. Before committing, confirm with GitLab which framework templates and report fields your edition provides, since the exact controls available change between releases.
The GitLab pricing page places compliance features under Ultimate, which is custom priced, so the cost question is a quote question. Ask the vendor or partner to price Ultimate for your user count and to state in writing which compliance capabilities are included. GitLab Free costs 0 dollars and Premium costs 29 US dollars per user per month billed annually, and the pricing page notes that all three tiers are available for self-managed installations, so you can run the platform under a lower tier while you decide. Confirm that the compliance features you need are not available only in a higher add-on, and budget for the people who will define the framework controls and review the reports, since those roles recur after the initial build.
Which Ultimate and Premium controls fit which control objective
This table maps common control objectives to the GitLab feature that usually supports them, the tier the feature is associated with, and what to verify before relying on it. Use it to scope edition choice early, because the tier named here often decides whether a control is available at all. Confirm every tier against the current GitLab pricing page and the feature documentation for your release before you commit to a design.
| Control objective | What the feature is for | Tier to confirm | What to confirm before relying on it |
|---|---|---|---|
| Compliance frameworks and labels | Tagging projects with a framework so that policies and reports apply to the right set of repositories | Ultimate, per the pricing page's compliance features listing | Which frameworks are predefined, whether custom frameworks are supported in your release, and how labels follow projects after transfer |
| Standards adherence reporting | Showing which projects meet the controls attached to their framework | Ultimate, per the pricing page's compliance features listing | What each adherence check actually tests, and whether the report is sufficient evidence for your assessor or needs supplementing |
| Violations reporting | Listing merge requests or pipelines that bypassed or broke required controls | Ultimate, per the pricing page's compliance features listing | How the report is filtered and exported, its retention, and whether it covers approvals overridden by administrators |
| Merge request approval policies | Requiring specific approvers or approval counts for changes to protected or regulated projects | Ultimate, per the pricing page's compliance features listing | Whether policies can be enforced at group level and inherited, and how they behave on forks and scheduled pipelines |
| Security policies | Enforcing scanner configuration and scan execution across projects in a group | Ultimate, per the pricing page's security feature listing | Which scan types the policy covers, runner requirements, and whether offline instances need separate scanner setup |
| Separation of duties: blocking self-approval | Preventing authors and committers from approving their own changes | Premium, per the sibling documentation on merge request approval settings | Whether the setting is configured at instance, group or project level, and whether it applies to all approval rules |
| Separation of duties: locking approval rules | Stopping project maintainers from editing the approvers for protected branches | Premium, per the sibling documentation on merge request approval settings | Which settings the lock covers and who can still change them, including instance administrators |
| Electronic signature for approvals | Requiring re-authentication before an approval is recorded | Premium, per the sibling documentation on merge request approval settings | Which authentication methods qualify for your signature standard and whether your assessor accepts this as the signature control |
How to set up compliance frameworks step by step
This sequence takes a self-managed GitLab instance from a confirmed tier to a tested set of framework labels and approval controls, with evidence collection in place before an assessment begins. Each step closes with a check your team can repeat.
Confirm the tier and license on the instance
Before any design work, confirm which edition and subscription tier your self-managed instance runs. Compliance frameworks, violations reporting and merge request approval policies sit in the Ultimate tier according to GitLab's pricing page, while some separation of duties settings appear in Premium, so map each control to the tier that provides it. Ask the GitLab account team or your licensing owner to confirm in writing what your subscription covers. Done when the licensed features list on your instance matches the controls in your plan.
Map control objectives to enforceable GitLab controls
Your compliance, security and audit leads list the control objectives the framework requires, such as independent review of production changes or protection of the default branch. For each objective, identify whether GitLab can enforce it directly, whether it needs a process around it, or whether it sits outside GitLab entirely. Record the mapping in a shared register that names an owner for each row. Done when every objective has one of the three outcomes and an owner, and the register has been reviewed by the people who will answer for it at assessment time.
Design the group and project structure
Decide which groups and projects hold regulated work, since framework labels and policies apply at the level where they are set and affect the projects beneath them. Separate regulated repositories from experimental ones where the framework requires it, and document who administers each group. Keep the hierarchy small enough that owners can explain it in one diagram. Done when a written structure exists, has been reviewed by platform and compliance owners, and each regulated project can be traced to a group that carries the intended controls.
Create and apply the compliance framework
Create a compliance framework in the instance that reflects the control register, give it a clear name and description, and attach it to the projects in scope. Applying a framework is an administrative change that affects how projects are reported, so record who made it and when. Confirm the attachment on a sample of projects by opening each one and checking that the framework label is present and correct. Done when every in-scope project shows the framework and no out-of-scope project carries it by mistake.
Define approval policies and separation of duties settings
Translate the approval and separation requirements into merge request approval policies and project approval settings. Decide who may approve, whether authors and committers may approve their own changes, whether approval rules can be changed by project maintainers, and which changes must be reviewed again after new commits. Write each decision next to the control objective it serves. Done when each separation of duties requirement in the register points to a named setting or policy, and the security owner has signed off the decisions.
Test on non-production projects
Build a test group with sample projects that mirror the regulated structure. Attempt the actions the controls should block, such as merging a change without the required approver, approving your own change, or pushing directly to a protected branch, and confirm each attempt fails as designed. Also confirm that permitted actions still succeed so you know the rules are not too broad. Keep the test results with the test date, the instance version and the tester's name. Done when every control in the register has a passing test, and any failure has a tracked fix.
Document evidence collection and review cadence
Decide what evidence the assessor will ask for, such as the framework definitions, policy configurations, violations reports, audit events and approval records, and where each is exported or retained. Set a review cadence for access rights, framework attachments and policy changes, and name the person who runs each review. Coordinate with your auditors on the form they accept, because DeployOpen prepares evidence and controls but independent auditors issue any attestation. Done when an evidence index lists each artifact, its source, its owner and its review date, and a first review has been completed and recorded.
Separation of duties risks to design out before go-live
Separation of duties usually fails at the edges: a single author who can approve, a project that sits outside the policy, or an approval that survives a change nobody reviewed. The cards below cover six parallel risks in a self-managed GitLab instance, each with the design response and the check that shows the response is working.
Authors approving their own changes
A developer who writes a merge request and also approves it removes the second pair of eyes the control depends on. Design the approval rule so the author cannot count toward required approvals, and block committer approvals as well where your change process requires it. Check this by opening a test merge request as the author and confirming the approve action is unavailable or does not satisfy the rule. Confirm the exact setting names and tier with GitLab's current approval documentation before you write the standard.
Project owners weakening inherited policy
Policies set at the instance or group level are only useful if a project maintainer cannot override them. Decide which settings must cascade from the top and which may be delegated, and document that boundary before teams are onboarded. Check it by signing in as a project owner, attempting to remove or relax an inherited approval rule, and recording whether the change is blocked. Ask GitLab to confirm which approval settings can be locked at a higher level in your edition.
Approval rules changed without review
An approval rule that can be edited silently by its owner gives auditors no evidence about who lowered the bar and when. Treat rule definitions as controlled configuration: limit who can edit them, require a second person for changes, and keep the history. Check this by changing a test rule and confirming the change appears in the audit trail and triggers the review step you defined. Your own change management record should show the same event.
Approvals surviving new commits
An approval given to a reviewed version of a branch should not carry over to code pushed afterward. Decide whether approvals reset on new commits for each protected branch, and accept that some teams will find this slows review. Check it by approving a merge request, pushing an additional commit, and confirming the approval count drops to zero or the rule requires a fresh review. Record the setting in the approval standard so the behavior is not left to project defaults.
Administrators bypassing policy
Instance administrators can often reach projects and settings that approval rules do not govern, which makes them a standing separation of duties risk. Define which administrative actions require a change ticket and a second approver, and keep administrator accounts separate from daily developer accounts. Check this by reviewing the list of administrators and reconciling it with the change records for the period. Ask your assessor how they want administrator activity evidenced before you rely on any single control.
Projects outside the framework
A repository created outside the policy scope, or imported without the framework applied, is where controls quietly stop applying. Use compliance frameworks to label in-scope projects and check the population regularly against the group structure. Check it by listing all projects under the scoped groups, confirming each carries the framework label, and investigating any that do not. Import and migration work often creates these gaps, so reconcile after each batch rather than once at go-live.
Choosing between Premium approval settings and Ultimate policies
This fits a team whose main requirement is separation of duties on merge requests: no one approves their own change, and approval rules stay fixed for the audit period. The Premium tier includes the approval settings auditors most often ask about, so check it first before considering a higher tier for this need.
- Author and committer blocking: Confirm that the setting blocking authors and committers from approving their own merge requests is available on Premium for your self-managed version.
- Locked approval rules: Confirm that approval rules can be locked so project maintainers cannot edit or remove them.
- Approvals on new commits: Check how removing existing approvals when new commits are pushed behaves in your branch workflow.
- Instance-level cascade: Confirm which settings flow from instance to group to project, and whether lower levels can override them.
- Upgrade effect: Ask GitLab whether approval settings configured on Premium carry over unchanged after an upgrade to a higher tier.
Before buying, check these behaviors against the GitLab documentation for the version you will run, because approval settings change between releases.
This fits an organization that must show the same controls across many projects and wants evidence of violations without assembling it by hand. Compliance frameworks, framework-wide merge request approval policies and violations reporting are the capabilities that depend on the Ultimate tier, so this tab is for teams that need them enforced centrally.
- Compliance frameworks: Confirm how a framework is defined, attached to projects and applied to every project carrying it.
- Violations reporting: Ask GitLab for a sample violations report so you can see what evidence it produces and which roles can view it.
- Policy enforcement: Confirm that policies set at group or instance level cannot be overridden by project owners.
- Standards mapping: Frameworks help organize controls, but neither GitLab nor DeployOpen issues certifications or audit reports. Auditors decide whether the evidence is sufficient.
- Quote basis: Ultimate is custom priced, so request a quote from GitLab with your user count and the list of features in scope.
Write the required control list before the quote conversation, so the price reflects the features you will actually configure.
This fits an organization where a regulated business unit needs framework-wide policies while other groups only need approval blocking and locked rules. Both can sit on one self-managed instance, but the boundaries between them need to be planned before licenses are assigned.
- Licensing scope: Confirm with GitLab whether mixed tier features are supported under one instance, and how licenses map to groups and users.
- Policy inheritance: Find out whether instance-level policies reach Premium groups, and what happens when a Premium group sits beneath a group with framework policies.
- Per-user cost: Premium is listed at 29 US dollars per user per month billed annually on the GitLab pricing page, so count users by group before deciding where each one sits.
- Settings map: Document which approval settings each Premium group keeps, so the boundary is visible to auditors.
- Evidence gaps: Violations reporting covers only the Ultimate groups, so plan a separate evidence process for Premium groups.
Ask GitLab to confirm each of these points in writing, and test the inheritance behavior in a non-production group before any policy goes live.
What to confirm in your environment before promising audit evidence
Compliance evidence from GitLab depends on four things: the edition and license you run, the release you are on, where the evidence is stored, and how your deployment is isolated. Each item below is a check to complete with your assessor and your own platform team before you describe any control as in place.
Features available in your edition
Confirm that every compliance feature you plan to cite is included in the tier you license. GitLab's pricing page places compliance features and merge request approval policies under Ultimate, while Premium carries separate approval settings. Ask for a written list of features per tier for your exact GitLab version, and check whether any feature needs an add-on. Do not assume a Free or Premium instance can produce a control that exists only in Ultimate.
Policy behavior across upgrades
Required upgrade stops mean you will not move directly between every release, and each stop can change how policies, approval rules and compliance frameworks behave or are displayed. Before each upgrade, read the release notes for the versions you pass through and retest a sample of policies in staging. Record which configuration you validated so the evidence you present matches the version in production.
Evidence export to your GRC or SIEM
Decide where compliance evidence must live for your auditor and whether your self-managed instance can deliver it there. Identify which reports, audit events and approval records you will export, how often, and in what format, and who is responsible for the export job. Test an export end to end, including retention in your target system, before you promise the auditor a continuous evidence trail.
Air-gapped and offline controls
If the instance runs in an offline or air-gapped network, confirm that every control still works without outbound connections. Some scanners and AI features have separate offline guidance, and update channels for scanner data, licenses and packages must be carried in by hand. Document which controls change under offline operation, and test them on the isolated network rather than assuming parity with an internet-connected instance.
Framework your auditor expects
Ask your assessor which framework or standard they will test against and which control identifiers they expect you to map to GitLab settings. A compliance framework configured in GitLab is only one input; the mapping, the wording of each control and the sampling method remain the auditor's decision. Obtain that mapping in writing before you build policies, so configuration work targets the evidence that will actually be requested.
Exception handling ownership
Name the person or role who approves an exception to a policy, such as a blocked approval rule needed for an emergency fix, and who records it. Define how long an exception may last, how it is reviewed, and how it appears in violation reports. Without a named owner and a record, an auditor will treat a bypass as an uncontrolled change, so agree this process with security, engineering and compliance leadership before go-live.
What buyers ask before setting up GitLab compliance frameworks
What does a GitLab compliance framework setup cost?
The software cost depends on the GitLab tier, and the services cost depends on how much control work the scope contains. The GitLab pricing page lists Free at 0 US dollars, Premium at 29 US dollars per user per month billed annually, and Ultimate as custom priced, with compliance features listed for the top tier. Services cost is driven by the number of projects and groups, the evidence you must produce, the number of frameworks, and whether existing policies must be migrated. Ask any quote to separate one-time work (design, policy build, evidence mapping) from recurring work (policy reviews, evidence collection, upgrades). Ask for the written scope and assumptions behind each line.
How long does a compliance framework rollout take?
The duration depends mainly on how many groups, projects and frameworks are in scope, how mature your control inventory is, and how many approval paths must be tested. No standard duration applies to every organization, so ask for a timeline in the written scope. If your instance must first move to a current version, plan for required upgrade stops. The GitLab upgrade paths documentation lists stops at versions x.2, x.5, x.8 and x.11 since 17.5, so an older instance may need several upgrade steps before compliance work begins. Ask for milestones that include testing with your evidence owner.
What must our team provide before compliance work starts?
Your team must provide a control inventory, a group and project structure, named control owners, and an evidence owner who accepts the records produced. Without these, policies cannot be scoped or tested. You should also provide administrator access to the instance, a list of approvers and their roles, and a decision on who may change compliance frameworks after go-live. Clear answers to who signs off on separation of duties are needed early, because approval rules depend on them. Confirm these inputs with your compliance lead before the scope is agreed.
Can our internal team set up GitLab compliance frameworks without a partner?
An internal team can set up compliance frameworks if it has GitLab administration skills, access to the right tier, and time to map controls to group and project settings. The work usually needs people who understand your control catalog, the GitLab permission model, and how approval rules affect merge requests. The trade-off is staff time and the risk of gaps when the people who designed the setup move on. A partner can take on the design, build and documentation, while your team keeps ownership of the policies. Compare both options against the same written scope.
Does DeployOpen issue audit reports for our GitLab environment?
No. DeployOpen does not issue audit reports, attestations or certifications. DeployOpen prepares systems, controls and evidence for compliance assessments, including configuring frameworks, approval policies and evidence collection in your infrastructure. Independent auditors and certification bodies perform the assessment and issue any report. Ask your auditor which evidence formats and sampling they expect before the build starts, so the configuration produces records they can review. Compliance outcomes depend on your control design, operation and the assessor's findings.
How should we change compliance policies after go-live?
Treat compliance policy changes as controlled changes with a written reason, an owner, a test step and an evidence record. Make changes in a non-production group first, record the approval, and confirm the effect on separation of duties before applying the change to production groups. Review changes after each GitLab upgrade, because release behavior can change. The GitLab maintenance policy describes a minor release on the third Thursday of each month and patch releases twice a month, so plan a regular review window. Ask the partner to include a change procedure and a handover of these steps in the scope.
How DeployOpen works on this
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, including self-managed GitLab. For compliance center and framework work, we start from the controls your assessors expect, then configure the GitLab features that enforce them and collect the evidence they will ask for.
How we scope
- Engagements are fixed-scope, with the framework, projects, groups and approval rules agreed in writing before work starts.
- Scope names which GitLab tier features are in use, since compliance frameworks and approval policies depend on Ultimate.
- Confirm with your assessor which controls must be evidenced from GitLab and which come from your own processes.
How we build
- We configure compliance frameworks, labels and pipeline requirements so that framework membership is applied consistently across projects.
- Merge request approval policies are built and tested against separation of duties rules, including author and committer approval restrictions.
- Each control mapping is tested in a non-production instance before rules are applied to production groups and projects.
How we hand over
- Handover includes configuration documentation, the control-to-setting mapping, and steps for reviewing violations reports.
- We document how to export compliance and audit data so your team can supply it to independent auditors.
- DeployOpen prepares systems, controls and evidence for assessments but does not issue audit reports or certifications.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, covering policy changes after each GitLab release.
- Retainers can include review of new approval rules before they reach production groups.
- Ask for the support level, response expectations and upgrade handling in the written quote before work begins.
