Who owns NIS2 and DORA on a Kubernetes platform team

There is a meeting that repeats across a lot of European engineering organizations right now. Someone from legal or risk brings a NIS2 control, a DORA article, or a "can we evidence this" request into the room. The Kubernetes platform team looks at security. Security looks at the platform team. A ticket lands on the security board, because that feels like the responsible place for anything with a regulation in the title. Three sprints later the cluster has not changed, the evidence still does not exist, and everyone is quietly annoyed with the security lead.

The failure is not legal and it is not technical. It is an ownership failure, with a specific shape: a regulation name was put on a board instead of an artifact being put in a sprint. Security can write the policy. Security cannot merge the Helm chart.

This article — by Matteo Bisi of Reevo — closes that gap on a cloud native platform: the traceability chain from a regulatory requirement to a Kubernetes object, a RACI that survives contact with sprint planning, and the open source projects that actually produce the evidence.

Caveat: nothing here is legal advice, and none of the mappings are official compliance mappings. NIS2 and DORA are outcome-based texts. Which entities and services are in scope, what measures are proportionate, and what evidence is sufficient depend on the organization's own risk assessment, its sector rules, national transposition, and its regulator — not on a table in a blog post.

What happens when security owns the regulation

The common default is that anything with a regulation in the title becomes a security ticket. The CISO — or the one senior security engineer who still answers Slack — becomes the owner of NIS2, DORA, and whatever arrives next. Platform engineers stay on product work. Security becomes a queue.

Two failure modes follow, and they feed each other:

• The bottleneck. Every image exception, every privileged securityContext, every "we need this log in the SIEM" request waits on the same two people. Delivery teams learn that talking to security is how work dies, so they route around it: a break-glass kubeconfig here, a sidecar nobody reviewed there, a registry that is not the approved catalog.
• Learned helplessness. If compliance is permanently someone else's backlog, platform engineers never own the reasoning behind it. They ship an admission policy because they were told to, disable it when it blocks a release, and wait for security to notice. A platform team can't be asked to own outcomes while the regulatory outcome sits on another team's board.

Neither failure is a personality problem. Both are org designs nobody named out loud.

What NIS2 Article 20 and DORA Article 5 actually assign

Both texts are blunt about where accountability sits — and it is not "the security team."

• NIS2 Article 20 places cybersecurity risk-management measures on the management body of essential and important entities. It approves the measures, oversees implementation, can be held liable for non-compliance, and is required to follow training.
• DORA Article 5 does the same for financial entities: the management body defines, approves, oversees, and remains responsible for the ICT risk management framework, and roles and responsibilities for all ICT-related functions must be assigned clearly and documented. A CISO title is not a substitute — it is one of the roles the assignment has to name.

But a board problem becomes a middle-management problem by Friday afternoon. The management body will not patch containerd. It will not decide whether kube-apiserver audit logs are retained for 12 months or 18. It will not sit in the planning session where "ship the new tenant" competes with "we still have no evidence trail." Those decisions are made by engineering managers — or they are not made at all. The same vacuum appears in Cyber Resilience Act programs, which carry a harder clock.

Put artifacts on the board, not regulation names

A regulation is a reason, not a ticket. "NIS2 Article 21" cannot be demoed at sprint review. "kube-apiserver audit policy shipped, logs shipped to the SIEM, retention documented" can be.

The artifact comes from a traceability chain with a clean handover in the middle: steps one to three (scope, control question, evidence definition) belong to risk, legal, and security; steps four to six (artifact, sprint item, recurring operation) belong to the platform and application teams. The handover is the artifact, not the article number. A ticket that says "implement NIS2 Article 21(2)(d)" has skipped the middle of the chain and asks an engineer to act as the lawyer who decided the law applies.

The chain closes: step six produces the evidence step three asked for, so delivery output flows back to risk, audit, and the SOC as routine — not as a fire drill three days before an inspection.

What that looks like in practice (provenance columns point at provisions that make the artifact relevant, not a claim the text commands that implementation):

Operational artifact	Control question it answers	NIS2 provenance	DORA provenance
Hardened image catalog & rebuild pipeline	Can we reduce known weaknesses and rebuild promptly on disclosure?	Art. 21(2)(d),(e)	Arts. 8, 9
Secrets manager as the only credential path	Can we protect credentials and show secrets aren't spread through code/config?	Art. 21(2)(i),(j)	Art. 9
Audit logs + ingress logs in the SIEM	Can we detect suspicious activity and retain evidence?	Art. 21(2)(b)	Arts. 10, 17
Admission policy: restricted PSS, no unpinned tags	Can we prevent unsafe configs reaching production, with recorded exceptions?	Art. 21(2)(f),(i)	Art. 9
Incident runbook & 24-hour fact pack	Can on-call establish what happened, impact, and facts for escalation?	Arts. 21(2)(b), 23	Arts. 17, 19
SBOM generated & retained in CI	Can we identify what we shipped, and when?	Art. 21(2)(d),(e)	Art. 28

The cloud native projects that produce the evidence

None of these artifacts requires a compliance product — the kind of tool that generates evidence about a platform it does not otherwise touch. They are ordinary platform capabilities, and open source covers most of them:

• Hardened image catalog & rebuild pipeline — Harbor (registry), Sigstore (signing/verification), in-toto (attestations), an image scanner in CI. The product isn't the pipeline; it's the rebuild cadence, sustained across every base image in the week half the team is on holiday. Sourcing the base layer from someone who maintains it full-time is legitimate — the provider then enters third-party scope under NIS2 Art. 21(2)(d) and DORA Art. 28.
• Secrets as a managed service — OpenBao or equivalent, External Secrets Operator to project secrets, SPIFFE/SPIRE for workload identity, cert-manager for certificate lifecycle. One credential path: identity-based, short-lived, no long-lived tokens in manifests.
• Audit & detection evidence — Kubernetes audit policy, Fluentd/Fluent Bit + OpenTelemetry for collection, Falco for runtime events, Prometheus for operational signals. The SIEM at the far end is usually bought; the collection path is yours.
• Admission control & exceptions — Kyverno or OPA Gatekeeper plus Kubernetes Pod Security Admission. Policies in version control, exceptions expressed as objects that expire rather than Slack messages.
• Software inventory — SBOM generation in CI, stored as an attestation next to the artifact, not in a wiki.
• Service ownership metadata — Backstage or equivalent, so "who is the engineering manager for this service" is machine-readable — which is what makes the RACI real.

The real point: a cluster can have Kyverno installed, Falco running, and SBOMs in CI and still fail an inspection — because nobody can say who decided what "acceptable" means, or who is accountable for keeping it that way. Tooling is the easy half.

A RACI that survives sprint planning

Once the traceability chain exists, the RACI answers who gets the artifact over the line and keeps it true:

Artifact	Responsible	Accountable	Consulted	Informed
Hardened image catalog & rebuild pipeline	Platform engineers	Platform eng. manager	Security (policy, CVE exceptions)	App teams, risk
Secrets manager as only credential path	Platform engineers	Platform eng. manager	Security, IAM	App eng. managers
Audit logs into the SIEM	Platform & SRE	Platform eng. manager	Security & SOC	Risk, CISO
Admission policy	Platform engineers	Platform eng. manager	Security (exceptions)	App teams
Incident clock: detect, page, assemble facts	On-call engineer	Service eng. manager	Security, legal, comms	Mgmt body, CSIRT
Notification to authority	Security / control function	CISO or nominated role	Legal, eng. manager	Mgmt body
SBOM for what you actually ship	Build engineers	Eng. manager of pipeline	Security (format, retention)	Procurement, risk
Exception to run privileged/hostNetwork	Requesting engineer	Requesting eng. manager	Security	Platform, risk

Security is rarely Accountable for the artifact itself. A secrets manager and an image catalog are services the platform team runs, not appliances security sprinkles on at the end.

Three rows worth spelling out

Detection is not notification. Incident detection and authority notification are different jobs on different clocks. NIS2 Art. 23 expects an early warning to the CSIRT/competent authority within 24 hours of becoming aware of a significant incident, a notification within 72 hours, and a final report within a month. If you make the on-call engineer "own NIS2 reporting," you get panic or silence at 02:00. The engineer owns the facts — what broke, when, blast radius, what's done. The nominated control function owns the notice. An early warning is a factual submission, not a root cause analysis; audit logs and a rehearsed runbook are what make the facts gather-able in minutes.

Exceptions belong to the requesting engineering manager. Security can advise that CAP_SYS_ADMIN in a production namespace is a bad idea — only the requesting team's manager can decide the product risk is worth it, write it down, and set an expiry. If security owns exceptions, every exception becomes a negotiation with the person everyone avoids, and the real decision maker stays invisible. Making the requesting manager accountable puts the cost where the benefit is, and the exception gets a natural expiry: the manager who wanted it renews it.

Capacity is the part that gets skipped. The useful test in planning: is the artifact in the next sprint with a named engineering manager, or is it still a control statement on a security slide? A second question: who is holding work labeled "security" or "compliance" that should not be theirs? Cutting scope honestly beats putting "DORA" on a slide and leaving engineers to find hours in the evening.

Security still sets the bar — what "restricted" means, which CVEs are acceptable, what a fact pack contains. But Consulted has to mean "answers within the same sprint," not "joins a working group." Teams walk toward security when talking to it makes the work smaller; they walk around it when it does the opposite.

Bottom line

The chain is short. The management body is accountable in the text; the engineering manager is accountable in the cluster; security is the specialist you consult; the engineer is responsible for the object that ships. Staff only the management body and security, and you get policies and liability with no Kubernetes. Staff only the engineering manager and engineer, and you get a fast platform you can't explain to a supervisor.

Next time a regulation lands in the room, don't look at security first. Look at the engineering manager who owns the system the requirement describes, and ask two questions: which artifact will you demo, and which sprint is it in? If there's no answer, the organization doesn't have a security gap. It has an ownership gap — and those are the expensive ones.

References: Regulation (EU) 2024/2847 (CRA), Directive (EU) 2022/2555 (NIS2), Regulation (EU) 2022/2554 (DORA).