GitLab for ISO 27001 change control and secure development

Which ISO 27001 change controls GitLab evidences and which it leaves to you

If you own the ISMS and need change records from GitLab for an ISO 27001 certification audit, start by separating two things: the technological controls that GitLab can produce evidence for, and the organizational controls that no tool can satisfy for you. ISO/IEC 27001:2022 Annex A lists 93 controls in four themes, and the change and secure development controls sit mainly in the technological theme, clause 8. GitLab's merge requests, protected branches, pipelines and audit events can show that changes were proposed, reviewed, tested and recorded. They cannot show that your change policy exists, that it was approved by management, or that staff were trained to follow it. Remember also that ISO does not certify organizations. Accredited certification bodies do, and they decide what evidence is sufficient. DeployOpen prepares the GitLab configuration, controls and evidence for that assessment, but it does not issue audit reports, attestations or certificates.

The evidence depends on your edition. Audit events for groups and projects require the Premium or Ultimate tier, and they are retained indefinitely, with CSV exports in UTC. The approval settings that matter for change control, including blocking author and committer approvals and requiring re-authentication to approve, are also a Premium feature. GitLab describes that re-authentication as an electronic signature for approvals. Confirm with your GitLab sales contact and the current pricing page which features your chosen tier includes, because security and compliance features are split between Premium and Ultimate. Ask your certification body early whether a re-authentication step satisfies their view of approval records, since that is their judgment, not GitLab's.

Several things stay with your organization regardless of tooling. You must define the change management process and its risk classes, decide who may approve which kinds of change, handle emergency changes and their after-the-fact review, and keep the link between a change record and the affected asset or service in your asset inventory. You also own access reviews for maintainer and owner roles, the separation of duties between developers and production, and the retention and review of audit logs outside GitLab if your policy requires it. Write these decisions down before the audit starts, because an auditor will test whether people followed them, and GitLab can only show what happened, not what you intended.

Mapping Annex A secure development and change controls to GitLab features

This table maps the Annex A technological controls most often tested for change and secure development to the GitLab settings that support them and the records an assessor can request. Control numbers follow the ISO/IEC 27002:2022 guidance and should be confirmed with your certification body, and each configuration should be verified in your own instance. The main takeaway is that approvals, protected branches and audit events count as evidence only when they are enforced and kept over the audit period.

Control	GitLab configuration	Evidence to pull	Where it usually fails
8.32 Change management (approval)	Require merge request approvals, block author and committer approvals, and require re-authentication to approve	Approval rule settings export and approval history for sampled merge requests	Approval rules overridden at project level, or self-approval left enabled
8.32 Change management (authorization)	Protect release and default branches so only named roles can merge or push	Protected branch settings with dates, plus audit events for any changes to them	Maintainers can push directly, or new branch names fall outside the protection pattern
8.31 Separation of development, test and production	Deploy to production only through protected environments and jobs run by approved roles	Environment settings, deployment job logs and the users who triggered each deployment	Developers hold production deploy rights or can read production variables
8.25 and 8.28 Secure development life cycle and secure coding	Run security scanning jobs in every merge request pipeline; confirm which scanners your tier includes	Pipeline results attached to each merge request and stored scanner reports	Scan jobs set to allow failure, so findings do not block the merge
8.29 Security testing in development and acceptance	Make required test and scan jobs block merge, and store results as job artifacts	Pipeline records and job artifacts for sampled changes across the audit period	Artifact retention shorter than the audit period, so older results are gone
8.15 Logging and 8.16 Monitoring activities	Review group and project audit events for membership, settings and protected branch changes	Audit event CSV exports with UTC timestamps, retained by GitLab indefinitely on Premium or Ultimate	Exports taken ad hoc with no review record, or the tier does not include audit events
8.4 Access to source code	Limit project membership and visibility, and review role assignments on a set schedule	Membership lists and audit events for role grants and removals	Former contractors keep developer access after offboarding

What evidence an auditor can pull from GitLab

An auditor testing secure development and change control will ask for records from several places in GitLab, and each place answers a different question. The cards below cover what each evidence class shows, which tier is needed to get it, and how to prepare it so that sampled records hold up under review.

Approved merge request history

Merge requests are the main record of what changed, who reviewed it and when it was approved. Auditors usually sample merge requests from a period and trace each one to its commits, its pipeline results and its approvals. Check that merge requests are required for all changes to the protected branches that feed production, and that the history is kept for the full audit period in the instance itself, not only in a local clone or a chat thread.

