What happened
The CNCF published a piece on a common pattern in European engineering teams: a NIS2 or DORA request arrives, gets filed as a security ticket, and three sprints later the cluster is unchanged and no evidence exists. The article calls this an ownership failure, not a legal or technical one. Its fix is to put concrete artifacts in sprints rather than regulation names on a board.
Why it matters
If you have no platform team, this pattern is probably closer than you think. Security, or one overworked senior engineer, becomes the owner of every regulation. Delivery teams then wait on that person, and some start working around them with unreviewed shortcuts such as an unapproved registry or a break-glass kubeconfig. The article’s point is that non-compliance often shows up as shadow infrastructure, not as a red cell on a slide.
The texts themselves do not put accountability on the security team. According to the article, NIS2 Article 20 and DORA Article 5 place it on the management body, which has to approve, oversee and, under DORA, clearly assign and document ICT roles. Day-to-day decisions, such as how long audit logs are kept, still fall to engineering managers.
The article also stresses that it is not legal advice. Whether you are in scope, and what evidence is enough, depends on your own risk assessment, sector rules, national rules and regulator.
What to do this week
- Find any open ticket titled with a regulation name and rewrite it as a deliverable that can be demoed, for example “API server audit policy shipped, logs forwarded, retention documented”.
- Split the work clearly: risk, legal and security decide scope, the control question and what evidence looks like. Platform and application teams deliver the artifact and run it.
- Name one engineering owner for each artifact, not just a team or a regulation.
- Ask who receives the evidence once it exists, so it flows to audit and the SOC routinely rather than in a rush before an inspection.
- Check with your own legal or compliance contact which entities and services are in scope for you. Do not rely on a blog table, including ours.
Need a hand?
Turning a regulatory requirement into something a Kubernetes team can build and evidence is the kind of work our Security & Compliance service covers. We can help you trace requirements to concrete artifacts and sprint items without adding a platform team. The first call is free and it is with an engineer.
Source: Who owns NIS2 and DORA on a Kubernetes platform team
Related service: Security & Compliance