# Closing the Compliance Gap on Kubernetes Platforms: From Regulation to Evidence
## The Ownership Problem Nobody Names
Across engineering organizations in Europe, a familiar scene plays out regularly. Someone from legal or risk walks into a room carrying a NIS2 requirement, a DORA obligation, or a simple “can we show evidence of this?” request. The Kubernetes platform team and the security team look at each other. A ticket gets filed on the security board because anything with a regulation attached feels like security’s responsibility. Three sprints pass. The cluster remains unchanged. The evidence does not exist. And quietly, everyone grows frustrated with the security lead.
This is not a legal problem. It is not a technical problem. It is a structural failure of ownership, and it follows a predictable pattern. A regulation’s name lands on a project board, but no actual deliverable makes it into a sprint. Security teams can draft the policy. Security teams cannot merge the Helm chart, update the admission controller, or maintain the audit pipeline. The result is a growing backlog of control statements that exist only as text on a slide and never as a running system.
The deeper issue is that when compliance becomes permanently someone else’s backlog, platform teams never develop the reasoning behind it. They install 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 what every platform engineering practice asks for. You cannot ask a team to own outcomes while keeping the regulatory outcome on another team’s board entirely.
## Where Accountability Actually Lives in NIS2 and DORA
Both NIS2 and DORA are blunt about where accountability sits, and it is not with the security team. NIS2 Article 20 places cybersecurity risk-management obligations on the management body of essential and important entities. That management body approves the measures, oversees their implementation, can be held liable for non-compliance, and is required to ensure appropriate training.
DORA Article 5 mirrors this for the financial sector. The management body defines, approves, and oversees the ICT risk management framework, with clear roles and responsibilities assigned and documented for all ICT-related functions. A CISO title alone does not satisfy this requirement. The CISO is one role within the assignment, not a replacement for it.
The challenge is that the management body will not patch containerd, decide on audit log retention periods, or sit in the sprint planning session where “ship the new tenant” competes with “we still have no evidence trail.” Those decisions happen at the engineering manager level, or they simply do not happen at all.
This creates a vacuum. Legal translates the regulation into control language. Security writes the control statement. But nobody is accountable for the actual Kubernetes object that would make the statement true. The same vacuum appears in Cyber Resilience Act programs, which carry a tighter compliance clock. Accountability at the top becomes theater unless someone in engineering owns the work that produces the tangible evidence.
## From Regulation Names to Concrete Artifacts
A regulation is a reason for doing something. It is not itself a piece of work. “NIS2 Article 21” cannot be demonstrated at sprint review. But “kube-apiserver audit policy shipped, logs flowing to the SIEM, retention period documented” can be.
The artifact does not come from an engineer reading a directive and independently inventing a Kubernetes task. It emerges from a traceability chain with a clean handover in the middle. The first phase involves interpreting the regulation: determining scope, formulating the control question, and defining what evidence would be sufficient. That work belongs to risk, legal, and security. The second phase involves building and operating the artifact: creating the sprint item, delivering it, and maintaining it as a recurring operational responsibility. That work belongs to platform and application teams.
The handover between these two phases is the artifact itself, not the article number from the regulation. A ticket that says “implement NIS2 Article 21(2)(d)” has skipped the critical middle of the chain and asks an engineer to act as the legal team that decided the regulation applies in the first place.
This chain also closes the loop. The output of delivery produces the evidence that the interpretation phase asked for, meaning that the work flows back to risk, audit, and the security operations center as routine business rather than as an emergency scramble days before an inspection. An artifact that only exists because someone ran a script manually once has not completed the chain.
## The Open Source Tools That Build the Evidence
The artifacts described here do not require a specialized compliance product. They are ordinary platform capabilities, and the open source ecosystem covers the majority of them. Sigstore and OpenBao sit outside the CNCF umbrella, falling under the OpenSSF and the Linux Foundation respectively, but every other tool in this stack is CNCF-graduated or incubating and all of it is open source.
A hardened image catalog and rebuild pipeline draws on Harbor for the registry, Sigstore for signing and verification, in-toto for supply chain attestations, and an image scanner integrated into CI. The platform team’s operational responsibility is maintaining a base image that is rebuilt on a defined schedule and when advisories are published, then published to a single registry from which workloads are permitted to pull.
Secrets as a managed service relies on OpenBao or an equivalent open source secrets manager as the store, the External Secrets Operator to project secrets into the cluster, SPIFFE and SPIRE for workload identity, and cert-manager for certificate lifecycle management. The goal is a single credential path: identity-based, short-lived, with no long-lived tokens buried in manifests or CI variables.
For audit and detection evidence, the stack includes the upstream Kubernetes audit policy, Fluentd or Fluent Bit with OpenTelemetry for log collection, Falco for runtime security events, and Prometheus for operational signals. The platform team must operate an audit policy that is not set to None, a shipping pipeline that survives node churn, and a documented retention setting.
Admission control and exception management use Kyverno or OPA Gatekeeper alongside the upstream Pod Security Admission baseline. The operational model is policies stored in version control, enforced in production, with exceptions expressed as Kubernetes objects that carry expiration dates rather than existing as Slack messages that nobody remembers.
Software inventory is handled through SBOM generation embedded in CI, stored as an attestation alongside the artifact itself rather than in a wiki page. The result is an answer to “what was in the image we deployed on the fourteenth” that takes minutes rather than days.
Service ownership metadata is best served by Backstage or an equivalent service catalog. This provides a machine-readable answer to “who is the engineering manager for this service,” which is what makes a RACI framework actually operational rather than decorative.
## A Practical RACI for Platform Compliance Work
Once the traceability chain is established, the RACI framework answers the remaining question: who gets the artifact across the finish line and who keeps it accurate afterward? The key insight 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 installs at the end.
For the hardened image catalog and rebuild pipeline, platform engineers are Responsible, the platform engineering manager is Accountable, security consults on policy and CVE exceptions, and application teams and risk stay Informed. For the secrets manager as the single credential path, the same pattern applies: platform engineers build and operate, the platform engineering manager remains accountable, security and IAM provide guidance, and application engineering managers receive visibility.
Audit logs flowing into the SIEM place platform and SRE teams in the Responsible role, with the platform engineering manager Accountable. Security and the SOC consult on what evidence is actually required, while risk and the CISO are Informed. The incident clock — detecting, paging, and assembling facts — places the on-call engineer in the Responsible seat, with the engineering manager who owns that service being Accountable. Security, legal, and communications are Consulted, and the management body and CSIRT are Informed.
For notification to the authority, security or the nominated control function handles execution, with the CISO or a nominated role taking Accountable. Legal and the engineering manager of the affected system are Consulted, and the management body is Informed. The SBOM in CI for what is actually shipped places the engineers who build the artifact in the Responsible role, with the engineering manager of that pipeline as Accountable.
Exceptions to run privileged workloads or use host networking are requested by the engineer, but the requesting engineer’s manager is Accountable. Security is Consulted, and platform and risk are Informed.
A RACI is a communication tool, not a governance artifact in isolation. If a table is published and never opened during planning, it has produced nothing more than stationery. Two categories of ownership get confused more often than the rest and deserve explicit attention: the separation between detection and notification, and the placement of exception accountability.
## Detection Is Not Notification
Incident detection and authority notification are different functions operating on different timelines. NIS2 Article 23 expects an early warning to the CSIRT or competent authority within 24 hours of becoming aware of a significant incident, a formal incident notification within 72 hours, and a final report within one month. DORA establishes its own reporting paths and deadlines for major ICT-related incidents.
Assigning the on-call engineer the ownership of NIS2 reporting leads to either panic or silence at two in the morning. The engineer owns the facts: what broke, when it broke, the blast radius, and what has already been attempted. 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.
This separation is what makes the 24-hour clock survivable in practice. An early warning is a factual submission, not a root cause analysis. The platform’s responsibility is to make those facts easy to gather within minutes, which is exactly what well-maintained audit logs and a rehearsed incident runbook provide.
## Exceptions Belong to the Requesting Manager
Security can advise that running a pod with CAP_SYS_ADMIN in a production namespace is inadvisable. Only the requesting team’s engineering manager can decide that the product risk justifies the exception, document the reasoning, and set an expiry date.
If security is made Accountable for exceptions, every exception becomes a negotiation with the person everyone is trying to avoid bothering, and the real decision maker stays invisible. Making the requesting engineering manager Accountable places the cost of the decision back where the benefit is realized, and it gives the exception a natural expiration: the manager who requested it is the one who must actively renew it.
## Capacity Planning for Compliance Work
The most telling test in any planning session is straightforward: is the artifact scheduled for the next sprint with a named engineering manager, or does it still exist only as a control statement on a security slide? A second, more uncomfortable question follows: who is currently holding work labeled “security” or “compliance” that genuinely belongs to another team? An admission policy that the platform team should own is one example. A forty-page control mapping that belongs with risk is another.
Capacity is where these programs quietly collapse. A platform team sized for product delivery alone will treat every compliance control as overtime work. 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 unrealistic. Cutting scope honestly produces a better outcome than putting “DORA” on a slide and leaving engineers to find the hours in their evenings.
Security still sets the standard. What “restricted” means in practice, which CVEs are acceptable as exceptions, what a fact pack must contain, and which logs the security operations team will actually use — all of that work remains essential. Security reviews exceptions, runs or supports the notification path, and trains engineering managers until those managers can hold the conversation without forwarding every email to the CISO.
However, “Consulted” must mean “answers within the same sprint,” not “joins a working group that meets monthly.” If the security function cannot staff that level of responsiveness, the honest move is to shrink the control set rather than maintain a queue that delivery teams learn to avoid. Teams move toward security when engaging with it makes the work smaller and clearer. They move around it when the opposite is true.
The sentence “we cannot show who had access to kube-apiserver during last week’s incident” is a useful signal in the second week of a compliance program. The same sentence spoken the week before an on-site inspection is a significantly more expensive problem.
## Putting It Together: The Engineering Manager as the Linchpin
The chain of accountability is short. The management body is accountable under the regulation. The engineering manager is accountable for the cluster. Security is the specialist you consult so that the work is technically sound. The individual engineer is responsible for the specific object that ships.
Staff only the management body and the security function, and you end up with policies and liability but no Kubernetes. Staff only the engineering manager and the engineer, and you get a fast platform that you cannot explain to a supervisor or an auditor. Both halves carry the load.
The next time a regulation enters 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 demonstrate, and which sprint does it land in? If there is no answer, the organization does not have a security gap. It has an ownership gap, and those are the ones that prove most expensive to close.
—
## Frequently Asked Questions
**What is NIS2 and why does it matter for Kubernetes platforms?**
NIS2, or the Network and Information Security Directive 2022/2555, is an EU regulation that expands cybersecurity requirements across essential and important entities. For Kubernetes platforms, it matters because it imposes obligations around supply chain security, vulnerability handling, access control, and incident management — all of which translate directly into Kubernetes configuration, policy, and operational practices.
**How does DORA differ from NIS2 in its impact on platform engineering?**
DORA (Digital Operational Resilience Act, Regulation EU 2022/2554) applies specifically to financial entities and their ICT service providers. While NIS2 covers a broader set of essential and important entities, DORA adds specific requirements around ICT risk management frameworks, third-party risk management, and incident reporting with defined timelines. Both require platform teams to produce tangible evidence of controls, but DORA’s financial sector focus means the audit and reporting expectations are particularly strict.
**What does “ownership gap” mean in the context of compliance?**
An ownership gap occurs when a regulatory requirement is assigned to a team — typically security — that lacks the authority or ability to actually build and operate the technical controls. Security can write the policy, but it cannot merge the code, update the Helm chart, or maintain the audit pipeline. The gap is between the team that is accountable for compliance on paper and the team that actually operates the infrastructure.
**Why should artifacts be put on the sprint board instead of regulation names?**
A regulation name is a reason, not a deliverable. “NIS2 Article 21” cannot be demonstrated, tested, or deployed. A concrete artifact like “hardened image catalog with signed images and documented rebuild cadence” can be demoed, tested, and pointed to during an audit. Sprint planning works with deliverables, not with regulation references.
**Which open source tools are most commonly used to produce compliance evidence on Kubernetes?**
The most common open source tools include Harbor for container registries, Sigstore for artifact signing, in-toto for supply chain attestations, OpenBao for secrets management, SPIFFE/SPIRE for workload identity, Kyverno or OPA Gatekeeper for admission control, Falco for runtime detection, Fluentd/Fluent Bit with OpenTelemetry for log collection, and Backstage for service ownership metadata.
**What is the difference between detection and notification in incident response?**
Detection is the process of identifying that an incident has occurred and gathering the factual details: what happened, when, what was affected, and what response actions have been taken. Notification is the formal communication to the competent authority, which has its own legal timeline and requirements. These are distinct responsibilities that should be assigned to different roles.
**How should exceptions to security policies be managed on Kubernetes?**
Exceptions should be expressed as Kubernetes objects (such as custom resources managed by Kyverno or OPA Gatekeeper) that carry explicit expiration dates. The engineering manager who requested the exception is Accountable for it, ensuring that exceptions are reviewed and renewed rather than persisting indefinitely as unreviewed configuration.
**Can platform teams realistically handle compliance work without dedicated compliance staff?**
Yes, but only if the compliance work is properly scoped and distributed. The key is to convert regulation requirements into specific, sized backlog items with clear ownership, rather than treating compliance as a separate workstream. Security provides the requirements and reviews the output, but the platform team builds and operates the controls.
**What happens if a platform team cannot keep up with the compliance workload?**
The honest response is to reduce the scope of controls rather than overcommit and fail. A smaller set of well-maintained, demonstrable controls is better than a large set of neglected ones. Additionally, sourcing components from vendors who maintain them full-time can reduce the platform team’s operational burden, though the accountability for supplier management then shifts to the organization.
**Is the RACI framework described in this article a governance model?**
The RACI described here is a communication tool, not a standalone governance model. Its value comes from being actively used — reviewed during sprint planning, updated when team structures change, and referenced when tickets are created. A RACI table that sits in a document repository and is never consulted has no practical effect.
—
## Conclusion
Closing the compliance gap on a Kubernetes platform is fundamentally an organizational design challenge, not a technical one. The open source ecosystem provides the tools to build hardened image catalogs, manage secrets, enforce admission policies, collect audit logs, generate SBOMs, and maintain service ownership metadata. What it cannot provide is the ownership structure that ensures these tools are actually operated, maintained, and accountable.
The path forward requires three things working together. First, a traceability chain that translates regulation articles into concrete artifacts with clear control questions and evidence requirements. Second, a RACI framework that places accountability with the platform engineering managers and individual engineers who build and run the systems, rather than with the security function that advises and reviews. Third, honest capacity planning that acknowledges compliance work has a cost and that cutting scope is a legitimate decision when resources are constrained.
The management body is accountable in the text of the regulation. The engineering manager is accountable in the cluster. When these two connect through a well-defined handoff — the artifact, not the article number — organizations move from reactive compliance scrambling to proactive platform ownership. The tools are available, the practices are proven, and the remaining work is entirely within the power of any engineering organization willing to name the ownership explicitly.
Thank you for reading
