GitLab for NIS2 supply chain and secure development

How GitLab supports NIS2 supply chain security evidence

If you are an essential or important entity under NIS2 and run your own GitLab, you need to show that your Article 21 measures on supply chain security and secure development work in practice. GitLab supplies technical controls and records, not a certificate. NIS2 creates no certificate of compliance: national competent authorities oversee compliance through inspections, security audits, security scans, information requests and administrative fines, so the question for your team is what evidence GitLab can produce for those reviews and what you must still document yourself.

GitLab helps most with the secure development and supply chain parts of Article 21. Security policies, which are an Ultimate feature, can enforce scan execution, merge request approvals and pipeline execution, and they are stored in a security policy project that you can review and version. The dependency list can export CycloneDX SBOMs for Ultimate projects, and audit events record who changed what. Confirm with your tier and version which of these features your edition includes, since the tier decision drives what you can show. GitLab does not cover risk analysis, incident handling, business continuity, supplier due diligence beyond your code dependencies, or the governance and training duties that Article 21 also requires.

Sector detail matters too. Commission Implementing Regulation (EU) 2024/2690 sets detailed technical and methodological requirements for the Article 21(2) measures, but only for specific sectors such as DNS, cloud, data center, CDN, managed service providers, online platforms and trust service providers. If you are outside those sectors, it is not binding on you, though it can still serve as a reference. Check with your national competent authority how your transposition law applies, and read the NIS2 Directive text on EUR-Lex before mapping evidence to obligations.

Mapping NIS2 Article 21 measures to GitLab capabilities

This table maps the supply chain, secure development, vulnerability handling, access control and change control themes to the GitLab features that produce evidence for them, with the configuration each needs and the tier it requires. Read the tier column first, because security policies and CycloneDX SBOM export are Ultimate features, and the evidence column shows what an assessor can actually inspect.

Theme	GitLab configuration	Tier required	Evidence it produces
Secure development testing	Enable SAST, secret detection and dependency scanning in the pipeline, and enforce scan execution policies for groups or projects through a security policy project	Ultimate	Pipeline job logs, scan reports and policy definitions stored in the security policy project
Supply chain component inventory	Use the dependency list for each project and export CycloneDX SBOMs from the dependency list	Ultimate	Per-project component inventory and versioned SBOM files tied to a commit or pipeline
Vulnerability handling	Apply vulnerability management policies and triage findings in the vulnerability report with owners and status	Ultimate	Vulnerability records with state changes, dismissal reasons and linked issues
Change approval before release	Set merge request approval rules, protected branches and approval policies for security-relevant projects	Premium for approval rules and protected branches; Ultimate for approval policies	Approval history, reviewer identity and merge records on each merge request
Access control over pipelines and environments	Restrict who can push to protected branches, run deploy jobs and modify CI/CD variables, and require SSO or SCIM-based provisioning	Free for basic roles; Premium or Ultimate for SAML group sync and SCIM provisioning (confirm per feature)	Role assignments, group membership changes and sign-in records
Audit trail of administrative and project changes	Review instance and group audit events, and forward them to your log platform on a schedule you define	Confirm the audit event tier for each event type in the current documentation	Audit event exports covering permission, policy and setting changes
Evidence beyond GitLab	Document supplier risk, incident reporting, business continuity and staff training in your own management system	Not a GitLab feature	Policies, risk registers and training records held outside the GitLab instance

Which GitLab records auditors and supervisors can use

GitLab produces several record types that can support NIS2 Article 21 supply chain and secure development measures. Each one lives in the instance by default, so the work is deciding what to export, where to keep it, and how long to keep it. Confirm retention periods with your national competent authority before relying on any of them.

Scan results and vulnerability records

Security scan outputs and vulnerability findings show what was tested, when, and what was triaged or accepted. Their value to a supervisor depends on showing that findings were tracked to closure, not just generated. Export scan reports from each pipeline into your evidence store, and record who accepted any risk. Check whether scanner artifacts expire under your pipeline and artifact retention settings, since a backup restore will not bring back expired artifacts. Confirm with your authority what retention period it expects for vulnerability handling records.

Merge request approval records

Approval history shows who reviewed and approved each change before it reached a protected branch. For Article 21 this is evidence of controlled change to software, not just a review habit. Keep a periodic export of merge requests, approvers and approval rules outside the instance, because the native view depends on project settings that may change later. Restores from backup carry this data forward, but project deletion does not. Confirm the retention period your authority expects for change records.

Pipeline execution logs

Pipeline logs record the build, test and scan steps that ran for a given commit, including the runner and job configuration used. They support claims about how an artifact was produced. Job logs are subject to log and artifact expiry, so unexpired logs are not guaranteed. Set retention deliberately for jobs that produce release artifacts, and archive logs for release pipelines to storage you control. Confirm with your authority and your own release policy how long build logs must be kept.

