C5 domain OPS: setting up operations ready for audit

This page covers the OPS (Operations) domain of C5:2026, section 5.6 of the catalogue. How criteria and subcriteria are structured in general is explained on the page C5 criteria catalogue.

What is the OPS domain about?

OPS requires the ongoing operation of the service to be planned, monitored and secured in a verifiable way. With 35 criteria, 89 basic subcriteria, 9 sharpening and 28 complementing additional subcriteria, it is the most extensive domain. The criteria titles fall into eight sub-areas; the grouping is our reading aid:

Eleven OPS criteria are new in C5:2026 without a predecessor, among them patch management (OPS-27, OPS-28), third-party libraries (OPS-29), data separation as a policy (OPS-30) as well as confidential computing and containers. Several previous criteria have new numbers: OPS-19 to OPS-23 in C5:2020 became OPS-22 to OPS-26, and OPS-24 became OPS-31. You therefore have to update references in old control descriptions.

Starting point: a SaaS provider before its first audit

Fictitious example, not a client. A provider runs a portal through which medical practices place laboratory orders and receive findings. The service runs on the infrastructure of a large cloud provider in a managed Kubernetes cluster, with a managed database and object storage. Logs go to a SIEM service of a specialised service provider. The operations team consists of five people with weekly on-call duty.

Before the project, the situation looks like this:

• The database creates snapshots automatically; a restore was last carried out two years ago because of an error, not as a planned test.
• A vulnerability scanner checks the cluster nodes, but not the container images and the libraries used.
• The team handles critical findings quickly; there are no fixed time frames per severity.
• The SIEM collects logs; the rules have not been adjusted since its introduction.
• Usage data of the practices is analysed for product analytics; nobody knows exactly how much of this is covered by the contract.

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

In OPS, provider and platform share many tasks, and for several criteria the catalogue explicitly names obligations of the customers to contribute. Our classification for the example:

The platform and the SIEM service provider are subservice organisations. If you use the carve-out method for them, their controls are outside your audit, but responsibility for the criteria remains with you; monitoring runs through the SSO domain. How to choose the method is explained on the page C5 scope.

Example control description for OPS-25

OPS-25 requires that system components in the area of responsibility of the cloud service provider “are subject to vulnerability scans at least once a month”, including a comparison against up-to-date vulnerability databases such as CVE or EUVD (OPS-25.01B). The severity is assessed according to defined criteria, measures are initiated within defined time frames, and the results are used to update the SIEM rules (OPS-25.02B to 04B). The time frames themselves are set by the policy under OPS-18; there the catalogue requires, among other things, that for vulnerabilities assessed to be “high”, engagement begins within one working day (OPS-18.03B). Our example control (own wording, not catalogue text):

As an example of a risk-based framework with CVSS time frames, the supplementary information on OPS-25 gives around 24 to 48 hours for “critical” and one month for “low”; the complementing subcriterion OPS-25.01AC requires such a risk-based framework, the figures themselves are an example, not a requirement. The software component data can be, but does not have to be, obtained using an SBOM.

What evidence the auditor wants to see

OPS produces a lot of evidence on a fixed cycle. For a type 2 report, every cycle must be evidenced without gaps throughout the audit period. Examples from the scenario:

How to manage this evidence per subcriterion and due date is shown on the page Evidence and documentation.

Possible gaps: cause, effect, remedy

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

Which gaps actually block the audit and in which order you close them is clarified by prioritising measures across all domains.

All criteria of the OPS domain

Titles as in the English version 1.0.1, number of subcriteria counted per section 5 (B = basic, AS = sharpening, AC = complementing). The column “What it covers” is our own short description, not catalogue text; the wording of the criteria in the catalogue is binding.

Security incidents in the narrower sense are covered by the SIM domain; OPS-19 defines when an operational incident is escalated there.

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, not titles from the standard.