In most companies, "governance" is a wiki of policies and a quarterly access review: useful documents, none of which would stop a bad change at 4pm on a Friday.
NIS2 just made that gap personal: the directive says a company's management body "can be held liable" for its security measures, and the Cyber Resilience Act wants a software bill of materials for everything you ship. A spreadsheet won't satisfy a regulator, and a 50-to-200-person scaleup can't staff a compliance department to produce one.
So put governance where the work actually happens: the internal developer platform you already run. Ownership in the catalog, controls in the golden path, deployment only through reviewed GitOps, and the evidence falls out by itself. One caveat up front: only where the path gates, not merely records.
Governance shouldn't live in a document nobody reads
Bolted-on governance (a policy wiki, a quarterly review, a spreadsheet of controls) describes intentions. It doesn't enforce them. And the gap between "we have a policy" and "the policy is applied to every service" is exactly where audits fail and incidents start.
We describe a platform to clients as five layers, and governance isn't one of them. It runs through two: the developer-experience layer (catalog, ownership, golden paths) and the security-and-compliance layer (policy, access, audit). The house phrase is "security built in, not bolted on." Call it compliance by architecture. Governance is the same: it's a property of the platform, or it's a document someone quotes after the incident.
| Governance as documents | Governance in the path | |
|---|---|---|
| Ownership | A spreadsheet, often stale | Catalog entry + CODEOWNERS, required to exist |
| A control | "We have a policy for that" | A blocking check on every merge |
| Access | Quarterly review | Enforced by the pipeline, continuously |
| Audit evidence | Assembled by hand, under pressure | A by-product of shipping (git history, scans) |
| Coverage | The services someone remembered | Every service, by default |
The cost of the document model just became personal.
NIS2 made governance and compliance your personal problem
NIS2 (EU Directive 2022/2555) turns governance and compliance from good intentions into a legal duty. And a 50-to-200-person scaleup is almost certainly in scope.
Any organisation with at least 50 staff, or more than €10M in turnover, in a covered sector is an "essential" or "important" entity. Article 21 lists the required measures, and several are pure governance: access control and asset management, supply-chain security, secure development. Article 20 is the one that should make you sit up: the management body approves and oversees those measures, "can be held liable" for failures, and has to take training. Fines reach €10M or 2% of worldwide turnover for essential entities, and €7M or 1.4% for important ones. A scaleup is usually the latter.
This is not some distant Brussels forecast. The Dutch implementation cleared the lower house in April 2026, with the Senate due to vote in early July and the law expected in force around mid-2026. The Commission is already chasing 19 member states for missing the original deadline. The Cyber Resilience Act piles on an SBOM-and-vulnerability-handling duty, and ENISA's technical guidance, under Commission Implementing Regulation (EU) 2024/2690, spells out the technical measures for the digital sector.
Here's the part you actually care about: none of this is satisfied by a spreadsheet. Access control, asset management, secure development, supply-chain integrity: these are properties of how you build and ship, not rows in a register. The engineering answer is the compliance answer.
| What NIS2 asks for | Where the deployment path delivers it |
|---|---|
| Asset management + access control (Art. 21(2)(i)) | Service catalog + CODEOWNERS + RBAC |
| Supply-chain security (Art. 21(2)(d)) | SBOM generated on every build |
| Secure development, vulnerability handling (Art. 21(2)(e)) | Blocking scan/SAST gates in CI |
| Evidence for management oversight (Art. 20) | Git history, scan reports, reviewed merges |
You meet it once, in the path every change already takes.
The deployment path is the governance system
So encode the rules into the path a change already travels, and governance happens by default while the evidence piles up on its own.
Across the platforms we build and operate, a new service doesn't start from a blank repository. A Backstage scaffolder template seeds it with a golden-path pipeline and registers it in the catalog with an owner. There is no such thing as an unowned service.
That pipeline doesn't copy-paste security config either. It pulls in versioned, shared CI components: one for scanning, one for container analysis, one for the SBOM. Upgrade a control in one place, roll the new version out, and every service moves to the same baseline, instead of chasing a copy-pasted change across a hundred repos. Compliance by architecture, made literal: the control is a dependency you version, not config you duplicate.
The gates that matter run on every merge request, and they block. Secret scanning rejects a committed credential. An encryption check refuses a plaintext secret before it lands. Static analysis and misconfiguration scans fail the build on real findings. And one gate I'm particularly fond of fails the build when role definitions drift out of sync across the identity provider, the secrets backend, and Kubernetes RBAC: access governance as code, not a review you do twice a year.
And there is one door to production. Merges reconcile to the cluster through GitOps; there is no side entrance that skips the pipeline. The merge request review is the human gate, the pipeline is the automated one, and the git history is the audit trail.
Notice what you didn't have to do: assemble evidence. The SBOMs, the scan reports, the reviewed merges, the catalog of who owns what: they're produced by shipping, not by a pre-audit scramble.
But encoding governance only governs if the path actually stops things.
A catalog records ownership; only a gate enforces it
A catalog that records who owns a service won't stop an unowned or unsafe one. Governance needs both halves, and mistaking the first for the second is where it quietly fails.
The record layer is necessary (a catalog knows who owns what, a scorecard knows which checks pass, an SBOM knows what's inside), and it's exactly the evidence Article 20 oversight wants. But a record states a fact; it doesn't enforce one. A scorecard saying 90% of services have scanning enabled is not a pipeline that refuses to merge the other 10%.
Enforcement is a gate that can say no: a blocking CI stage, a required review, a deployment path with no side door. And it's worth being honest about the gates you don't have yet. On the platforms we run today, enforcement lives in CI and GitOps review. We don't yet refuse workloads at the cluster admission layer (an admission controller that rejects an unsigned or non-compliant image), and we don't yet sign application artifacts end to end. Those are the next gates, not finished ones. Claiming otherwise would be exactly the governance theatre this argues against.
| Layer | Records (knows) | Enforces (stops) |
|---|---|---|
| Catalog + CODEOWNERS | Who owns what | None |
| Scorecards / SBOM | Which checks pass; what's inside | None |
| Blocking CI gates | A failing report | Won't merge |
| Required GitOps review | Who approved | No merge, no deploy |
| Admission control / signing | None | Next gate, not yet built |
The honest limits: the gates we haven't built yet
Governance-in-the-path is powerful, and incomplete. Name what it doesn't cover.
First: when the pipeline is the only door, the pipeline becomes the thing to protect. The platform holds the keys to every environment. Scope its credentials, keep RBAC deny-by-default, treat the platform itself as a high-value target. Securing with the platform is no excuse for not securing the platform itself. And infrastructure you own and can open up is easier to audit than a service whose insides you're not allowed to see.
Second: the gates we just admitted we don't have (cluster admission control and artifact signing) are real gaps. Today a careless or malicious change gets caught by CI and review, not refused at the cluster. Closing that is the roadmap, and naming it is the difference between a control and a claim.
Third: evidence generated and never read is theatre. An SBOM that lands in a bucket nobody watches isn't security: pipe it into a monitored vulnerability feed, or admit you've automated a checkbox.
And paved roads, not walls. The golden path works because it's the easy path, not because it's the only one allowed. DORA's 2024 research is blunt that a platform imposed badly can slow delivery, "requiring careful implementation focused on developer independence." Governance that developers route around isn't governance.
So what's the bar?
Final thoughts
Governance that lives in a document is governance you hope for. Governance that lives in the deployment path is governance you can prove: enforced where the work happens, recorded in git, inherited by every new service by default. For a scaleup that can't staff a compliance function, that's the only version that scales, and the only one that survives an audit.
The test was never "do we have a policy," or even "do we have a catalog." It's "could a bad change reach production, and can we show who shipped what?" The record is the easy part. The gate is the work. And some gates are still on our roadmap, which is the honest answer.
The Cyber Resilience Act's main obligations arrive in December 2027. The teams that put ownership, controls, and review into the path now are the ones who won't be assembling evidence by hand later. If you're not sure whether your own deployment path governs or just describes, hand the question to a second pair of eyes: an architecture review is a low-commitment way to find out. Before an auditor, or an incident, asks it for you.