Kubernetes operations concept: outline and template per APP.4.4

Hand over cluster operations? WZ-IT operates Kubernetes on your infrastructure or hosted in Germany: updates, backup, monitoring and incident response, with a service level per cluster. Managed Kubernetes operations

A cluster runs as long as nothing unplanned happens. An operations concept decides in advance what happens during updates, outages, staff changes and audits. The BSI module APP.4.4 Kubernetes sets five baseline requirements that can be bundled into one concept. This guide provides the outline with minimum content per chapter, a RACI template, the six operating processes and the documentation duties. As of October 2026.

Contents

• What APP.4.4 requires and what an operations concept makes of it
• The five baseline requirements in the original wording
• The outline: eleven chapters with minimum content and pass criterion
• Roles and responsibilities: RACI template
• The six operating processes
• Documentation duties
• For elevated protection requirements
• Status and methodology
• Our approach at WZ-IT
• Further guides

What APP.4.4 requires and what an operations concept makes of it

The module APP.4.4 Kubernetes (2023 edition, German only) has 21 requirements. It must always be applied together with the module SYS.1.6 Containerisation and names IT operations as the role with primary responsibility. It does not prescribe a document called an operations concept. It requires planning (A1, A2), regulated permissions (A3) and a backup (A5). These contents belong in one concept, otherwise they remain in people's heads and in tickets.

Two documents have different jobs:

The concept refers to the matching section of the manual in each chapter. The manual belongs in version control like the configuration (A8 provides for versioned and annotated configuration files as a standard requirement).

The five baseline requirements in the original wording

The baseline requirements are the duties of the module worded with MUST. Titles and core statements follow the module. The module is published in German; the quotations are our translation.

A4 is not a planning task. The concept records which runtime and nodes the isolation relies on and refers to the proof of verification. The standard requirements A6 to A12 add to the chapters below, for example A7 (network separation with whitelisting), A9 (service accounts) and A11 (health checks).

The outline: eleven chapters with minimum content and pass criterion

The table is the template. Each row is a chapter with its minimum content, the requirements it rests on and a pass criterion that a third party can verify without asking back. References to other modules (CON.3, DER.2.1, OPS.1.1.3, OPS.1.1.5, SYS.1.6) are additions from the compendium, not parts of APP.4.4.

Chapters 7 and 4 provide the evidence that is easiest to verify: a restore record and an RBAC export. The article Kubernetes NIS2 and ISO 27001: evidence from the cluster shows the evidence for these. The pass criteria of the security layers are in the hardening checklist, those for operational readiness in the go-live checklist.

Roles and responsibilities: RACI template

APP.4.4 names IT operations as primarily responsible. The ISB ensures that the requirements are met and reviewed in line with the security concept and is involved in strategic decisions. Business owners come from CON.3 and OPS.1.1.3: they define the requirements of their applications for backup (CON.3.A1) and are primarily responsible for the patch and change management concept (OPS.1.1.3.A1). The table distributes these roles across operating tasks. It is a proposal by WZ-IT, not part of the BSI compendium. R = carries out, A = accountable (exactly one party per row), C = consulted, I = informed.

With a service provider, the provider carries out (R) the rows of IT operations. Which rows these are is stated in the contract and in chapter 3; as a proposal, protection requirements, approvals and business ownership remain with the client. How tasks are split between provider control plane, service provider and self-operation is shown in Managed Kubernetes vs. self-hosted.

The six operating processes

The concept describes each process with sequence, evidence and pass criterion. Detailed execution belongs in the operations manual.

Updates

1. New patch and minor versions are assessed promptly. OPS.1.1.3.A15 requires assessing and prioritising patches, deciding whether to apply them and, when a patch is not applied, documenting the reasons.
2. Version planning follows the support period: a minor version is maintained for roughly 14 months, twelve in the standard period and two in maintenance mode (Patch Releases). Minor versions are not skipped (kubeadm upgrade). The kubelet must not be newer than the kube-apiserver (Version Skew Policy).
3. For products without vendor support it must be checked whether they can still be operated securely; otherwise OPS.1.1.3.A15 prohibits their further use.

Evidence: version status per component, patch decisions, maintenance windows. Pass criterion: no component outside support. The schedule in detail is in the Kubernetes upgrade guide.

Backup and restore

1. The concept lists the six items from A5 and assigns a procedure, time and target to each.
2. Backups are stored on separate storage media (CON.3.A2), protected against unauthorised access and overwriting (CON.3.A14) and kept physically apart from the systems they protect (CON.3.A12).
3. The restore is tested regularly, above all whether data can be restored "flawlessly and in reasonable time" (CON.3.A15). The test cadence is a proposal of the concept, for example quarterly per critical application.

Evidence: backup logs, restore record with duration. Pass criterion: all six items are covered, and no restore is older than the defined cadence. The four layers are explained in Kubernetes backup; etcd snapshots are described in the Kubernetes documentation.

Monitoring

