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, and it has 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 is about closing 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.

One caveat before going further. Nothing here is legal advice, and none of the mappings below are an official compliance mapping. NIS2 and DORA are outcome-based texts. Which entities and services are in scope, what measures are proportionate, and what evidence is sufficient all depend on the organization’s own risk assessment, its sector rules, national transposition, and its regulator. They do not depend 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. Application teams stay on features. The security function becomes a queue.

Two failure modes follow, and they feed each other.

The first is 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 start routing around it: a break-glass kubeconfig here, a sidecar nobody reviewed there, a registry that is not the approved catalog.

The result rarely announces itself. Non-compliance does not show up as a red cell on a slide; it shows up as shadow infrastructure carrying a ticket label that still says “security”.

The second is learned helplessness on the platform side. 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. That is the opposite of the ownership every platform engineering talk asks for. You cannot ask a team to own outcomes and simultaneously keep the regulatory outcome on another team’s board.

Neither failure is a personality problem. Both are org designs that 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. The management body approves the measures, oversees their 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 have to be assigned clearly and documented. A CISO title is not a substitute for that assignment; it is one of the roles the assignment has to name.

So far this reads like a board problem. By Friday afternoon it is a middle-management problem. 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 vacuum underneath the management body is where most programs die. Legal translates the article. Security writes a control statement. Nobody is accountable for the Kubernetes object that would make the statement true. The same vacuum appears in Cyber Resilience Act programs, which carry a harder clock: accountability at the top is theater unless someone in engineering owns the work that produces the evidence.

Put artifacts on the board, not regulation names

A regulation is a reason. It is 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 does not come from an engineer reading a directive and inventing a Kubernetes task. It comes from a traceability chain with a clean handover in the middle.

Traceability chain in two stages: scope, control question, and evidence definition owned by risk, legal, and security; artifact, sprint item, and recurring operation owned by the platform and application teams

Steps one to three are interpretation, and they belong to risk, legal, and security. Steps four to six are delivery, and they 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 also closes. Step six is what produces the evidence that step three asked for, which means the output of delivery flows back to risk, audit, and the SOC as a matter of routine rather than as a fire drill three days before an inspection. An artifact that only exists because someone ran a script by hand once has not completed the chain.

The table below shows what the output of that chain looks like on a Kubernetes platform. The middle column is the control question the artifact answers. The provenance columns point at the provisions that make the artifact relevant; they are not a claim that the text commands that specific implementation. DORA references apply only where the financial entity and the ICT service fall within its scope.

Operational artifact	Control question it answers	NIS2 provenance	DORA provenance
Hardened image catalog and rebuild pipeline	Can we reduce known weaknesses in deployed software, and rebuild promptly when a material vulnerability is disclosed?	Article 21(2)(d) and (e): supply chain security, vulnerability handling and disclosure	Articles 8 and 9: ICT asset identification, protection and prevention
A secrets manager as the only credential path	Can we protect credentials, limit access to them, and show that secrets are not spread through code and cluster configuration?	Article 21(2)(i) and (j): access control, asset management, multi-factor authentication	Article 9: protection and prevention measures
Kubernetes audit logs and ingress logs in the SIEM	Can we detect suspicious activity, investigate an incident, and retain the evidence for the required period?	Article 21(2)(b): incident handling	Articles 10 and 17: detection capabilities, ICT-related incident management
Admission policy: restricted Pod Security Standards, no unpinned image tags	Can we prevent unsafe workload configurations from reaching production, while recording approved exceptions?	Article 21(2)(f) and (i): policies on effectiveness, access control, asset management	Article 9: protection and prevention measures
Incident runbook and a 24-hour fact pack	Can on-call staff establish what happened, its impact, and the facts needed for a timely escalation?	Articles 21(2)(b) and 23: incident handling, early warning within 24 hours and notification within 72 hours	Articles 17 and 19: incident management, reporting of major incidents
SBOM generated and retained in CI	Can we identify what software we shipped, and when, if a supplier, package, or vulnerability requires investigation?	Article 21(2)(d) and (e): supply chain security, vulnerability handling	Article 28: ICT third-party risk management

