Every few weeks someone asks us whether NIS2 means they need a new CI system. The honest answer is almost always no. The directive doesn’t mention pipelines at all. What it does ask for is a set of risk-management measures, and a surprising number of them are things a well-run pipeline already does, or could do with an afternoon’s work.
We started reading Article 21 with a highlighter and a list of our customers’ workflow files side by side. Here is what we found, minus the legal hedging (your lawyer will add it back, and they should).
The four lines that touch your pipeline
Out of the ten measures in Article 21(2), four land squarely on the path from commit to production:
- (d) Supply chain security. Know what you build from. A lockfile and an SBOM per release is a strong start.
- (e) Secure development and vulnerability handling. Scanning in the pipeline, and a written way to deal with what it finds.
- (i) Access control. Who can merge to main, who can deploy, and how you’d know if that changed.
- (j) MFA. On the forge, on the deploy path, and on the break-glass account everyone forgot about.
The directive doesn’t care which CI you run. It cares whether you can show your work.
Not legal advice. We’re engineers; we sit next to your lawyer, not in their chair.
Evidence is a by-product, not a project
The expensive way to comply is to do the work and then document it separately. The cheap way is to make the work produce its own evidence. A required review on main is an access-control record. A failed build on a reachable CVE is a vulnerability-handling record. You just need to keep them.
# .gitea/workflows/release.yml (excerpt)
jobs:
sbom:
runs-on: gumoji-eu
steps:
- uses: gumoji/scan@v3
with: { fail-on: reachable-high, sbom: cyclonedx }
- uses: gumoji/comply-evidence@v1 # files it under Art. 21(2)(e)
Where to start on Monday
Turn on required reviews for your default branch. Enforce MFA on the forge for everyone, contractors included. Add one scanning step that fails on reachable highs, not on every CVE in the database, or people will learn to ignore it by Thursday. Then write a one-page vulnerability-handling policy that describes what you now actually do.
That won’t make you compliant on its own. It will make the rest of the conversation much shorter, and it will make your pipeline better regardless of what the regulator thinks. If you’d like a second pair of eyes on your workflows, we’re happy to look.