GitLab for SOC 2 change management

How GitLab supports GitLab for SOC 2 change management

GitLab merge requests, approvals, protected branches and pipelines can hold much of the evidence a SOC 2 examination asks for under CC8.1, but the auditor, not DeployOpen or GitLab, decides whether those controls are sufficient. If your organization is a service organization preparing for an examination, start by treating the GitLab instance as a candidate system of record for change management, then confirm with your auditor which records they will accept and how they will sample them. SOC 2 examinations use the AICPA's 2017 Trust Services Criteria (TSC), in the version with revised points of focus published in 2022. The five categories are security, availability, processing integrity, confidentiality and privacy. The security common criteria CC1 to CC9 apply to every SOC 2, so change management is in scope whatever other categories you add. CC8.1 is the only criterion in the CC8 Change Management series, but it is broad: it covers every stage of a change to infrastructure, data, software or procedures, from authorization and design through testing, approval and implementation. Points of focus are characteristics that help you design and evaluate controls, not separate requirements, so you do not need to address every one of them. DeployOpen plans, configures and documents the GitLab environment and prepares the evidence it produces. DeployOpen does not issue SOC 2 reports, attestations or opinions. Those come from a CPA firm performing the examination, and management's description of the system is prepared against the AICPA's 2018 description criteria. Before you build anything, ask your auditor whether they expect a Type 1 or Type 2 report, since a Type 2 examination tests operating effectiveness over a period and will need GitLab records that were kept consistently throughout that window.

Mapping CC8.1 stages to GitLab capabilities and configuration

This table pairs each CC8.1 change stage with the GitLab capability that can produce its evidence and the settings needed to make that evidence reliable. Rows marked with a tier note depend on Premium or Ultimate features, so confirm tier fit against your edition before relying on a row. Use it as a design checklist for your own change process, not as a statement of what an assessor will accept.

CC8.1 stage	GitLab capability	Configuration to set	Tier dependency
Authorization	Issues linked to merge requests	Require every merge request to reference an approved issue or change ticket; use a description template that asks for the reason and risk	Not applicable
Design	Merge request descriptions and linked design documents	Store design notes in the repository or wiki; add a merge request template with design and rollback sections	Not applicable
Development	Feature branches and merge requests	Block direct pushes to the default branch through protected branches; require at least one reviewer who is not the author	Not applicable
Configuration	Merge request approval rules and CODEOWNERS	Define approval rules by path (for example, infrastructure or pipeline files); assign code owners for each owned area	Approval rules are available on Free; confirm multi-level and enforced rules against your tier
Documentation	Merge request templates and changelog entries	Require documentation fields in the template; link release notes or runbook changes to the merge request	Not applicable
Testing	CI/CD pipelines and job logs	Make test, security and lint jobs required status checks before merge; retain pipeline records for your evidence period	Advanced CI/CD features are listed for Premium; security scanning for Ultimate
Approval	Protected branches and approval records	Restrict who can merge and who can push; keep approval history visible on each merge request; disable self-approval where your tier allows	Some approval controls are Premium or Ultimate features; confirm on the pricing page
Implementation	Protected environments and deployment jobs	Limit who can deploy to production and require approval for production jobs; run deployments from pipelines only	Protected environments and deployment approvals are typically Premium or Ultimate; confirm
Emergency change	Expedited merge path with audit trail	Define a documented emergency procedure with a named approver; require a follow-up review after merge; review audit events for bypasses	Audit event coverage varies by tier; confirm which events your edition records

Which GitLab records an auditor can sample

An auditor testing change management will ask for a sample of changes and trace each one from authorization to deployment. The records below are the GitLab objects that let you do that trace, and each needs an export and retention procedure that your team defines and assigns an owner to.

Merge request history and approvals

Each merge request records the proposed change, the author, the reviewers, the discussion thread, the commits and the approvals given before merge. This is usually the primary authorization and review evidence for CC8.1. Check that approval rules name who must approve, that authors cannot approve their own changes, and that the approval record survives squash or rebase. Export a sample of merged requests with their approval state as part of your testing package.

Protected branch and environment settings

Protected branch and protected environment settings show who can merge, push or deploy to sensitive paths such as the default branch and production. An auditor will compare the configured rules against the stated change policy. Store the settings as configuration baselines under version control where your tooling allows, and capture a dated export each review cycle so you can show what the rules were during the audit period, not only today.

Pipeline results

Pipelines show which automated tests, scans and build steps ran against a specific commit, and whether they passed. They are the testing evidence that CC8.1 expects before implementation. Confirm that required pipelines gate merges and that the job logs and artifacts for sampled changes are retained long enough to be pulled. Ask your auditor which pipeline outputs they want kept as attachments rather than only as a pass or fail status.

Audit events

