Tenant separation in C5:2026: implementing OPS-30, OPS-31 and COS-06 verifiably

This page covers the separation of customer data as a focus topic of C5:2026. The OPS domain as a whole is covered on the page OPS domain; which new focus areas the catalogue sets overall is shown on the page C5:2026.

What is tenant separation about in C5:2026?

The catalogue lists “More detailed consideration of multi-tenancy” as one of the main changes (section 1.1). In the criteria the topic is called “Separation of Datasets”; it means the separation of customer data between different customers and between customers and the provider. Three criteria form the core:

• OPS-30 Policies and procedures (new): Based on a risk assessment under OIS-07, the provider establishes policies that rest on a documented cloud layer model. They show which layers the service uses, which separation measures apply per layer, categorised by confidentiality, integrity and availability and as preventive, detective and reactive, how the measures are monitored and what happens in the event of deviations (OPS-30.01B).
• OPS-31 Implementation: The provider implements measures against threats to the separation, customer data on shared virtual and physical resources is “securely and strictly separated”, and the risk assessment is reviewed as needed, especially in case of architecture changes, and at least annually (OPS-31.01B to 03B). According to the change history, OPS-31 is the successor of OPS-24 from C5:2020.
• COS-06 Separation of data traffic: Customer data traffic in jointly used network environments is separated on network level according to a documented framework (COS-06.01B). For IaaS and PaaS the complementing COS-06.01AC requires physically separated networks or state-of-the-art encryption combined with logical separation. The rest of network security is covered by the COS domain.

Subcriteria in other domains add to this: IAM-07.01B requires partitioning measures that separate customers from each other and the service from the provider’s other systems, IAM-07.02B that a security incident at the components storing the data does not spread to the components managing access to them. OPS-15.01B requires logs that identify access unambiguously at the tenant level. COS-05.02B separates the orchestration networks from the customer networks, OPS-34.02B no. 4 the customer data in containers.

As an example of a layer model the catalogue names the CISA Cloud Security Technical Reference Architecture; the provider may, however, use its own categorisation (supplementary information on OPS-30). Not every combination of protection goal and type of measure has to be covered for every layer; where that is not meaningful, document it comprehensibly in the policy.

Starting point: document management for public authorities

Fictitious example, not a client. A provider runs document management as SaaS for local authorities. All authorities use the same application on the infrastructure of a large cloud provider: a shared Kubernetes cluster, a shared database with a column for the tenant ID, a shared object storage with one directory per tenant and a shared search index. Full-text search and a preview function run as separate services.

Before the project, the situation looks like this:

• Each developer sets the tenant ID in their own queries; there is no central enforcement.
• The search index contains documents of all tenants; filtering happens only at output.
• One shared data key in the platform’s key management applies to all tenants.
• The annual penetration test checks the application from outside, but not whether a user of one authority can see data of another.
• The logs of the preview function contain no tenant ID.

The separation probably works. In this form it cannot be evidenced: the layer model, the risk assessment and tests that would detect a breach of the separation are missing.

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

With SaaS, separation above the infrastructure lies with the provider. The platform separates its own customers from each other, that is the provider from other platform customers, not the provider’s tenants among themselves. For OPS-31 and COS-06 the catalogue lists complementary customer criteria. Our classification for the example:

Whichever of these customer controls you assume belong in the system description as complementary customer controls (CUEC). How to make the customers’ obligations manageable is shown on the page Complementary customer criteria.

Work product: separation matrix per cloud layer

OPS-30.01B requires measures per layer, categorised by protection goal and type of measure. The simplest form is a matrix that serves as policy and audit basis at the same time. An excerpt for the example (own categorisation of the layers, own measures):

C, I and A stand for confidentiality, integrity and availability (the asset register on the AM domain page additionally rates authenticity as a fourth protection goal). The diagram below this paragraph shows the same matrix as a printable overview; the table contains a few more details. The matrix does not replace the risk assessment under OIS-07; it shows which measure addresses which risk. According to the supplementary information on OPS-31, cryptographic separation does not have to exist on every resource if the risk assessment does not call for it there.

Example control description for OPS-31

A separation that is only claimed cannot be audited. The following control makes it measurable (own wording, not catalogue text):

The penetration test has a purpose of its own here: if the effectiveness of the separation cannot be assessed with reasonable assurance because of a complex implementation, the supplementary information on OPS-31 allows evidence to be provided through expert third-party reviews as well, for example penetration tests. The supplementary information on COS-06 says the same for network separation.

What evidence the auditor wants to see

For tenant separation the auditor needs two things: the reasoning why the measures are sufficient, and evidence that they were effective during the period. Examples from the scenario:

You evaluate the platform’s report through subservice organisation management (see subservice inventory). How to map evidence to the subcriteria 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 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 to close first is a question of prioritising measures.

Criteria on tenant separation

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

Access by your own staff to customer data under IAM-07.03B et seq. is covered on the page IAM domain.

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).