Containers and Kubernetes in C5:2026: implementing OPS-34 and OPS-35 for the audit

This page covers container operations as a focus topic of C5:2026. The OPS domain as a whole, including vulnerability scans and patch management, is covered on OPS domain. Which new focus topics the catalogue sets overall is explained on C5:2026.

What do containers mean under C5:2026?

The catalogue explicitly names container management as one of its new focus topics (section 1.1). At the core are two new basic criteria in the OPS domain: OPS-34 “Container Management - Policies and Procedures” and OPS-35 “Container Management - Implementation”. OPS-34.01B requires specifications for the entire container life cycle with at least five stages: creation, testing and validation of images, their storage and retrieval, deployment and management of containers, their operation, and decommissioning of images and containers. OPS-35 requires the provider to implement and maintain these specifications technically and organisationally.

OPS-34.02B lists nine aspects the policy has to address along the life cycle. Most refer to criteria in other domains, and OPS-34 bundles them for containers:

• inventory of containers according to a documented process (AM-02, AM-03, AM-09),
• assessing the need for malware protection (OPS-05),
• logging and monitoring along the life cycle (OPS-10, OPS-12),
• separation of customer data based on a risk assessment (OPS-30),
• access to the container host according to a roles and rights framework (IAM-01, IAM-06),
• encryption of stored and transmitted data, as far as possible (CRY-01),
• network security, such as detecting unexpected data flows (COS-01, COS-03),
• changes to containers and images following a regulated process (DEV-03),
• hardening according to industry standards so that no unnecessary services run (PSS-11).

For host access and encryption the catalogue says “should”, the other points are worded as firm requirements. Containers also appear elsewhere: IAM-06.08B requires activities of privileged users on containers and images to be logged according to OPS-10, and COS-05.02B separates the networks the provider uses to create and orchestrate workloads from the customers’ networks. The term Kubernetes does not appear in the catalogue. The criteria are technology-neutral and apply to any orchestration.

Starting point: an HR SaaS on managed Kubernetes

Fictitious example, not a client. A provider runs software for HR administration and payroll for mid-sized companies. The service consists of around 40 microservices in a managed Kubernetes cluster of a large cloud provider (hyperscaler), plus a managed database and a container registry from the same hyperscaler. Images are built in a build pipeline, and a GitOps tool deploys them to the cluster. The platform team has five people.

This is the situation before the project:

• Teams pull base images themselves from public registries, each team at its own version.
• The registry holds several thousand images, including some with no running container. Only the cluster itself shows which image runs in production.
• Two administrators have cluster admin rights via a static configuration file. Their commands on the cluster are not logged separately.
• For troubleshooting, developers occasionally open a shell in running production containers.
• There is no written rule on when an image is deleted.

Technically this is a common setup. For the audit, the policy under OPS-34 is missing, and without it the auditor can assess neither the suitability of the design nor, for type 2, the operating effectiveness over the period.

Who is responsible for what: provider, platform, customer?

With managed Kubernetes, the platform runs the cluster’s control plane and the provider runs everything it deploys on it. OPS-34 and OPS-35 are addressed to the provider, and the catalogue lists no complementary customer criteria for them. Our classification for the example:

If you use the carve-out method for the platform, its controls are outside your audit, but responsibility for the criteria stays with you (see C5 scope). If you let customers run their own containers, for example as PaaS, PSS-11 is added: customers must be able to restrict the selection of images, and images you provide need information on their origin and hardening according to industry standards. According to the supplementary information, PSS-11 is typically not applicable to SaaS. You justify this in the system description.

Example control description for image approval (OPS-34, OPS-35)

The first three stages of the life cycle can be combined in one control: no image goes into production unless it was built, checked and approved. Our example control for the provider above (own wording, not catalogue text):

Under the catalogue, signing is an additional criterion (complementing), OPS-34.01AC no. 1. For the basic criteria, another effective approval is enough. We still recommend signing, because the admission rule in the cluster enforces it technically and the evidence is then produced automatically. If you include it, you also have to store the signing key securely under CRY-10 (see CRY domain). The scans themselves belong to OPS-25. What a scan control looks like is shown on OPS domain.

What evidence the auditor wants to see

Container evidence is produced almost entirely by machines, in pipeline, registry and cluster. What matters is that you retain it over the whole audit period, since a cluster only shows its current state. Examples from the scenario:

Which evidence you keep for which subcriterion and when belongs in an evidence register. How to maintain one is shown on evidence and documentation.

Possible gaps: cause, effect, remedy

The following gaps follow from the wording of the criteria and the scenario. If a subcriterion is not met, the criterion counts as not met and the auditor reports the deviation (sections 3.4.12 and 3.4.13).

The order in which you close such gaps is a question of prioritising measures across all domains.

Criteria related to containers

Criterion titles as in the English catalogue version 1.0.1, subcriteria counted according to section 5 (B = basic, AS = additional (sharpening), AC = additional (complementing)). The selection outside OPS-34 and OPS-35 is our classification. The column “What it is about” is our own short description, not catalogue text. The wording of the criteria in the catalogue is binding.

How additional criteria such as OPS-34.01AC come into the audit scope is explained on C5 criteria catalogue. OPS-34 and OPS-35 are new in C5:2026 with no predecessor. There are no C5:2020 controls you could renumber for them.

Relationship to ISO/IEC 27001:2022 Annex A

The following mapping is our own, unofficial classification by topic. The BSI has not yet published a cross-reference for C5:2026. The catalogue refers to the BSI website for it (section 3.3). So far the table there covers C5:2020 only, and the BSI says the table for C5:2026 is “scheduled for publication in the near future” (as of 6 November 2026). According to the catalogue, even an official table only shows thematic proximity, not fulfilment of the criteria (section 3.3). The short labels are ours.