Kubernetes NIS2 and ISO 27001: The Evidence a Cluster Can Provide

Which evidence does your cluster already provide? The WZ-IT cluster audit reviews configuration, versions, access, network policies and the restore path against the CIS Kubernetes Benchmark and BSI APP.4.4. The result is a report with prioritised measures, a configuration review without a penetration test. See the Kubernetes cluster audit

Customers, auditors and supervisory authorities rarely ask about the concept when it comes to Kubernetes. They ask for evidence: Who has administrator rights? When was the restore last tested? How long is access logged? This guide shows which technical evidence a Kubernetes operation can provide for Article 21 of the NIS2 Directive, for ISO 27001 Annex A and for the BSI module APP.4.4, and where that evidence lives in the cluster. As of October 2026.

The boundary up front: the cluster provides technical evidence. It provides no certification, replaces neither the risk analysis nor the management system, and is not legal advice. Whether a company falls under NIS2 is clarified by legal counsel.

Table of contents

• What NIS2, ISO 27001 and APP.4.4 require of the cluster
• The evidence matrix: requirement, evidence, location
• Four pieces of evidence a fresh cluster does not produce
• Additionally for critical facilities (KRITIS)
• What the cluster does not provide
• How often evidence is produced
• Status and methodology
• How WZ-IT works
• Further guides
• Sources

What NIS2, ISO 27001 and APP.4.4 require of the cluster

NIS2. Article 21 of Directive (EU) 2022/2555 requires appropriate and proportionate technical, operational and organisational measures. Paragraph 2 names ten areas (a to j), among them incident handling, business continuity such as backup management and disaster recovery, security in maintenance including vulnerability handling, access control policies and multi-factor authentication. Kubernetes does not appear in the text, the requirements are technology-neutral. In Germany they correspond to items 1 to 10 of section 30(2) BSIG, and paragraph 1 requires entities to document compliance. Anyone who has to document needs evidence that comes out of ongoing operations. For entity types such as cloud computing service providers, data centre service providers or managed service providers, Implementing Regulation (EU) 2024/2690 specifies the technical requirements (Article 21(5)).

ISO 27001. The standard describes an information security management system. Annex A of the 2022 edition contains 93 controls in four themes. The technological controls carry the numbers A.8.x. Most cluster evidence falls under them, access rights and incident handling additionally under A.5.x. The standard text is not freely available. The numbers in this article come from the ENISA mapping table.

BSI APP.4.4. The module APP.4.4 Kubernetes (2023 edition, German) has 21 requirements. Five are basic requirements (A1 to A5, MUST), seven are standard requirements (A6 to A12, SHOULD) and nine apply with elevated protection needs (A13 to A21). It is applied together with SYS.1.6 Containerisation.

The evidence matrix: requirement, evidence, location

The table assigns to each area the references, the evidence from the cluster and its location. It is a reading aid and not an official mapping. References: NIS2 = letter in Article 21(2), ISO = Annex A of the 2022 edition, APP = requirement in the module APP.4.4.

The reporting deadlines come from Article 23(4): early warning within 24 hours, notification within 72 hours, final report no later than one month after the notification. The examples of evidence follow the ENISA implementation guidance for Implementing Regulation 2024/2690, for example records of regular restore tests, patch histories with timestamp and responsible person, or configuration snapshots before and after changes.

Four pieces of evidence a fresh cluster does not produce

Some evidence arises on its own, such as the Git history of a GitOps repository. Four need deliberate setup or a recurring action.

1. The audit log. The API server only writes events if an audit policy is configured: without --audit-policy-file nothing is logged. The log answers what happened when, who triggered it, on which resource and from where. A policy that records all requests at metadata level is enough as a start:

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: Metadata

The log backend writes to a file (--audit-log-path, rotation via --audit-log-maxage, --audit-log-maxbackup and --audit-log-maxsize), the webhook backend sends to an external API. There is no fixed retention period. For the entity types it covers, the implementing regulation requires logs for a predefined period and protection against unauthorised access or changes, and the ENISA guidance names a defined period as evidence. The operator sets and justifies the period. In audit mode, violations of the Pod Security Standards end up as an annotation in the same log (Pod Security Admission).