Audit events record administrative and security-relevant actions, such as permission changes, protected settings edits and membership changes. They show whether the controls you describe were changed without approval. Decide which audit event streams you will export, where they are stored outside the instance, and who reviews them. Confirm with your GitLab edition and documentation which events are captured for your version before you promise coverage in the system description.

Issue links and deployment records

Linking merge requests to issues, change tickets or incident records connects each change to its business reason, and deployment records tie a change to the environment where it ran. Together they let an auditor follow one change from request to production. Define the linking convention in your change procedure, for example a required ticket reference in the branch name or merge request template, and check that deployment records are kept for production environments.

Retention and export procedure

GitLab keeps much of this evidence in the instance, and a backup or a server failure can lose it if it is not exported on a schedule. The team must write down what is exported, how often, in what format, where it is stored and how long it is kept, and must align that with the audit period and your own policy. Assign an owner, test a restore of the exported evidence and record each export so you can show it was complete.

Standard, urgent and emergency changes under one GitLab process

A standard change is the normal path: a developer opens a merge request, the pipeline runs its tests and scans, reviewers approve, and the change merges to a protected branch and deploys. GitLab records most of the CC8.1 stages as the work happens, so the evidence is produced by the workflow rather than assembled later. The merge request holds the description, the linked issue, the diff, the review discussion and the approval history. The pipeline holds the test results, the job logs and the commit it ran against. The deployment job links back to both.

Authorization: The linked issue or ticket records why the change was requested and who accepted it into the backlog.
Testing: Pipeline jobs for unit, integration and security tests are attached to the exact commit that was merged.
Approval: Approval rules on the project define who must approve, and the approval record shows who approved which commit.
Protected branches: Restrict who can push and merge to the main branch so no change bypasses the merge request.
Deployment record: Protected environments show who triggered the production deployment and when.

Check that approval rules cannot be edited by the same people who approve changes, and that the audit events for these settings are retained for the full audit period.

Configuring GitLab so change records hold up to sampling

This sequence turns GitLab settings into a change record that an auditor can trace from authorization through testing, approval and deployment. Each step names the owner, the configuration and the artifact that proves it worked. The result is a repeatable set of records for CC8.1 sampling, including emergency changes.

Define the change policy and control owners
Before touching GitLab, management writes the change management policy and names who authorizes changes, who approves merge requests, who administers the instance and who owns production environments. Each owner is recorded by role and named person, with a backup for each role. The output is a signed policy and an owner register that the GitLab configuration in later steps can point to. Ask your SOC 2 auditor which description of the system and which control wording they expect to see mapped to these roles, since the policy is the first thing sampled.
Protect branches and require separate approvals
Configure protected branches on the default and release branches so that direct pushes and force pushes are blocked. Set merge request approval rules that require at least one reviewer who is not the author, and make sure the people who can push to production branches are not the same people who approve their own work. Document the approval rule set and export the protected branch settings as a baseline. Done means a test merge request by an author cannot merge without an independent approval, and that test is kept as evidence.
Require pipelines and security jobs before merge
Make a passing pipeline a merge condition, and include the test stages and the security scanning jobs your tier supports in that pipeline. Confirm which scanners your edition includes, since the pricing page separates the features available per tier. Pipeline results are retained as job logs and artifacts that show what was tested against which commit. Done means a merge request with a failing test or blocking scan cannot be merged, and the pipeline record for an approved change is linked to that merge request.
Configure protected environments for deployments
Define production and other sensitive environments as protected, with deployment approvers limited to the roles named in the policy. Deployment jobs then wait for an authorized approver, and the approval is recorded against the environment. Keep developer accounts from holding deploy rights in production, and check the deployment history against the owner register. Done means a deployment to production by an unauthorized account is rejected, and each production deployment shows who approved it and which pipeline produced it.
Link issues to merge requests
Require every change to reference a tracked issue or change ticket, using a consistent naming convention in merge request titles or a required template. The issue holds the business reason, the risk assessment and the test plan, and the merge request holds the code and review. Confirm the link is kept when the merge request is closed. Done means a sample of merged changes can be traced from the production deployment back to the authorization record, without relying on memory or chat history.
Set a recurring audit event review
Identify the audit events that show change activity, such as changes to protected branch rules, approval rules, member roles and environment settings, and decide who reviews them and how often. Export or forward these events to your log platform so they are kept outside the instance. Record each review with a date, the reviewer and any exceptions raised. Confirm with your auditor how the review interval will be defined in the control description. Done means the review log shows that someone outside the change path checked settings changes and followed up on anything unexpected.
Rehearse an emergency change
Write the emergency change procedure, covering who can declare an emergency, how the change is authorized after the fact, which approvals still apply and how the fix is back-ported to the normal branch. Run a rehearsal on a non-production project, then review the resulting merge requests, pipelines, deployment approvals and tickets. Note any gap, such as an approval that could not be obtained in time, and update the procedure. Done means the rehearsal produces a complete record set, and the lessons learned are filed with the policy so that a real emergency follows the same path.