A ticket that names the artifact, links the control question, states the evidence, and has a person who can finish it is a concrete piece of work. It can be estimated, it can be demoed, and (the part that matters at audit time) it can be pointed at.

The cloud native projects that produce the evidence

None of these artifacts requires a compliance product, in the sense of a tool that generates evidence about a platform it does not otherwise touch. They are ordinary platform capabilities, and the open source ecosystem covers most of them. Not everything in the table below is a CNCF project (Sigstore and OpenBao sit under the OpenSSF and the Linux Foundation respectively), but all of it is open source and all of it can be run by the team that owns the cluster.

The table is illustrative rather than prescriptive. It answers “can this be built with open source”, which is not quite the question a platform lead faces.

Artifact	Open source building blocks	What the platform team actually operates
Hardened image catalog and rebuild pipeline *	Harbor for the registry, Sigstore for signing and verification, in-toto for attestations, an image scanner in CI	A base image that is rebuilt on a schedule and on advisory, published to one registry that workloads are allowed to pull from
Secrets as a managed service	OpenBao or an equivalent open source secrets manager as the store, External Secrets Operator to project secrets into the cluster, SPIFFE and SPIRE for workload identity, cert-manager for certificate lifecycle	One credential path: identity-based, short-lived, with no long-lived tokens in manifests or CI variables
Audit and detection evidence	Kubernetes audit policy upstream, Fluentd or Fluent Bit and OpenTelemetry for collection, Falco for runtime events, Prometheus for the operational signals	An audit policy that is not None, a shipping pipeline that survives node churn, and a retention setting someone has written down (the SIEM at the far end is usually bought; the collection path is yours)
Admission control and exceptions	Kyverno or OPA Gatekeeper, plus the upstream Pod Security Admission baseline	Policies in version control, enforced in production, with exceptions expressed as objects that expire rather than as Slack messages
Software inventory	SBOM generation in CI, stored as an attestation next to the artifact rather than in a wiki	An answer to “what was in the image we deployed on the 14th” that takes minutes, not days
Service ownership metadata	Backstage or an equivalent catalog	A machine-readable answer to “who is the engineering manager for this service”, which is what makes the RACI below real

* Buildable and realistic to operate are different claims, and the hardened image catalog is where they diverge most. The pieces are all open source, but the product is not the pipeline; it is the rebuild cadence, sustained across every base image and runtime you ship, in the week half the team is on holiday. Few platform teams are funded for that, and a catalog that goes stale is worse than no catalog, because by then a control statement says it is handled. Sourcing the base layer from someone who maintains it full time is a legitimate answer, and it does not remove the ownership question so much as change its shape: the provider enters third party scope under NIS2 Article 21(2)(d) and DORA Article 28, and supplier management needs a named owner exactly as the pipeline did.

None of this is unique to regulated industries. It is the same platform baseline most mature teams build anyway; NIS2 and DORA mostly change the deadline and the consequence of missing it. Open source removes the license barrier rather than the staffing one, so the build or source decision belongs in the roadmap for every row, not just the one carrying the asterisk.

Which is the real point of the table. 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 for a Kubernetes platform

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

Adjust the role names to your organization. Do not adjust the underlying idea, which is that security is rarely Accountable for the artifact. A secrets manager and a hardened image catalog are services the platform team runs, not appliances that security sprinkles on at the end.

Artifact	Responsible	Accountable	Consulted	Informed
Hardened image catalog and rebuild pipeline	Platform engineers	Platform engineering manager	Security (policy, CVE exceptions)	Application teams, risk
Secrets manager as the only credential path	Platform engineers	Platform engineering manager	Security, IAM	Application engineering managers
Kubernetes audit logs and ingress logs into the SIEM	Platform and SRE	Platform engineering manager	Security and SOC (what evidence is required)	Risk, CISO
Admission policy (restricted PSS, no :latest)	Platform engineers	Platform engineering manager	Security (exceptions)	Application teams
Incident clock: detect, page, assemble facts	On-call engineer	Engineering manager who owns that service	Security, legal, communications	Management body, CSIRT
Notification to the authority	Security or the nominated control function	CISO or nominated role	Legal, engineering manager of the affected system	Management body
SBOM in CI for what you actually ship	Engineers who build the artifact	Engineering manager of that pipeline	Security (format, retention)	Procurement, risk
Exception to run privileged or with hostNetwork	Requesting engineer	Requesting engineer’s manager	Security	Platform, risk