Security policy project history

Security policies such as scan execution and merge request approval rules are stored in a dedicated security policy project. Its commit history shows when a control was introduced, changed or removed, which is useful when a supervisor asks whether a control was in force at a given date. Protect this project with restricted maintainer rights and keep a copy in version control you can export. Confirm that the history you keep covers the period your authority will ask about.

Dependency lists and SBOMs

The dependency list shows the components a project uses, and it can be exported as CycloneDX SBOMs on the Ultimate tier. SBOMs are the most direct evidence of supply chain visibility, but a single export is a snapshot. Generate SBOMs per release and store them with the release record, not only in the GitLab UI. Check that exports include the components and versions you need for your own inventory. Confirm with your authority which format and retention period it accepts.

Audit events and backup coverage

Audit events record administrative and access actions across the instance, such as permission changes and settings edits. They are often the first thing a supervisor asks for when reviewing who could change code or pipelines. Forward them to a log platform you control, since the instance-side record is only as durable as its database. Backups protect the instance copy, but they only cover the retention window you configured, so older events may be gone. Confirm with your authority how far back access and change records must go.

Choosing Free, Premium or Ultimate for NIS2 evidence

GitLab Free costs 0 dollars, according to the GitLab pricing page, and is available for self-managed installations. A team can host repositories, merge requests and basic pipelines without a licence fee. For NIS2 Article 21 supply chain and secure development measures, Free gives you a change and code review trail, but not the policy engine, SBOM export or scanning features that produce stronger evidence.

Repository and review history. Merge requests, commit history and protected branches show who changed what and when, provided your team configures the branch rules.
Pipeline records. CI/CD job logs show build and test steps, but you must link them to approvals through your own procedure.
No policy enforcement. Scan execution and merge request approval policies are Ultimate features, so Free teams enforce secure development rules through documented procedure and manual checks.
No built-in SBOM export. The dependency list export is an Ultimate feature, so Free teams need separate tooling to generate component inventories.

Before you rely on Free, ask your compliance lead which records your national competent authority or auditor will expect to see.

Configuring GitLab for NIS2 evidence collection

This sequence turns a self-managed GitLab instance into a source of evidence for NIS2 Article 21 supply chain and secure development measures. Each step produces a record that an assessor can inspect, and each closing check confirms the setting is actually in force.

Deploy a supported GitLab version on the upgrade path
The platform team installs a GitLab release that is still within the maintenance policy and plans every move through the required upgrade stops, which fall at versions x.2, x.5, x.8 and x.11 since GitLab 17.5. Confirm the current supported releases in the maintenance policy before choosing the target version, and record the installed version and upgrade plan in your change records. Done means the instance reports a supported version and the upgrade plan names each stop it will pass through.
Enforce protected branches and merge request approvals
The DevOps lead configures protected branches so that no one pushes directly to release branches, and sets merge request approval rules so that a reviewer other than the author must approve each change. Assign these rules at the group level so that new projects inherit them. Done means a test push to a protected branch is rejected and a merge request cannot merge without the required approvals, with both results kept as evidence.
Create a security policy project and attach policies
The security lead creates a dedicated security policy project, then defines scan execution and merge request approval policies in it and links them to the relevant groups, projects or compliance frameworks. Scan execution and approval policies require the Ultimate tier. Done means each in-scope project shows the policies as applied, and a merge request that changes a scanned branch triggers the required scans and approval gate.
Enable dependency list and CycloneDX SBOM export
The application security team turns on the dependency list for each in-scope project and exports CycloneDX SBOMs from the Ultimate tier. Store the exported files alongside the release records for each version, so that each shipped component can be traced to a build. Done means a sample release has a retrievable SBOM whose component list matches the dependency list shown in the project.
Set audit event retention and export
The platform owner decides how long audit events are kept and sets up a scheduled export to storage that the GitLab administrators cannot alter, such as a log platform or write-once storage you control. Confirm the retention period with your compliance lead, since NIS2 sets no fixed period in the supplied sources. Done means a test action such as a permission change appears in the exported record within the expected window.
Back up instance configuration and secrets
The platform team documents the configuration and secrets needed to restore the instance and includes them in the backup procedure, because evidence is only useful if the instance can be rebuilt with its settings intact. Follow the backup and restore documentation to confirm what is covered by the standard backup task and what needs separate handling. Done means a restore test on a separate host reproduces the policy configuration and audit history.
Harden the instance and runners
The security engineer works through GitLab's hardening guidance for application settings, CI/CD, configuration files, the operating system and NIST SP 800-53 mappings, rolling changes out gradually and recording each one. Runners get isolated execution environments and restricted tags, and their versions are kept aligned with the GitLab version. Done means a hardening baseline document lists each applied setting, its owner and the date, and an assessor can compare the live configuration against it.