2. The RBAC export with recertification. An export with a reference date, kept in Git or in the evidence repository, shows who holds administrative rights:

kubectl get clusterrolebindings,rolebindings -A -o yaml > rbac-$(date +%F).yaml
kubectl get clusterrolebindings -o custom-columns='NAME:.metadata.name,ROLE:.roleRef.name,SUBJECTS:.subjects[*].name' | grep cluster-admin

The export is only half the evidence. The other half is the documented review: who looked at the list when and what was revoked. Members of the group system:masters bypass all RBAC checks, and their access cannot be revoked by removing bindings (RBAC Good Practices). Admin access through this group therefore belongs in the review. APP.4.4.A3 additionally requires that administrative actions are not anonymous.

3. The restore record. A green backup job shows that something was written. A record shows that the cluster can be restored. The fields follow point 4.2 of the implementing regulation and the ENISA examples of evidence for it (recovery times, completeness including configuration data, tests and corrective measures):

• Date, responsible person, scope (namespace, volumes, database)
• Backup source with timestamp, which yields the actual data loss
• Restore target, never the production system
• Start, end and measured duration compared with the target
• Integrity check, for example row count or an application smoke test
• Deviations with corrective measure and deadline
• Approval, storage location, date of the next test

APP.4.4.A5 defines the scope of the backup: persistent volumes, configuration files of Kubernetes and the control plane, the cluster state including extensions, etcd, infrastructure applications and the data of the registries. Snapshots must not replace the backup. The etcd snapshot (etcdctl snapshot save) contains the entire cluster state and should be stored encrypted (Kubernetes documentation). The four backup layers are described in Kubernetes backup: the four layers.

4. The version and change history. Kubernetes maintains each minor version for roughly fourteen months, twelve in the standard period and two in maintenance mode (Patch Releases). As of 28 October 2026, 1.34 has been past its end of support since 27 October 2026, and 1.35 runs until 28 February 2027. Evidence shows which version the cluster ran, when it was upgraded and who approved the change. If the cluster configuration is in Git, the history is complete: the GitOps principle Versioned and Immutable demands exactly that, and APP.4.4.A8 asks for versioned and annotated configuration files. In addition there is an official CVE feed as JSON and RSS against which the version state can be compared.

A note on NetworkPolicies as evidence for network separation: they only take effect if the CNI enforces them. Without a network plugin that supports them they have no effect, and a pod without a policy is not isolated. Which CNI features additionally provide flow data as evidence is compared in Cilium vs. Calico.

Additionally for critical facilities (KRITIS)

For operators of critical facilities, section 31 applies in addition to section 30 BSIG: measures beyond the protection level of other particularly important entities can be proportionate, and for the relevant IT systems attack detection is mandatory, continuously and automatically collecting and evaluating parameters from ongoing operations. The audit log of a cluster is a data source for this detection, not the detection itself. Operators demonstrate implementation to the BSI under section 39 by security audits, reviews or certifications, first at a point in time set by the BSI (at the earliest three years after designation as an operator) and every three years thereafter. Which facilities count as critical is a question for legal counsel and the relevant ordinance. Technically this means for the cluster: the same evidence as in the matrix, attack detection with connected log sources, and evidence that can be presented for the audit in the three-year cycle.

What the cluster does not provide

Not coming from the cluster are the risk analysis and security concept (Article 21(2)(a)), training (point g), personnel security, the approval and oversight of the measures by management bodies under Article 20 and the decision who reports incidents. The cluster provides the technical evidence for these decisions, not the decisions.

The boundary of responsibility also shapes the evidence. With managed Kubernetes services, the control plane and etcd are with the provider. With self-operated clusters on Proxmox, bare metal or at a cloud provider, the etcd backup, the API server configuration including the audit policy and upgrades belong to operations. A certificate of the data centre or the provider applies to its scope and says nothing about RBAC, network policies or the restore of the cluster. Check the scope, the validity, the certification body, monthly evidence from ongoing operations and the sub-processors involved.