Approval rules and approver identities

An approval rule defines who must approve a change, and the audit question is whether the approvers were the people the rule required. Record the rule configuration, the approver list and the identity behind each approval. On Premium, approval settings can block author and committer approvals and require re-authentication to approve, which GitLab describes as an electronic signature. Confirm these settings are on, because an approval without them is weaker evidence.

Protected branch settings

Protected branch settings show who can push, merge and force-push to the branches that matter for release. An auditor will check the current configuration and ask for evidence that it has not drifted. Export the settings for each protected branch and store the export with the change records. Unexpected changes to these settings are a common finding, so the export should be compared against an approved baseline.

Pipeline results and scan reports

Pipeline results show that tests and security checks ran against the exact commit that was merged. Keep the pipeline record linked to its merge request, and retain the scan reports the pipeline produced. Scanner availability depends on tier: the pricing page places application security testing and related compliance features in Ultimate, so confirm which scanners your edition includes before you describe them as evidence.

Group and project audit events

Audit events record administrative and security-relevant actions, such as permission and setting changes, and they are the evidence for changes that happened outside a merge request. Audit events require Premium or Ultimate. They are retained indefinitely, and CSV exports use UTC, so state the time zone in your evidence index and align it with change tickets recorded in other time zones.

Configuration exports and periodic snapshots

Live settings change, so an auditor asking what the rules were in March needs a record from March. Schedule exports of approval rules, protected branch settings and relevant instance settings, and store them with a date and a hash in a location the development team cannot edit. Snapshots turn a current-state screenshot into a dated record that can be tested against the change log.

Presenting sampled records to auditors

Auditors select a sample from a population, so prepare a population list first, such as all merge requests merged to production in a period, then provide the records for the sampled items. For each sample, show the merge request, its approvals, its pipeline and any related audit events in one bundle. Note exceptions openly, including emergency changes and their follow-up review. Confirm the sampling approach and evidence format with your auditor before the period begins.

How approvals, protected branches and pipelines form one change record

A change in self-managed GitLab becomes reviewable evidence only when the merge request, the pipeline and the protected target branch are configured to work together. The developer pushes a feature branch, opens a merge request, and the pipeline runs build, test and security jobs against that exact commit. Required reviewers approve the merge request, and the protected target branch accepts the merge only when the configured approval rules are met and the pipeline has finished. The deployment that follows is linked back to that merge request and its commits, so an auditor can start from a production change and trace it to the code, the tests, the scanners and the people who approved it. Each link in that chain is a configuration decision you own, so the first task is to write down which branches are protected, which pipeline jobs must pass, and who is allowed to approve.

Premium approval settings let you block approvals from the merge request author and from anyone who committed to the change, and they can require the approver to re-authenticate before approving. GitLab describes that re-authentication step as an electronic signature for approvals, which gives the approval a stronger link to a named person at a specific moment than a checkbox would. Blocking author and committer approval matters because a change that its own author approves has no independent review, and the record would show a review that did not happen. Confirm in your own instance how these settings apply to inherited approval rules, to users who hold maintainer roles, and to bot accounts, since each of these can create an approval path you did not intend.

Treat these features as inputs to your change control process, not as proof that a control operates. The merge request record shows that a review and a pipeline occurred, but it does not show that the change was authorized, that the risk was assessed, or that an emergency change followed your exception process. Those points need a documented procedure, roles and retained records, which your auditor will ask for separately. Before you rely on the record, test it with a sample change, export the audit events and check that the approver, timestamp and target branch match what your procedure describes. Ask your assessor early which of these records they will accept and in what format.

Controls GitLab does not cover on its own

GitLab can produce strong records of how code changes are proposed, reviewed and merged, but an ISO 27001 certification also depends on controls that live outside the repository. The cards below set out where those gaps sit and what your own team or partner must own.

The ISMS itself

Scope, the risk assessment and treatment plan, the statement of applicability, policies and management review are organizational records that GitLab does not hold. Your GitLab change records only support the ISMS if the risk decisions behind them are documented and traceable. Check that each Annex A control you claim to cover points to a named owner and a stored document outside GitLab.

People and physical controls

Screening, security awareness training, onboarding and offboarding, and the physical protection of data centers and hardware fall under the people and physical control themes of Annex A. GitLab can show who holds a role or approval right, but it cannot show that a person was screened or trained. Confirm that access removal in your identity provider is tied to the same leaver process you evidence.

