How GitLab supports DORA ICT change management evidence
A financial entity in scope of Regulation (EU) 2022/2554 (DORA) has applied the Regulation since 17 January 2025, and it must be able to show supervisors how ICT changes were requested, tested, approved and released. Self-managed GitLab can produce much of that record: merge requests with recorded approvals, protected branches, pipeline results and audit events, all kept in infrastructure the entity controls. It helps evidence the change management part of ICT risk management, and the related access and logging controls. It does not satisfy DORA on its own. Risk assessment, the ICT asset and third-party register, incident handling, resilience testing and board governance sit outside the repository, and DeployOpen prepares systems, controls and evidence for assessment but does not certify compliance. Supervisors, through the competent authority for each entity type, decide whether the evidence is adequate.
The tier decision comes first. Compliance center features, merge request approval policies and audit event streaming are Ultimate features, and separation of duties is built from protected branches and custom CI/CD configuration paths. Group and project audit events require Premium or Ultimate. Confirm the exact feature set against the current GitLab compliance documentation and the pricing page before you write a requirement that depends on a specific tier, because edition boundaries change between releases. Also confirm whether your deployment uses a self-managed Ultimate subscription, since a quote follows from a written scope that names the tier and user count.
Before the build starts, map each change control you intend to evidence to a GitLab record: who approved, what was tested, which environment received the change, and whether the approver was independent of the author. Decide how emergency changes are routed, how approvals are retained when a project is archived, and where exported audit data is stored and for how long. Write these decisions into the change policy so that the platform configuration proves the policy rather than replacing it. A short illustrative test, such as attempting a production deployment from a non-approved branch and keeping the pipeline and audit output, gives the supervisor a concrete example of a control operating.
Mapping DORA change-related requirements to GitLab capabilities
This table maps DORA Chapter II change-related expectations and the Article 28 and 30 contract points to GitLab features, the configuration each needs and the tier that includes it. Read each row as a mapping to article topics for discussion with your compliance and legal teams, since the mapping does not establish certification. The main takeaway is that approval policies and audit events carry most of the change evidence, while several rows depend on contract records outside GitLab.
| Requirement area | GitLab capability and configuration | Tier required |
|---|---|---|
| Chapter II ICT risk management: controlled changes (Articles 5 to 16) | Protected branches that require merge requests, with required approvals and pipeline success before merge | Confirm current tier with GitLab pricing page |
| Separation of duties between authors and production changes | Protected branches plus custom CI/CD configuration paths so production deployment jobs run only from an approved pipeline file | Confirm tier for each feature; compliance framework features are Ultimate |
| Restricted deployment to production | Protected environments limiting which roles or users can trigger deployments to each environment | Confirm current tier with GitLab pricing page |
| Enforced independent approval of changes | Merge request approval policies that apply required reviewers across groups and projects | Ultimate |
| Traceability of change decisions and access (Chapter II logging and monitoring expectations) | Group and project audit events covering approvals, settings and membership changes, retained indefinitely, with streaming to your log platform | Premium or Ultimate for audit events; audit event streaming is Ultimate |
| Register of information for ICT contracts (Article 28(3)) | Record the self-managed GitLab subscription, any support partner, and any hosted runner or cloud provider in your register | Not a platform feature |
| Documented exit strategy and tested transition (Article 28(8)) | Tested backup and restore, plus export and import paths to move projects, issues and pipelines if the arrangement ends | Confirm tier and procedure with GitLab documentation |
| Contract content on data location and changes (Article 30(2)) | Record where the instance and its backups are hosted, and the contract terms for advance notice of hosting changes | Not a platform feature |
Which GitLab records auditors can pull and how to keep them
Four record types in self-managed GitLab carry most of the change evidence a DORA assessment will ask about. Each one has different licensing, retention and export behavior, so the set has to be planned together. The entity decides how long records stay, where they are archived and how they link back to change tickets.
Group and project audit events
Audit events record changes to membership, permissions, protected branch settings, approval rules and project configuration. Access to them depends on tier: the audit events documentation lists Premium or Ultimate, and records are retained indefinitely by default. Confirm which tier your entity licenses before you rely on these records. Check whether your reviewers can filter events by user, date and target so they can answer questions about who changed a control.
Merge request approval history
Approval records show who reviewed a merge request, who approved it and whether the required approvers were different people from the author. Approval rules are an Ultimate capability, so confirm that the edition covers them. Export the approval history with the merge request, not only the final state, because auditors test whether approvals happened before the change was merged. Link each merge request to the change ticket it implements.
Pipeline records and test results
Pipeline records hold the jobs, stages, test reports and security scan outputs that ran against a specific commit. They show whether testing happened before deployment and which code version was tested. Set the retention for job logs and artifacts deliberately, because cleanup rules can remove the evidence before the review window closes. Store the pipeline ID in the change record so the test run can be found later.
Protected environment deployment records
Deployment records show which pipeline deployed which commit to which environment, and who approved the deployment where protected environments require it. They are the strongest link between a change ticket and what reached production. Confirm that production environments are protected, that deployers are restricted, and that deployment approvals are recorded. Test one production deployment end to end before the assessment to confirm the record shows all of these.
Export and archive practice
GitLab keeps records in the instance, so an archive outside the instance protects them from accidental deletion, instance failure and changes to settings. Decide which records are exported, in what format, how often and to which storage location with write-once or access-controlled settings. Include the export in the backup plan. Document who runs the export and how the archive is checked for completeness.
Retention and export ownership
Retention periods and export rules are the entity's responsibility to define, based on its own DORA obligations, its record-keeping policy and the supervisor's expectations. GitLab provides the record types and settings, but it does not decide how long the entity keeps them. Put the decision in a written retention standard, name an owner for each record type and review it at the same time as the change management procedure.
Configuring GitLab change controls for a DORA evidence trail
This sequence turns a self-managed GitLab instance into a change system where every production change has an authorized requester, an independent reviewer, a tested pipeline and an exportable record. Each step names the control it supports and the check that shows it is working. Confirm Ultimate-tier features with GitLab before you commit to a design, because several of the controls below depend on them.
Deploy self-managed GitLab inside your boundary
The platform team installs self-managed GitLab in the entity's own cloud accounts, data centers or network segment, using an install method and reference architecture sized for the user count and CI load. Decide early where the database, object storage and backups sit, because these become part of the ICT asset and register of information that DORA expects you to maintain. Confirm the install method and sizing against GitLab's current documentation, and record the hosting location, since Article 30(2) requires contracts to state where services are provided and data processed. Done means the instance is reachable only from approved networks and its hosting details are written into the ICT asset inventory.
Enable protected branches and required approvals
Platform administrators protect the default and release branches so that no one can push directly or force-push, and set merge request approval rules so that a change to production code needs at least one reviewer who is not the author. Map these rules to the change authorization step in your ICT change management procedure, and decide whether approvers must come from a named group. Test the control by attempting a direct push and a self-approval with a non-privileged test account. Done means both attempts fail and the failure appears in the audit trail.
Define custom CI/CD configuration paths for separation of duties
Platform engineers move the pipeline definitions that deploy to production into a separately owned project, and point protected projects at that path so that application teams cannot alter the deployment logic in their own merge requests. Restrict who can merge changes to that configuration to a small group that is independent of the teams whose code is being deployed. Confirm with GitLab how separation of duties is enforced for your chosen tier, since this design relies on protected branches and custom configuration paths. Done means a test merge request that edits the production pipeline file in an application repository is blocked or routed to the owning group for approval.
Configure protected environments for production
Administrators define production and other sensitive environments as protected, naming the roles or groups allowed to deploy and, where your procedure requires it, adding approval steps before a deployment job runs. This ties each production deployment to a specific pipeline, commit and approver. Ask GitLab which protected environment and deployment approval features are available in your edition and tier, and test them in a non-production project first. Done means a deployment from an unauthorized role is refused and an authorized deployment records the approver and the pipeline reference.
Enable audit events and set up export
Group and project audit events are turned on for the scope that covers change-relevant activity, including membership changes, protected branch changes, approval rule edits and environment changes. Confirm with GitLab which audit event types are available at your tier and whether audit event streaming is included, since the compliance features referenced for this design are Ultimate features. Set up a regular export or streaming target that sits outside the GitLab administrators' control, so that the record survives an administrator change. Done means a test change to a protected branch rule appears in the audit log and in the external copy.
Link pipeline records to change requests
Teams configure merge request templates that require a change reference, such as a ticket ID from the change management system, and ensure that pipeline results, test reports and security scan outputs attach to the merge request. The objective is that one merge request can show who requested the change, who approved it, what tests ran against the exact commit and what was deployed. Confirm with your change system vendor how the reference is validated. Done means a sample change can be traced from the ticket to the merge request, the pipeline and the production deployment without manual reconstruction.
Document and test the emergency change path
The change owner writes an emergency change procedure that states who may authorize an out-of-band change, how the change is made through GitLab, and how it is reviewed after the fact. Decide whether emergency changes use a separate protected path with fewer approvers or the normal path with expedited approval, and record the trade-off. Run a tabletop exercise that includes a retrospective merge request and an audit log review. Done means the procedure is approved, the exercise produced a dated record, and the team can show the emergency change in the audit trail with its after-the-fact approval.
Confirm the evidence with an independent assessor
Before relying on this design for DORA supervision, your compliance function and an independent assessor review the configuration, the test records and the export. DeployOpen prepares the systems, controls and evidence for this review but does not issue audit reports or attestations, and DORA itself sets no certification scheme. Ask your competent authority or internal audit which evidence they expect for ICT change management under the regulation. Done means the reviewer has signed off on the test results and the evidence pack is stored where it can be retrieved for supervisors.
How a single change becomes a DORA evidence trail
A single change is only evidence if every link in its chain is recorded in the same system. In a self-managed GitLab setup, the chain usually runs from an issue or ticket reference in the merge request title or description, to the merge request itself, then to the approvals recorded on that merge request, the pipeline that built and tested the commit, the deployment into a protected environment, and finally the audit events that record who changed the project, group or environment settings. Each link has a home: the merge request and its approvals live in the GitLab project database, pipeline jobs and logs are stored in GitLab with job artifacts in the configured object storage, deployment records sit under the project's environments, and audit events are kept in GitLab. Decide early which of these you will export, where the exports go and who can read them, because the ticket system is the only link you probably do not host in GitLab.
When a supervisor reviews a sample change, the questions are general and repeatable: was the change authorized, was it tested before it reached production, did someone other than the author approve it, and could the person who wrote the code deploy it without a second party. Your team should be able to show the merge request, its approval history, the pipeline that ran against the exact commit, the environment deployment and any settings change that affected the path. Check in your own instance that protected branches, protected environments and approval rules are set so the answers come from GitLab rather than from convention. The trail breaks when approvals happen in a chat tool, when the ticket status is the only authorization record, or when pipeline logs age out before the review window closes. Confirm your retention settings for pipeline artifacts and logs with your own administrators before you rely on them.
Questions financial entities ask before using GitLab for DORA evidence
Does using self-managed GitLab make our organization DORA compliant?
No. DORA is Regulation (EU) 2022/2554, and compliance is a property of your whole ICT risk management framework, not of a tool. GitLab can produce records that support change management controls, such as merge request approvals, protected environments, audit events and pipeline logs, but your governance, risk assessments, testing policy and supervisory reporting still have to be designed and operated by your entity. DORA also sets no certification scheme, so no vendor or DeployOpen engagement results in a DORA certificate. Confirm with your national competent authority and your own compliance function how they expect change evidence to be presented, and with your independent auditor which records they will sample.
What drives the setup effort for GitLab change evidence?
Effort depends on four things: instance size, the number of projects and environments that carry production changes, how identity is integrated, and which GitLab tier you choose. Compliance features such as merge request approval policies, the compliance center and audit event streaming are Ultimate features, so the approval model and evidence export scope drive more work than a basic install. Identity integration through SAML, LDAP or SCIM affects who can approve and how access is removed when people leave. Ask for a written scope that lists the projects in scope, the environments that need protection, the approval rules per change type and the evidence export targets before comparing quotes.
Can our own platform team set up GitLab for DORA evidence in-house?
Often yes, if your team already runs self-managed infrastructure and has people who understand both Git workflows and change control. The install, upgrade stops and backups are standard operational tasks that GitLab documents in detail. What is harder in-house is designing separation of duties, writing approval rules that match your change policy, and mapping records to DORA ICT change management expectations. Many entities keep the platform operation internal and buy design or review support for the control model. Decide which of these you can staff and maintain before choosing between your team and a partner.
What do our teams need to provide for a GitLab implementation?
Plan for named owners in four areas: the change management function that defines which changes need approval and emergency procedures, the platform team that hosts and patches the instance, the security team that sets protected branch and runner rules, and the application teams whose repositories and pipelines will be configured. You also need access to your identity provider, a place to store backups and a decision on where audit events are exported and retained. Expect reviews of the design before go-live. Agree these responsibilities in writing so the scope and deliverables match what your organization can provide.
How long must we keep GitLab audit events for DORA?
GitLab documents that group and project audit events require Premium or Ultimate and are retained indefinitely by default, so the GitLab instance itself does not force a short retention window. However, DORA and your internal record retention rules set how long you must keep ICT change records, and that period is a policy decision for your compliance function. Confirm with your regulator and legal team what retention applies, then decide whether records stay in GitLab, are exported to your log platform or archive, and how they are protected from tampering. Also check that backups include the data you need to prove a change history.
Which GitLab tier do we need for change management evidence?
Choose the tier by the controls you must enforce, not by the headline price. GitLab Free is available for self-managed installations at no cost, and Premium is listed at 29 US dollars per user per month billed annually on the pricing page. Ultimate is custom priced. Merge request approval policies, the compliance center, compliance frameworks and audit event streaming are Ultimate features, while group and project audit events are available from Premium. If you need enforced approval policies or streamed audit events, Ultimate is the relevant scope, and the price must come from a written quote. Confirm current tier contents on the pricing page before budgeting.
Does GitLab evidence cover our supplier obligations under DORA?
Only partly. GitLab records how changes to your software were proposed, reviewed, tested and deployed, which supports the change management part of ICT risk management. DORA also requires an information register of ICT contracts, contract terms covering service location and data return, and tested exit strategies for services supporting critical or important functions. GitLab's self-managed model means your entity holds the instance and data, but those contractual and exit obligations are outside what GitLab's pipelines record. Ask your legal and third-party risk teams to document how the GitLab platform, runners and any partner appear in your register.
What should we verify before relying on GitLab records in an examination?
Test the evidence path end to end before an examiner asks for it. Pick a sample change, then confirm you can show the merge request, the reviewer and approval, the protected environment that received the deployment, the pipeline results and the matching audit event. Check that emergency changes follow a documented path and leave a record. Verify that administrator actions on the instance are logged, that backups restore to a working state, and that the instance is upgraded through required upgrade stops so it stays supported. Confirm the exact evidence format your auditor and supervisor accept.
Who owns which DORA evidence
The ICT risk and compliance function owns the policy that defines how changes are authorized, tested and recorded, and it answers for the entity's position under DORA's ICT risk management requirements. GitLab does not write that policy, but it can hold the approval rules that enforce it, such as protected branches and merge request approval settings, which are configured through the compliance features described in the GitLab compliance docs. Compliance should also own the change risk classification, the exception process for emergency changes and the periodic review of who holds approval rights.
- Policy and classification: the written change policy, risk tiers and the criteria for standard, normal and emergency changes.
- Approval rules: the rules that a compliance lead signs off, which engineering then implements in GitLab.
- Access reviews: periodic checks of who can approve, merge or deploy to protected environments.
- Exceptions and risk acceptance: signed records of any change that bypassed the normal path, kept with the ticket or incident record.
- Third-party records: where GitLab is an ICT service, the register of information and contract terms that DORA requires, which sit outside the platform.
Before relying on GitLab records, confirm with your team which features your edition includes, since compliance center and approval policy features are Ultimate capabilities.
Engineering and platform teams own the day-to-day operation of the change path: branch protection, pipeline definitions, runner fleet, environment configuration and the GitLab instance itself. GitLab records most of the operational trail here, including merge requests, approvals, pipeline results and deployment history tied to protected environments. Because those records are only as good as the configuration behind them, this group must be able to show that the settings were applied and not changed without review.
- Merge request trail: code changes, reviewers, approvals and linked issues for each change.
- Pipeline records: test, scan and build results attached to each commit and merge.
- Protected environments: who may deploy to production and under which approval rules.
- Configuration and backups: the
gitlab.rbsettings, runner configuration and backup procedures that keep the record intact. - Runner and instance logs: execution records that support the audit trail, kept under your retention rules.
Check that separation of duties is enforced by configuration, such as custom CI/CD configuration paths, rather than by convention alone.
External auditors and national competent authorities review whether the entity's change controls operate as described. They do not receive GitLab access as a matter of course, so the entity must decide what they can inspect and how. GitLab's audit events are relevant here because group and project audit events require Premium or Ultimate and are retained indefinitely, according to the GitLab audit events docs. DeployOpen prepares systems and evidence for assessments, but auditors and supervisors make the findings.
- Sampling: auditors typically select changes and ask for the approval, test and deployment records behind each one.
- Audit event exports: evidence of permission changes, approval rule edits and configuration changes.
- Narrative and policy: the documented process that explains how GitLab records map to the entity's obligations.
- Independence of evidence: records the entity can reproduce from GitLab and from its own systems, not from screenshots alone.
- Supervisory requests: responses that the entity prepares for the competent authority, which the ICT risk function coordinates.
Ask your auditor early which evidence formats and sample periods they expect, and confirm with them how they will treat evidence that lives in a self-managed instance.
How DeployOpen scopes and delivers DORA change evidence
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted GitLab inside your own infrastructure, including cloud accounts, data centers or air-gapped networks. For DORA ICT change management, we set up the approval, environment and audit record design first, then prepare the evidence your compliance and audit teams will need, without issuing any audit report or certification.
How we scope
- Map your ICT change types, approvers and emergency change paths to GitLab merge requests and protected environments.
- Confirm which GitLab tier your required approval, compliance and audit event features need before design starts.
- Agree the written scope, deliverables and timelines with you in advance, since most engagements are fixed-scope.
How we build
- Configure protected branches, custom CI/CD configuration paths and approval rules that separate authors from approvers and deployers.
- Test change records end to end, from a sample merge request through pipeline results to a protected deployment.
- Check that group and project audit events capture the actions your change policy depends on, and document any gaps.
How we hand over
- Document the change workflow, roles, approval matrix and where each record of evidence is stored and retrieved.
- Provide a mapping from your DORA change management obligations to the GitLab features and settings that support them.
- Train your platform, security and compliance owners to pull evidence themselves and to run the procedures independently.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover, scoped in writing.
- Plan GitLab upgrades around required upgrade stops so that change controls and evidence stay valid through each release.
- Review changes to approval policies and environments with your team so the evidence record stays consistent over time.