What GitLab does not cover for SOC 2

GitLab records what happens to code and pipelines, but a SOC 2 change management control spans more than one repository. The cards below mark where GitLab evidence stops and where the organization must supply its own policy, process and records.

The change policy stays yours

GitLab enforces the approval rules you configure, but it does not write the change management policy that defines who may authorize a change, what risk levels need review and how exceptions are granted. Auditors will compare the configured merge request approvals against that written policy. Check that every approval rule in your projects maps to a clause the policy actually states, and that the policy names an owner who reviews it on a schedule you set.

Infrastructure changes outside GitLab

Changes to cloud accounts, network devices, firewall rules and identity settings made through consoles or vendor portals never pass through a merge request unless you route them there. Inventory every channel that can alter production and decide, for each one, whether it is managed as code in GitLab or excluded from the change population. Undocumented channels are where the change inventory most often fails.

Manual changes on hosts

SSH sessions, ad hoc package updates and hand edits to configuration files on servers leave no pipeline record. GitLab can show that a deployment ran, but not that an administrator changed a file afterward. Consider how host access is granted and logged, whether configuration management detects drift, and how emergency host access is reviewed after the fact.

Data changes and schema edits

Database updates, data corrections and bulk record changes usually run through scripts, runbooks or database tools that sit outside the repository approval flow. CC8.1 expects changes to data to be authorized and tested like other changes, so define which data changes must be committed as reviewed scripts, and which tools are permitted to execute them against production.

Ticketing and CAB processes

If your organization runs a change advisory board, a service desk workflow or a risk assessment form, those records remain in the ticketing system. GitLab does not replace them or link them automatically. Decide which identifier ties a merge request to its ticket, make the link mandatory in templates where possible, and confirm which system the auditor will treat as the authorization record.

People, the description and other categories

Operating effectiveness depends on people following the process consistently over the audit period, and no tool enforces that alone. Your organization also writes the SOC 2 system description and decides which Trust Services categories are in scope beyond the common criteria. Plan periodic access reviews, training and management oversight, and confirm the scope and description with your auditor before relying on GitLab evidence.

What GitLab SOC 2 change management work costs and needs

What drives the effort of GitLab SOC 2 change management work?

The main drivers are the number of repositories and pipelines in scope, the number of environments that change control must cover, the tier and features you choose, how many ticketing or deployment systems feed approvals, and whether evidence must be rebuilt for past changes. A small set of repositories with one production environment and a clear branch model is far simpler than dozens of services with separate staging, production and infrastructure repositories. Retrofitting evidence for changes already made usually takes more effort than configuring controls for new work, because records from before the controls existed may be incomplete. Ask for a quote built from a written inventory of repositories, environments, approval paths and the audit period your auditor will examine.

Is the GitLab Free tier enough for SOC 2 change management?

GitLab's pricing page lists Premium and Ultimate features, including advanced CI/CD and priority support for Premium, and application security testing, software supply chain security, vulnerability management and compliance features for Ultimate. Whether Free covers your needs depends on which controls you must evidence, such as required approvals, protected branches and environment protections, and on how your organization wants to manage reviewers and audit records. Confirm each control you plan to rely on against the current pricing page and the feature documentation for your version. Make that list before you choose a tier, and check it again with your auditor, since the auditor decides what evidence is sufficient.

How long does GitLab SOC 2 change management work take?

The duration depends on the scope and on the audit period, not on a fixed figure. A Type 1 review looks at control design as of a date, while a Type 2 report covers operating effectiveness over a period, so the length of time your controls must run before the examination shapes the schedule. Configuration work is usually shorter than the time needed to show that controls operated consistently. Agree the timeline in writing as part of a fixed scope, and confirm the observation window with your auditor before setting dates.

Can our team implement GitLab SOC 2 change management on its own?

Yes, a capable team can configure merge request approvals, protected branches, protected environments and pipeline gates itself, provided it has someone who understands both GitLab administration and the change control requirements. The harder parts are usually agreeing on the approval matrix, deciding which changes are standard, normal or emergency, and writing procedures that match what engineers actually do. Teams often underestimate the time needed to test emergency change paths and to collect evidence consistently across many projects. DeployOpen can plan, configure and document this work as a fixed-scope engagement if you prefer a partner, and your team keeps ownership of the procedures and the instance afterward.

What does GitLab SOC 2 change management need from our staff and auditor?