Emergency change approval

Emergency fixes often bypass the normal merge request path, through a shared administrator account, a direct push or a manually triggered deployment. Define in writing who may authorize an emergency change, how it is recorded in an issue, and how it is reviewed after the fact. Test that the record exists before an incident happens.

Production changes outside GitLab

A pipeline can be approved and merged while the actual change to production is made by hand, through a console, a configuration management tool or a vendor portal. Map every path that reaches production and decide which ones GitLab can gate. Where a change bypasses GitLab, your evidence will have a gap that auditors will test.

Vulnerability management decisions

A scanner finding is only the start. Someone must decide whether to fix, accept or defer each vulnerability, with a documented rationale, an owner and a due date. GitLab tracks findings, but the risk acceptance decisions and their approvers sit in your process. Confirm which scanners and vulnerability management features your GitLab edition includes before you write the procedure.

Supplier and offline operation

Third-party components, hosting providers, runner cloud accounts and contracted developers each need their own controls and contracts. Offline or air-gapped operation also requires separate planning, because scanner databases, container images and updates must be brought in by a controlled process. Ask your GitLab partner and each supplier for their own evidence, and confirm offline scanner support for your edition.

Configuring GitLab for an ISO 27001 change control evidence set

This sequence sets up a self-managed GitLab instance so that every production change has an approval record, a pipeline history and an audit trail that can be exported and kept under your own ISMS procedure.

Confirm the Premium or Ultimate tier
The platform owner checks the license tier on the instance before design starts. Group and project audit events require Premium or Ultimate, so a Free instance cannot produce the audit trail this evidence set depends on. Approval controls such as blocking author and committer approvals and requiring re-authentication are Premium settings as well. Confirm which tier each feature needs against the GitLab pricing page and the audit events documentation. The output is a written tier decision that names the features in use, signed off by the CISO or ISMS owner.
Set group-level approval rules and protected branches
The GitLab administrator creates a top-level group for production repositories and sets merge request approval rules there so subgroups inherit them. Protect the default and release branches so that only defined roles can merge and nobody pushes directly. Map each approval rule to the change authorization roles in your change management policy. Confirm the result by attempting a direct push to a protected branch and an unapproved merge, both of which should fail and be logged. Keep a screenshot or exported settings file as the baseline record.
Block author and committer self-approval
Enable the approval settings that stop a merge request author or a commit author from approving their own change. This is the control that separates the person who makes a change from the person who authorizes it, which auditors look for under the change management and secure development controls in Annex A. Test it with a second account that tries to approve a change it committed. The check passes when the approval is rejected and the attempt is visible to the reviewer. Record the setting in the configuration baseline.
Require re-authentication to approve
Turn on the setting that requires the approver to re-authenticate before an approval is recorded. GitLab describes this as an electronic signature for approvals, which gives you a stronger link between an approval and the named person who gave it. Decide with your identity team whether re-authentication runs through the instance password, the second factor or the single sign-on provider, and confirm that the chosen method works for every approver. The output is a tested approval flow and a short note on the authentication method used.
Require security jobs in every pipeline
Add the GitLab security scanning templates to the CI/CD configuration for protected projects and make the jobs mandatory through pipeline configuration or security policy, depending on your tier. Confirm which scanners your tier includes by checking the pricing page, because application security testing and vulnerability management are listed for Ultimate. Where a scanner is not licensed, document the compensating review step instead. The check passes when a merge request cannot reach the protected branch without a completed pipeline that includes the required jobs and their results.
Define audit event retention and export routines
Assign an owner for audit evidence and set a routine to export group and project audit events on a fixed schedule, storing the CSV files in a location the platform administrators cannot silently change. GitLab keeps audit events indefinitely, but exports are the copies auditors will sample, and CSV exports use UTC, so document that time basis in the procedure. Test one export and confirm that the file contains approval, merge and permission change events for a sample change. Record the export location, owner and reviewer in the ISMS evidence register.
Protect the evidence store with upgrade and backup routines
Before the evidence set is relied on, confirm that the instance has a tested backup and restore routine and a planned upgrade path. GitLab requires upgrades to pass through required upgrade stops, so the upgrade calendar must follow the published stop versions, and backups must cover the database and repositories so approval and audit records survive a failed upgrade or hardware loss. Ask the platform team to prove a restore to a separate environment. The output is a dated runbook and a restore test record that the ISMS owner accepts.
Document the procedure in the ISMS
Write the change control procedure as a controlled document in your ISMS, linking each GitLab setting to the Annex A control it supports and naming the owner of each control. Include the approval rules, the exported evidence, the export schedule, the UTC convention and the upgrade and backup routines. Ask your certification body or internal auditor to review the mapping before the first assessment, because they decide what evidence is sufficient. The step closes when the document is approved, version-controlled and linked from the evidence register.