Where GitLab evidence stops

GitLab can produce records for parts of Article 21 on secure development and supply chain security, but several measures sit outside the instance entirely. The cards below list those gaps so you can assign each one to a named owner before an assessor asks. Confirm every item against Implementing Regulation (EU) 2024/2690 and your national transposition law.

Supplier risk assessment

GitLab shows which components and dependencies a project uses, but it does not assess the suppliers behind them. Vendor security questionnaires, financial stability checks, hosting location reviews and due diligence on managed services you run alongside GitLab all live in your procurement and third-party risk process. Keep those records in a system you control and link them to the GitLab projects they affect. Confirm with your national authority which supplier assessment evidence it expects.

Incident reporting under Article 23

GitLab can hold pipeline failures, audit events and vulnerability records that help reconstruct an incident, but it does not decide what counts as significant or send notifications. Your incident response procedure must define the early warning, incident notification and final report timelines that Article 23 sets, and who submits them to the competent authority or CSIRT. Test that path with a tabletop exercise. Confirm the criteria against Implementing Regulation 2024/2690.

Backup and continuity outside GitLab

GitLab backup and Geo replication protect the GitLab instance, but business continuity also covers the identity provider, the runner hosts, the database and object storage that GitLab depends on, and the systems that build and ship your products. Those components need their own recovery objectives and restore tests. Ask who owns restore testing for each dependency and whether results are recorded outside the GitLab instance.

Human training and awareness

Secure coding training, phishing awareness and the handling of secrets by developers are not recorded by GitLab. Merge request approvals show that a reviewer approved a change, not that the reviewer was trained to find a flaw. Keep training completion records, role-based training plans and attendance logs in your learning or HR system. Assessors often ask how training content relates to the vulnerabilities that scanners detect.

Contracts and governance documents

Policies, risk registers, the security governance charter, management approval of measures and contracts with GitLab, runner hosting providers and integrators are documents rather than pipeline events. GitLab can enforce a policy in code, but the written policy, its owner, review cycle and approval belong in your document management system. Confirm which governance records your national authority expects management to sign and keep.

Proof that scanners cover every component

Security policies and scanners only report on the projects, languages and package managers they are configured to read. A repository without a supported lockfile, a container image built outside the pipeline, or a vendored binary may never appear in the dependency list. Maintain an inventory of repositories and build targets, compare it against the projects where scanning is enforced, and review the gaps on a schedule. Confirm the coverage you need against the GitLab security policy documentation and your own asset register.

Questions buyers ask before outsourcing NIS2 evidence work

What drives the cost of NIS2 evidence work on GitLab?

The cost depends mainly on the GitLab tier you need, the number of projects and groups in scope, how many security policies you must design, how much evidence design is required, and how much legal scoping your organization needs before any technical work starts. Scanning, merge request approval policies and SBOM export are Ultimate features, so the tier decision is usually the first cost driver. GitLab's pricing page lists Free at 0 US dollars, Premium at 29 US dollars per user per month billed annually, and Ultimate as custom priced, so the licence line depends on your quote from GitLab. DeployOpen fixed-scope work is priced from a written scope, so ask for the scope items listed above to be separated in the quote. Ask whether the figure covers one-time design or recurring support.

How long does it take to set up GitLab evidence for NIS2?

Duration depends on how many projects must produce evidence, how many policies need agreement with security and legal owners, and whether your existing pipelines already run scanners and produce SBOMs. Policy design often takes longer than the technical configuration, because approvers and evidence owners must agree on what is recorded and retained. Your GitLab instance may also need upgrades, runner changes or identity integration before policies can be enforced. No duration is fixed here, so ask any partner to state the phases, the assumptions behind each one, and which client dependencies could delay them.

What does the client need to provide for this work?

You will need named security owners who can approve scanning and vulnerability policies, legal or compliance input that maps NIS2 obligations to your entity classification, and repository access for the groups and projects in scope. Administrative access to the self-managed GitLab instance and the security policy project is also required, along with access to your existing evidence stores, such as ticketing or log systems. Ask the partner to list each input, the person responsible for it, and the date it is needed, so the timeline does not depend on informal availability.

Can our own team do this without an outside partner?

Yes, if your team already runs self-managed GitLab, understands its security policies and can write the evidence design and legal scoping in-house. Many organizations split the work, keeping policy decisions and legal interpretation internal while outsourcing configuration, pipeline changes and documentation. The main risks of doing it alone are unclear ownership of the policy project, scanners that run but whose results nobody reviews, and evidence that cannot be shown to a supervisor in a usable form. Compare your team's capacity against the scope list before deciding.

Does GitLab alone make us NIS2 compliant?

