Having hardened your Kubernetes clusters is good. Being able to show it is what counts when the supervisory authority gets in touch. NIS2 requires cybersecurity risk-management measures, and national laws and regulations in each member state spell out what they should contain. None of them mention Kubernetes, yet almost every requirement lands in the cluster.
This article explains how to turn Kubernetes hardening into evidence that holds up under supervision: which NIS2 requirements touch the platform, how the CIS Benchmark, policies and audit logs work as proof, and which artifacts you should be able to produce in an afternoon.
Questions about this topic? Get in touch with us!
This is a technical walkthrough, not legal advice. If you are unsure whether your organisation is in scope, talk to a lawyer. The legal references were checked on 2 November 2026.
By the Agency 42 team · Last reviewed 2 November 2026
Why "evidence" and not just "hardening"?
NIS2 (Directive (EU) 2022/2555) gives supervisory authorities real tools. For essential entities, Article 32 allows on-site inspections and off-site supervision, regular and targeted security audits, ad hoc audits, security scans, and requests for information and for evidence of implementation of cybersecurity policies. For important entities, Article 33 provides a similar set of tools (without regular audits), used after the fact when the authority has reason to believe the rules are not being followed.
Think of it as bookkeeping. A company can have paid every invoice on time, but without receipts it cannot show the auditor. Security measures work the same way. A tighter cluster configuration without traceable results, versions and dates is a feeling, not evidence.
Which requirements land in the cluster?
Article 21(2) of NIS2 lists ten areas that the measures must at least cover. Several of them are platform work through and through: security in network and information systems acquisition, development and maintenance, including vulnerability handling (point (e)), policies and procedures to assess the effectiveness of the measures (point (f)), basic cyber hygiene (point (g)), cryptography (point (h)), access control and asset management (point (i)) and multi-factor authentication (point (j)).
Member states transpose these points into national law, and some regulators add detailed rules. For cloud computing, data centre and managed service providers, among others, the technical requirements are set directly in Implementing Regulation (EU) 2024/2690 (Article 21(5)). In practice the requirements translate to the cluster like this:
| NIS2 area | What it means in the cluster |
|---|---|
| Asset management (21(2)(i)) | Inventory of clusters, versions, namespaces, owners and suppliers |
| Network security and segmentation | NetworkPolicies with default deny, separate clusters or node pools for sensitive systems |
| Secure configuration (21(2)(e), (g)) | Hardening to vendor recommendations and standards such as CIS, no unnecessary features |
| Access control and MFA (21(2)(i), (j)) | RBAC without broad cluster-admin roles, SSO with MFA for kubectl and consoles |
| Logging and monitoring | API server audit log, collected centrally and analysed |
| Assessing effectiveness (21(2)(f)) | Regular tests showing the chosen configuration is actually in force |
| Change and patch management (21(2)(e)) | GitOps history, upgrade plan and patch routine |
Two things are worth knowing:
Recommendations are not the same as requirements. National rules often mix binding requirements ("shall") with general advice ("should"). In Sweden, for example, the regulator's general advice is to start installing a security update within 72 hours of it becoming available. That is a recommendation, not a legal requirement, but it is a clear signal of what supervisors expect.
Not everyone follows the same detailed rules. Providers covered by Implementing Regulation (EU) 2024/2690 follow its annex for the technical measures, while other sectors follow their national rules. The platform work is much the same, but the references in your documentation differ.
Five kinds of evidence the cluster can produce by itself
1. CIS Benchmark results, with date and version
The CIS Kubernetes Benchmark is a widely used standard for secure configuration. Run the checks automatically, for example with kube-bench, with the built-in CIS profile in RKE2, or with the Compliance Operator (built on OpenSCAP) in OpenShift. What matters for the evidential value:
- store the result per cluster and date, in a machine-readable form,
- document deviations with a rationale and the person who approved them, because a "fail" with an approved rationale is better than a "pass" nobody understands,
- re-run after every upgrade, because the result only applies to the version you actually run.
The same thinking applies to the nodes. Hardening the operating system with OpenSCAP and CIS or DISA STIG profiles produces reports of the same kind. More on that on our Linux page.
2. Policy as code, and reports of what it blocked
It is not enough to write in a policy that containers must not run as root. It should be impossible to get it wrong.
- Enable Pod Security Admission at the restricted level (or at least baseline) per namespace. It is a label on the namespace:
kubectl label namespace payments pod-security.kubernetes.io/enforce=restricted
A pod that, for example, lacks runAsNonRoot or does not drop all capabilities is then rejected directly by the API server. PodSecurityPolicy was removed in Kubernetes 1.25, so if old PSPs still appear in your documentation, it is time to tidy up.
- Use Kyverno or OPA Gatekeeper for rules Kubernetes does not have built in: allowed registries, required image signatures, mandatory resource limits and owner labels.
- Keep the policy reports. Every rejected deployment proves the control works, and collected reports show the effect over time, which is exactly what Article 21(2)(f) asks you to assess.
3. Audit logs you can read after the fact
The API server audit log is the cluster's till roll: who did what, to which resource and when. It covers the use of administrative privileges and changes to permissions. A simple starting point for an audit policy:
apiVersion: audit.k8s.io/v1
kind: Policy
omitStages:
- RequestReceived
rules:
# Permission changes: log the full request and response
- level: RequestResponse
resources:
- group: rbac.authorization.k8s.io
# Secrets and ConfigMaps: who and when, never the content
- level: Metadata
resources:
- group: ""
resources: [secrets, configmaps]
# Interactive access into running pods
- level: Request
resources:
- group: ""
resources: [pods/exec, pods/attach]
# Everything else
- level: Metadata
The first matching rule decides the level, so order matters. Changes to roles and bindings are recorded in full, because "who granted this, and when" is the first question in most reviews. Secrets and ConfigMaps are recorded at metadata level only, so their values stay out of the log. Every exec into a pod leaves a trace with the command that was run. Ship the log to a central system outside the cluster, protect it against tampering and encrypt it in transit. Make sure all nodes use synchronised time, otherwise the logs are hard to correlate when it matters.
4. Change history in Git
With GitOps, for example Argo CD or Flux, Git becomes the change log. Every change has an author, a reviewer, a date and a rationale. That is structured, traceable change management without anyone filling in an extra form. It is also how you detect configuration drift, when the cluster no longer matches what is in Git.
5. Version and patch status per cluster
Vulnerability handling under Article 21(2)(e) means you can show that systems are on supported versions and that published vulnerabilities are dealt with. For the platform that means:
- a list of every cluster with Kubernetes version, distribution and support status,
- scan results for the images running in production, for example from Trivy,
- a plan for clusters approaching end of life. Our Kubernetes 1.34 end-of-support checklist shows what that looks like in practice.
The evidence pack: what you should be able to produce in an afternoon
Our rule of thumb: if the supervisory authority calls on Monday, you should be able to send the following before Friday, without anyone working through the night. The answer to life, the universe and everything may be 42, but the answer to "show us your hardening" should be a folder.
- An inventory of clusters, versions, owners and suppliers.
- The latest CIS results per cluster, with documented deviations.
- Active policies, exported from Git, and policy reports for a recent period.
- The audit policy and examples of audit log analysis (alerts, investigated events).
- An RBAC overview: who has cluster-admin, and why.
- The change log and upgrade history.
- Patch and vulnerability status for images in production.
- The latest review of the security measures and how effective they are.
AI can help compile the pack, summarise logs and spot gaps. But a person reviews it, judges it and stands behind it. That person should also be able to explain it to management, which under Article 20 of NIS2 must approve the measures and take part in training.
Summary
- NIS2 requires risk-management measures (Article 21) and gives supervisors the right to audit, scan and request evidence (Articles 32 and 33).
- National rules, and Implementing Regulation (EU) 2024/2690 for cloud, data centre and managed service providers, make the requirements concrete: configuration, access, logging, testing and change management.
- Make the hardening measurable: CIS results, policy reports, audit logs, Git history and patch status.
- Collect everything in an evidence pack that is built continuously, not the night before the audit.
Make this a priority now if:
- you are in scope of NIS2 and run production on Kubernetes,
- you do not know who has cluster-admin in every cluster today,
- the audit log is not enabled, or is only stored inside the cluster.
Frequently asked questions
Does NIS2 mention Kubernetes?
No. The directive and the national rules are technology-neutral. The requirements on configuration, access, logging and change management still apply to every system that delivers the service, and that includes the cluster.
Do we have to follow the CIS Kubernetes Benchmark?
Not explicitly. NIS2 asks for measures that take into account the state of the art and relevant standards. CIS is an established and easily measurable way to show that.
Must security updates be installed within 72 hours?
NIS2 itself sets no fixed deadline. Some national regulators, Sweden's among them, give a 72-hour start as general advice, which is a recommendation rather than a requirement. Check the rules in your member state.
How long should audit logs be kept?
The directive sets no fixed period. Decide on a retention period based on your risk analysis and the rules in your member state, and document the decision.
Can the supervisory authority scan our clusters?
For essential entities, Article 32 of NIS2 allows security scans based on objective, non-discriminatory, fair and transparent risk assessment criteria, where necessary in cooperation with the entity. National law sets out the details.
Want help making your Kubernetes platform ready for supervision?
We are a Kubernetes and DevSecOps team based in Malmö, Sweden, working with hardening, policies, DevSecOps and operations in regulated environments. We have experience from platform operations in the defence sector and from assignments for Danish public authorities.
We are happy to start with a gap analysis against NIS2 and, if you manufacture products, the CRA. You get a picture of where the platform stands today and a prioritised list of what needs doing. Contact us for a quote or a first technical conversation.
Read more:
- Compliance: NIS2 and the CRA
- Kubernetes
- SUSE Rancher
- DevOps and DevSecOps
- CRA SBOM requirements
- Contact us
Sources
All checked on 2 November 2026.
- Directive (EU) 2022/2555 (NIS2), in particular Articles 20, 21, 32 and 33. eur-lex.europa.eu
- Commission Implementing Regulation (EU) 2024/2690. eur-lex.europa.eu
- Kubernetes documentation: Pod Security Admission and Auditing. kubernetes.io
- Center for Internet Security, CIS Kubernetes Benchmark. cisecurity.org