The work needs named owners from engineering, security or compliance, an administrator for the self-managed instance, and people who approve changes in production. Engineering leads must agree on the approval matrix and emergency procedure, and the team that runs infrastructure must confirm how deployments reach each environment. Your auditor should review the control design and the evidence you plan to produce before the observation period starts, because changing the approach midway creates gaps. Ask the auditor which records they will request, such as merge request history, approval records, pipeline results and audit events, and confirm that your instance retains them long enough.

What does GitLab SOC 2 change management cost to run after launch?

Some costs are one-time, such as design, configuration, documentation and testing of the change path. Others recur, including GitLab subscription fees for the tier you choose, infrastructure and storage for the instance and its backups, runner capacity, staff time to review access and approvals, and periodic upgrades. GitLab's upgrade paths require stops at specific versions, so plan that work into your recurring effort. Ask any partner to separate one-time and recurring costs in the quote, and ask your team to estimate its own review time for each quarter.

Does DeployOpen certify GitLab SOC 2 change management or issue a SOC 2 report?

No. DeployOpen plans, implements, documents and supports self-hosted GitLab inside your own infrastructure, and it prepares systems, controls and evidence for compliance assessments. It does not issue audit reports, attestations or certifications. A SOC 2 report is produced by an independent CPA firm that performs the examination, and the report is issued to your organization by that firm. Confirm the auditor's requirements early, because the evidence you prepare must match what the examination will test.

How auditors use GitLab evidence in a SOC 2 examination

Management's description of the change process is itself audited evidence. A SOC 2 examination is an assertion-based engagement under AT-C section 205, and the service auditor obtains written representations from management before issuing a report. Those representations cover the system description, so the way your change process is written down must match what GitLab actually enforces: who can open and approve a merge request, which branches are protected, which pipeline jobs gate a merge, and how emergency changes are recorded. If the description says every production change has an independent approval but the approval rule can be bypassed by project maintainers, the auditor will find that gap before you do. Before the examination starts, confirm each sentence in the description against a current project configuration export and the audit event log, and assign an owner to re-check it when the GitLab configuration changes.

A Type 2 examination tests a sample of changes across the whole period. A Type 1 report looks at the design of controls as of a date. A Type 2 report adds an opinion on operating effectiveness over a period, which means the auditor selects individual changes and asks for the full chain: the requirement or issue, the merge request, the reviewer approvals, the pipeline results, the deployment record and any exception. Each piece of that chain has to be complete, unaltered and traceable to the others. In practice, that means keeping merge requests and approvals inside GitLab rather than in chat threads, ensuring that squash or rebase operations do not erase the approval history your reviewers relied on, and retaining audit events long enough to cover the full period plus the auditor's fieldwork. Ask your auditor early which sample populations and retention periods they expect, because those answers decide how you configure log export and backup.

Treat the report as restricted, and confirm the standards timeline with your auditor. A SOC 2 report is generally restricted in use to the service organization, its customers and their auditors, unlike a general-use SOC 3 report, so decide in advance who receives the report and under what terms. The AICPA Auditing Standards Board proposed revisions to its baseline attestation standards in February 2026, and the Journal of Accountancy reports that, if adopted, they would apply to engagements beginning on or after June 15, 2029. Your current engagement is not covered by that date, but a multi-year relationship with an audit firm should include a conversation about how the proposals might affect evidence requests, so your GitLab retention and export design does not need to be rebuilt later.

How DeployOpen scopes and delivers GitLab change evidence

DeployOpen plans, implements, hardens, documents and supports self-hosted GitLab inside your own infrastructure, so the change records you rely on stay under your control. For SOC 2 change management, we start from how your change process is meant to work and build the GitLab configuration and evidence trail around it.

How we scope

We review your current change process, approval roles and which systems fall inside the SOC 2 system description.
The written scope names the projects, protected branches, approval rules and pipeline stages that will be configured.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.
We confirm with your auditor which evidence they expect to sample, so the scope reflects what will be examined.

How we build

We configure protected branches, merge request approval rules and separation of duties to match the agreed change policy.
Pipelines are set up to record test results, and emergency change paths are defined with their own approval and review steps.
We test the controls by attempting unapproved merges and direct pushes, and record what GitLab blocked.
Audit events and retention settings are checked so the records needed for a review period are kept.

How we hand over

You receive configuration documentation covering approval rules, branch settings, pipeline definitions and runner ownership.
A control-to-evidence map shows which GitLab records support each stage of the change lifecycle.
Your team gets a walkthrough of how to pull merge request, approval and pipeline evidence for an auditor request.
We document what GitLab evidence cannot show, so gaps are owned by your team and not discovered during the examination.

How we support

Ongoing support is available as a retainer for GitLab upgrades, configuration drift checks and runner maintenance.
Upgrade planning follows the required upgrade stops, so control settings are reviewed at each planned stop.
We can rerun control tests after significant configuration changes or before an examination period begins.
Support scope, response expectations and fees are confirmed in writing, and no price is set until the scope is agreed.