1. Every container defines health checks for startup and operation (A11). Based on the checks, Kubernetes is meant to delete or restart pods.
2. Alert rules, thresholds and responsible persons are in the concept. Logs are retained outside the containers, at least on the container host (SYS.1.6.A7).
3. For the API server, an audit policy defines which events are recorded and with which data. OPS.1.1.5.A1 requires a logging policy.

Pass criterion: a test alert reaches the named person within the agreed time.

Incident

1. The concept defines what a security incident is and how it is distinguished from day-to-day disruptions (DER.2.1.A1), and names responsible persons and contacts (DER.2.1.A3).
2. Affected parties are informed promptly, and reporting duties towards authorities and regulated sectors must be considered (DER.2.1.A4).
3. For recovery: data from backups may only be restored if it was not affected by the incident, and credentials of affected components are changed beforehand (DER.2.1.A6).

Pass criterion: one run-through is documented, the contact list is current.

Access

1. Every action on Kubernetes and the control plane is authenticated and authorised, including actions by automation (A3).
2. Pods do not use the default service account; each application has its own with minimal permissions (A9). Only selected administrators manage the CNI and create volumes (A7, A3).
3. The group system:masters bypasses all RBAC checks and cannot be revoked through bindings (RBAC good practices); the concept regulates who is a member.

Evidence: RBAC export with review note. Pass criterion: every far-reaching permission has a justification and an owner.

Changes

1. Changes to components, software and configuration data follow a concept: planned, approved, documented, with a fallback solution. For larger changes the ISB is involved (OPS.1.1.3.A1).
2. The cluster configuration is versioned and annotated in the management software, write permissions are minimal (A8). Pipelines work with the necessary permissions, with a separate process per user group (A10).
3. The intended security level is maintained during and after the change (OPS.1.1.3.A1).

Pass criterion: for every change in recent quarters there is a commit, an approval and a rollback path.

Documentation duties

The table summarises which documents the concept presupposes. The "Update" column is a proposal.

For elevated protection requirements

The requirements A13 to A21 are exemplary proposals whose adoption follows from a risk analysis. The concept lists them as an appendix with a decision per requirement: implemented, waived with reason, or not applicable. They include automated auditing against benchmarks (A13), dedicated nodes (A14), separate clusters for applications with very high protection requirements (A15), micro-segmentation (A18), high availability across several fire compartments (A19) and encrypted file systems including etcd (A20; for the API data in etcd see also encrypting data at rest).

Status and methodology

• As of: 29 October 2026.
• Sources of the requirements: APP.4.4 Kubernetes, 2023 edition, read in full; numbers, titles and quotations come from the original PDF. From CON.3, DER.2.1, OPS.1.1.3, OPS.1.1.5 and SYS.1.6 (each 2023 edition) only the requirements named are taken into account. Quotations are our translation of the German original.
• Our own additions: outline, pass criteria, RACI and cadences are proposals by WZ-IT. They are not a BSI requirement and not an official mapping.
• Kubernetes facts: documentation on kubernetes.io, retrieved on 29 October 2026.
• Not included: legal interpretation, NIS2 duties (see evidence from the cluster) and the requirements of other modules, unless named above.

Our approach at WZ-IT

1. Review the current state. The cluster audit compares the cluster with the CIS Kubernetes Benchmark and APP.4.4 and delivers a report with prioritised measures. It is a configuration review, not a penetration test. From EUR 1,490 net, one-off, creditable against the first month of operations.
2. Distribute tasks. Which rows of the RACI table WZ-IT takes over is set by the scope of services and the service level.
3. Operate. Managed Kubernetes operations takes over the operating processes: updates, backup, monitoring and incident response. Operations cost from EUR 590 per cluster and month including 3 worker nodes, net. Monitoring runs 24/7, the response to P1 incidents follows the service level (service levels).

Further guides

• Kubernetes hardening: checklist with pass criteria - security layers per CIS and APP.4.4
• Kubernetes go-live checklist - 25 checks as a self-test
• Kubernetes backup: the four layers - chapter 7 in detail
• Kubernetes NIS2 and ISO 27001: evidence - which evidence the cluster provides
• Managed Kubernetes vs. self-hosted - responsibility matrix per operating model
• Taking over a Kubernetes cluster: audit checklist - the current state before changing operators

Sources

• BSI IT-Grundschutz Compendium: APP.4.4 Kubernetes, 2023 edition, retrieved 29 October 2026
• BSI: CON.3 Datensicherungskonzept, 2023 edition, retrieved 29 October 2026
• BSI: DER.2.1 Behandlung von Sicherheitsvorfällen, 2023 edition, retrieved 29 October 2026
• BSI: OPS.1.1.3 Patch- und Änderungsmanagement, 2023 edition, retrieved 29 October 2026
• BSI: OPS.1.1.5 Protokollierung, 2023 edition, retrieved 29 October 2026
• BSI: SYS.1.6 Containerisierung, 2023 edition, retrieved 29 October 2026

Review the cluster or hand over operations? The audit delivers the report on the cluster configuration, managed Kubernetes implements the measures. Cluster audit · Managed Kubernetes operations