The cluster provides technical evidence; certification and legal assessment lie outside the technology. The evidence from operations comes from the agreed scope of service and does not replace the customer's management system.

How often evidence is produced

For most evidence the frameworks prescribe no fixed cycle. The table shows the WZ-IT recommendation, justified by criticality. The ENISA guidance gives two reference values: review configurations at least monthly (point 6.3.3) and check backups by criticality, as an example weekly for high and monthly for moderate or low criticality (point 4.2.6).

Anyone who pulls the exports by hand shortly before the audit only evidences the reference date. A scheduled job (CI pipeline or CronJob) with storage in the evidence repository evidences the whole period.

Status and methodology

• As of: 28 October 2026. Kubernetes documentation as published for version 1.37, support dates from the Patch Releases page.
• NIS2: Letters a to j according to the directive text (EUR-Lex), items 1 to 10 according to section 30(2) BSIG (gesetze-im-internet.de).
• ISO 27001: Numbers from the ENISA mapping table version 1.2 (September 2025). It assigns Annex A numbers to each requirement of Implementing Regulation (EU) 2024/2690. We assigned the numbers to the cluster areas. ENISA states that the mapping does not express equivalence of the frameworks. The implementation guidance formally addresses the entity types of the regulation and serves other entities as orientation.
• APP.4.4: Requirements and classification from the module, 2023 edition.
• Commands: Examples, to be checked before use on your own cluster.
• Not included: Legal interpretation, sector-specific rules and a comparison of SIEM products.

How WZ-IT works

1. Inventory in the cluster audit. The cluster audit reviews configuration, versions and upgrade path, access, network policies, secrets as well as backup and restore path against the CIS Kubernetes Benchmark and APP.4.4. It is a configuration review with a report and not a penetration test. It costs from €1,490 excl. VAT one-time and is credited against the first month of operations. As of October 2026.
2. Evidence in operations. In Kubernetes operations, upgrade, backup and restore evidence is produced within the agreed scope of service. Managed Kubernetes costs from €590 excl. VAT per cluster and month including three worker nodes. Monitoring runs 24/7, the response to P1 incidents follows the service level.
3. Boundary. WZ-IT provides technical evidence and does not provide legal advice. Whether and which NIS2 obligations apply to your company is clarified with your legal counsel; the BSI applicability check gives a first orientation.

The operational evidence beyond Kubernetes, such as patch, monitoring and incident reports, is described on the compliance page.

Further guides

• Kubernetes backup: the four layers: etcd, resources, volumes and consistent databases as well as the tested restore.
• Taking over a Kubernetes cluster: audit checklist: inventory and red flags for clusters you inherit.
• Cilium vs. Calico: CNI comparison with policies, flow data and encryption.
• Access Kubernetes privately with NetBird: cluster API without public exposure and with traceable access.
• Longhorn vs. Rook-Ceph: the storage layer beneath the volumes that get backed up.

To have a cluster reviewed for evidence or to set up operations with evidence: Kubernetes cluster audit by WZ-IT.

Sources

All sources retrieved on 28 October 2026.

• Directive (EU) 2022/2555 (NIS2), Articles 20, 21 and 23
• BSIG section 30, section 31 and section 39 (German)
• BSI: NIS-2-regulated companies and NIS-2 applicability check (German)
• BSI IT-Grundschutz Compendium: APP.4.4 Kubernetes, 2023 edition (German)
• BSI: Current developments in IT-Grundschutz (adaptation to ISO 27001:2022) (German)
• ENISA: Technical Implementation Guidance (version 1.0, June 2025) and Mapping Table (version 1.2)
• Kubernetes: Auditing, RBAC Good Practices, Network Policies, Pod Security Admission
• Kubernetes: Operating etcd clusters, Encrypting confidential data at rest
• Kubernetes: Patch Releases and Official CVE Feed
• OpenGitOps: GitOps Principles
• kube-bench and CIS Kubernetes Benchmark
• Velero