What internal audit, the certification body and engineering each need

Internal audit tests whether the change control process actually operates as the ISMS describes it, and it does this before the external certification body arrives. For a GitLab-based process, the work is to select a sample of changes over a period, trace each one from its issue or request through the merge request, approvals, pipeline results and deployment, and record any exception. The audit cadence should be set in the internal audit program, not by GitLab, and the sample should include emergency or out-of-band changes if your process allows them.

Sample selection: Pick changes across all production-affecting projects, not only the ones the team is proud of, and include a share of merge requests that were closed without merging.
Approval trace: Confirm that the approver was not the author, that approval settings blocked self-approval where you configured that, and that the approval record matches the people your policy names.
Exception review: Check direct pushes to protected branches, bypassed pipelines and changes merged with failing jobs, then confirm each had a documented reason.
Audit event review: Export group and project audit events for the period, check the CSV timestamps against the UTC convention GitLab uses, and look for changes to protected branch rules or approval settings.
Cadence: Agree how often the review runs and who signs off findings, then keep the review record as evidence.

Before you rely on a sample, confirm with your own team which audit events your tier provides, since the supplied facts tie group and project audit events to Premium or Ultimate.

Questions buyers ask before engaging a partner for GitLab ISO 27001 evidence

What does a GitLab ISO 27001 evidence engagement cost, and what drives it up?

The cost depends on the written scope, which you should ask for before any figure is discussed. The main drivers are the number of GitLab groups and projects in scope, how many separate change paths exist (application code, infrastructure as code, configuration), how much of the approval and branch configuration already exists, and whether you want scanning, runner isolation or audit log export built into the evidence set. Costs split into one-time work (mapping controls to GitLab settings, configuring protected branches and approval rules, writing the procedure, collecting a sample evidence set) and recurring work (periodic evidence reviews, export routines, and support for surveillance audits). Ask for a quote that lists each component separately, names what is one-time and what recurs, and states the assumptions about your instance size and tier.

How long does it take to prepare GitLab evidence for ISO 27001?

Duration depends on how far your current change process is from what the evidence needs to show. Teams that already use merge requests with required reviewers and protected default branches usually need less configuration work than teams that deploy from shared accounts or direct pushes. The schedule also depends on your certification body's audit date, on how many interviews and sample requests your auditor expects, and on whether your change records live in GitLab or in a separate ticketing system. Ask for a timeline in the written scope, and confirm with your certification body which evidence periods they will sample, since that sets how much history must exist before the audit.

What must our team provide before a partner can start?

Your team needs to supply the control scope, access to the GitLab instance with an administrator account for configuration review, and a list of the systems that change production (CI/CD, deployment tools, infrastructure repositories). You also need your current change management procedure, the names of the people who approve changes and the people who can deploy them, and any existing risk treatment or statement of applicability entries that touch secure development. Expect to name an internal owner who can decide on policy questions and sign off on the final evidence set. Missing ownership is one of the most common reasons these engagements slow down.

Can our own team do this work without a partner?

Yes, many organizations do this in-house, particularly when they already run self-managed GitLab and have engineers familiar with its approval and audit features. The work is mostly configuration and documentation, so the question is capacity and independence. Ask yourself whether your team can map each Annex A control to a specific GitLab setting, test that the setting actually blocks the unwanted path, and produce evidence in a form an auditor accepts without rework. A partner can carry the fixed-scope build and hand over documentation your team operates afterward. Compare both options against the same written scope so the trade-offs are visible.

Does using GitLab make us ISO 27001 certified?

No. GitLab is a tool that can produce records of change approval, branch protection and security scanning, but it does not make an organization compliant or certified. ISO does not certify organizations, and certification is issued by accredited certification bodies after an audit of your whole information security management system, including policies, risk assessment, roles, supplier controls and management review. DeployOpen prepares systems, controls and evidence for assessment but does not issue audit reports, attestations or certifications. Confirm with your certification body which records they accept and how they sample them.

Which GitLab tier do we need for audit events and approval settings?