A RACI is a communication tool, not a governance artifact in its own right. If you publish the table and never open it during planning, you have produced stationery. Two rows get confused more often than the rest, and both are worth stating explicitly.

Detection is not notification

Incident detection and authority notification are different jobs on different clocks. NIS2 Article 23 expects an early warning to the CSIRT or competent authority within 24 hours of becoming aware of a significant incident, an incident notification within 72 hours, and a final report within a month. DORA sets its own reporting path and deadlines for major ICT-related incidents.

If you make the on-call engineer “own NIS2 reporting”, you will get panic or silence at 02:00. The engineer owns the facts: what broke, when, the blast radius, what has already been done. The nominated control function owns the notice to the authority. The engineering manager owns whether the runbook was rehearsed before the night it was needed.

That separation is also what makes the 24-hour clock survivable. An early warning is a factual submission, not a root cause analysis. The platform’s job is to make those facts easy to gather in minutes, which is exactly what audit logs and a rehearsed runbook are for.

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 that the product risk is worth it, write down the reason, and set an expiry.

If security is Accountable for exceptions, every exception becomes a negotiation with the person everyone is trying not to bother, and the real decision maker stays invisible. Making the requesting manager accountable puts the cost back where the benefit is, and gives the exception a natural expiry date: the manager who wanted it is the one who has to renew it.

Capacity is the part that gets skipped

The useful test in a planning session is simple: 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, more uncomfortable question follows: who is currently holding work labeled “security” or “compliance” that should not be theirs? An admission policy the platform should own is one answer. A 40-page control mapping that belongs with risk is another.

Capacity is where these programs quietly fail. A platform team staffed for product delivery alone will treat every control as overtime. They will ship the hardened image catalog, or they will ship the new tenant environment. They will not ship both from the same three people unless the roadmap is quietly optimistic. Cutting the scope honestly is a better outcome than putting “DORA” on a slide and leaving engineers to find the hours in the evening.

Security still sets the bar, and that work does not go away: what “restricted” means in practice, which CVEs are acceptable exceptions, what a fact pack must contain, which logs the SOC will actually use. It reviews exceptions, runs or supports the notification path, and trains engineering managers until they can hold the conversation without forwarding every email to the CISO.

But Consulted has to mean “answers within the same sprint”, not “joins a working group”. If the security function cannot staff that responsiveness, the honest move is to shrink the control set rather than to keep a queue that delivery teams learn to avoid. Teams walk toward security when talking to it makes the work smaller and clearer. They walk around it when it does the opposite.

“We cannot evidence access to kube-apiserver for last week’s incident” is a useful sentence in week two of a program. The same sentence the week before an on-site inspection is a much more expensive one.

Look at the engineering manager first

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 so that the work is correct. The engineer is responsible for the object that ships.

Staff only the management body and the security function, and you get policies and liability with no Kubernetes. Staff only the engineering manager and the engineer, and you get a fast platform you cannot explain to a supervisor. Both halves are load-bearing.

So the next time a regulation lands in the room, try not to 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 is no answer, the organization does not have a security gap. It has an ownership gap, and those are the expensive ones.

References

Regulation (EU) 2024/2847 (Cyber Resilience Act): https://eur-lex.europa.eu/eli/reg/2024/2847/oj

Directive (EU) 2022/2555 (NIS2): https://eur-lex.europa.eu/eli/dir/2022/2555/oj

Regulation (EU) 2022/2554 (DORA): https://eur-lex.europa.eu/eli/reg/2022/2554/oj