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. 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. 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