Group and project audit events require the Premium or Ultimate tier for self-managed GitLab, and the approval settings that block author and committer approvals and require re-authentication to approve are also available in Premium. According to the GitLab pricing page, Premium is listed at 29 US dollars per user per month billed annually, and Ultimate is custom priced. Audit events are retained indefinitely and CSV exports use UTC, which helps when you align records with your audit period. If you also need scanning results as evidence, check which scanners and policy features your scope requires, because those sit in higher tiers. Confirm the current tier matrix with GitLab before you buy.

How does the 2022 edition transition affect our timeline?

ISO/IEC 27001:2013 certificates had to expire or be withdrawn by 31 October 2025, the end of the 36-month transition period set by IAF MD 26:2023. If your organization still holds a 2013-based certificate, the relevant question is whether the 2022 edition has been adopted and audited, and that is determined by your certification body. The 2022 Annex A has 93 controls in four themes, so your mapping should reference the new control identifiers and attributes rather than the older clause structure. Ask your certification body what transition audit they require and whether the evidence scope changes, since that determines how much preparation the GitLab work must cover.

What evidence will an auditor actually ask to see from GitLab?

Auditors usually sample changes and ask for proof of authorization, independent review, testing and traceability. In GitLab that typically means merge request records with approvals, the approval rules in force at the time, protected branch settings, pipeline results for the change, and audit events showing who changed those settings. Expect requests for a sample of changes across the audit period, plus evidence that emergency or out-of-process changes are recorded and reviewed. Confirm the sampling method and the evidence format with your auditor early, and test an export yourself before the audit date.

Mapping GitLab records to Annex A change controls

Most of the evidence an auditor samples for ISO/IEC 27001 change management and secure development already exists in a normal GitLab workflow: the merge request, its approval history, the protected branch rules it passed through, and the pipeline results attached to it. For control 8.32 (change management) and control 8.25 (secure development life cycle), an auditor will typically pick a set of changes and ask who authorized each one, who reviewed it, what testing and scanning ran, and whether the author could approve their own work. The mapping belongs in your statement of applicability, so confirm the control-to-evidence mapping with your certification body before you design the evidence around it.

Approval settings do most of the work on the authorization side. On Premium, GitLab can block author and committer approvals and require re-authentication before a reviewer approves, which GitLab describes as an electronic signature for approvals. Combine these with protected branches that restrict who can push to and merge into production-bound branches, and you have a basis for the separation of duties expected under control 8.31 (separation of development, test and production environments). Confirm with your compliance lead whether a re-authentication step meets your own signature policy, and document who may change these rules, since an approval rule that can be edited quietly is weak evidence.

Audit events provide the record that ties the other controls together. The GitLab audit events documentation states that group and project audit events require Premium or Ultimate and are retained indefinitely, and that CSV exports use UTC. Security scanning and vulnerability management, which support control 8.29 (security testing in development and acceptance) and control 8.8 (management of technical vulnerabilities), are Ultimate features on the pricing page, so confirm the tier before scoping the evidence. Before the first audit, export a sample of merge requests, check the timestamps against your change tickets, and confirm that your retention and access rules match what the auditor will expect.

How DeployOpen scopes and delivers ISO 27001 change control evidence

DeployOpen plans, implements, hardens, documents and supports self-hosted GitLab inside your own infrastructure, including the approval, protected branch, scanning and audit event settings that change control evidence depends on. We prepare the systems and evidence for your ISO 27001 assessment, but independent auditors and certification bodies issue any audit report or certification.

How we scope

We map your change workflow, repositories and release paths to the Annex A controls you need to evidence.
The written scope names which projects, groups, approval rules and audit event exports are covered.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

We configure merge request approvals, protected branches and protected environments to match your documented change process.
We enable and test audit event collection, confirm the required edition and document which evidence each setting produces.
We verify controls with test merge requests and pipelines so you can show auditors the settings work as described.

How we hand over

You receive a control-to-evidence map, configuration records and runbooks for exporting audit events and pipeline history.
We document the procedures for emergency changes and approval exceptions so your team can run them consistently.
Handover includes a review session where your compliance lead and engineers confirm what each artifact proves and where gaps remain.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
We can review GitLab version upgrades and configuration drift against the evidence map at agreed intervals.
Ask your certification body to confirm which evidence it will sample, since the final assessment decision rests with the auditor.

GitLab for ISO 27001 secure development and change control