No. NIS2 is a directive that applies through national laws, and it creates no certificate of compliance. Authorities oversee compliance through inspections, audits, scans, information requests and fines, so compliance depends on your whole risk-management program under Article 21, including governance, supplier management, incident handling and business continuity. GitLab can produce scanning results, approval records, SBOMs and audit events that support secure development and supply chain measures. It does not decide your risk appetite, cover your non-development systems or replace independent assessment. Confirm your obligations with legal counsel and your national competent authority.

How could the COM(2026) 13 proposal change the scope of this work?

The Commission proposed targeted amendments to NIS2 on 20 January 2026 under COM(2026) 13, including a new small mid-cap category. The proposal still needs approval by the European Parliament and the Council, and Commission pages updated through July 2026 describe it as a proposal. If adopted in a changed form, it could alter which entities are in scope and therefore which evidence you need to produce. Build the scope so that policy and evidence definitions can be adjusted without rebuilding pipelines, and ask any partner how change requests after signature are handled.

Where does GitLab evidence stop for NIS2 Article 21?

GitLab evidence covers what happens in repositories, merge requests, pipelines and dependency inventories. It does not show that a supplier has met your contractual security requirements, that staff are trained, that business continuity plans work or that incidents were reported within the deadlines in Article 23. Evidence also depends on how you run the instance itself, including backups, access control and upgrades. Ask for a mapping that marks each requirement as covered by GitLab, covered by another system, or owned by a process outside the platform.

What should we verify before signing a scope for NIS2 GitLab work?

Verify the GitLab tier and features your scope requires, the list of projects and groups in scope, the policies to be enforced and who approves them, and the evidence each policy will produce and where it is stored. Confirm that the instance can be operated in your environment, including any offline or air-gapped constraints, and that backups and upgrade stops are planned. Also confirm the named client owners, the acceptance criteria for each deliverable, and how the team handles changes if the NIS2 scope is amended.

What to confirm with your authority and auditor first

Before any GitLab work is scoped, confirm with counsel and your national competent authority which obligations apply to you. NIS2 is a directive, so its duties reach your organization through the national law that transposes it, and that law may add requirements or keep stricter rules. Establish your sector under the directive's annexes, whether you are classified as an essential or important entity, and how your Member State supervises that classification. The directive's supervision model differs between the two categories, so the classification changes how much evidence the authority may ask for and how often it may ask. Also check whether the proposed amendments to the directive, which are still pending approval by the European Parliament and the Council, would change your category.

Ask the authority or your auditor which evidence they expect for the Article 21 measures and in what format. NIS2 creates no certificate of compliance, so there is no standard attestation to target. Authorities oversee compliance through inspections, security audits, security scans and information requests, and they may want to see policies, configurations and records directly. Ask whether they will accept GitLab exports, such as audit events, pipeline records and dependency lists, or whether they expect evidence in another form. Ask which GitLab tier your scanning and policy controls require, since the Ultimate features named in this section are not available on lower tiers. Settle these questions before you write the statement of work, because they determine what DeployOpen configures and what it documents.

DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications, and it cannot tell you that your organization is compliant. Those judgments belong to your national authority and to any independent auditor you engage. The implementation scope should therefore be written around the questions your authority or auditor has confirmed, not around general good practice. Record in the written scope which controls are configured, which evidence is generated, and which responsibilities stay with your own staff, such as risk assessment, supplier reviews and incident reporting. Where the authority's expectations are still unclear, plan the scope to be adjusted after that conversation rather than assuming the answer.

How DeployOpen scopes and delivers NIS2 evidence configuration

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For GitLab and NIS2 supply chain and secure development measures, we configure the GitLab controls that produce evidence, then document where that evidence stops and what your organization must still provide.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
The written scope names the GitLab tier, the projects and groups in scope, and which scanners and policies will be configured.
We confirm which Article 21 measures the evidence is meant to support and which parts belong to your own policies and processes.

How we build

We configure scan execution, merge request approval and pipeline execution policies in a security policy project, then test them on sample projects.
We set up SBOM export and dependency list review, and check that outputs are complete for the components you need to track.
We document the configuration as code, so policy changes go through merge requests and leave an audit trail.

How we hand over

You receive a written map of each configured control to the evidence it produces, including where that evidence is stored and how long it is retained.
We document the evidence gaps, such as supplier assurance, incident reporting and people controls that GitLab does not cover.
Runbooks explain how your team collects evidence for an inspection or information request from the competent national authority.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, which cover GitLab release changes and policy reviews.
We can review the evidence map when national transposition rules or the implementing requirements change, and confirm the current text with your legal team.
Quotes follow from the written scope. Ask for separate estimates for the GitLab tier, configuration work, testing and any retainer.

GitLab for NIS2 supply chain and secure development measures