C5 domain COS: segmenting networks and documenting data flows

This page covers the COS (Communication Security) domain of C5:2026, section 5.9 of the catalogue. How criteria and subcriteria are structured in general is explained on the page C5 criteria catalogue.

What is the COS domain about?

COS protects information in networks. The catalogue states the objective as ensuring the protection of information in networks and the corresponding information processing systems (section 5.9). The criteria require technical safeguards against network-based attacks at multiple tiers (COS-01), defined security requirements for connections (COS-02), security zones with monitored transitions (COS-03), security gateways at every network perimeter (COS-04), separate networks for administration (COS-05), separation of customer data traffic in jointly used networks (COS-06), up-to-date documentation of the network topology (COS-07) and policies for data transmission (COS-08).

The domain comprises eight criteria with 20 basic subcriteria, one sharpening and three complementing additional subcriteria. For a SaaS provider on a hyperscaler platform, COS mainly concerns the virtual networks it configures itself. Which encryption methods apply to transmission is governed by the CRY domain; how the data of the protective systems is evaluated in the SIEM, by the OPS domain.

Starting point: a flat network that has grown over time

Fictitious example, not a client. A provider runs a telemonitoring platform for heart patients. Measuring devices in patients’ homes send readings via small mobile gateways that the provider supplies; hospitals and cardiology practices see the readings in a web portal and receive alarms. The service runs as SaaS on the infrastructure of a large cloud provider, in a managed Kubernetes cluster with a managed database.

Before the project, the situation looks like this:

• All services sit in one virtual network with one subnet; the database can be reached from every pod.
• Administrators connect via SSH directly from the office network, allowed by its IP address.
• The security group rules have grown over the years. Nobody knows exactly any more what some open ports are needed for.
• The web application firewall protects the portal, but not the interface for the readings.
• The network diagram in the wiki shows the state of two years ago.
• The logs of the firewall and the web application firewall stay with the platform; the provider’s SIEM does not receive them.

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

The boundary runs between the platform’s physical network and the virtual networks the provider configures. Five of the eight criteria contain complementary customer criteria; they are aimed mainly at customers who are themselves responsible for parts of the service, for example virtual machines in an IaaS solution. Our classification for the example:

Whichever customer controls you assume belong in the system description as complementary customer controls (CUEC). If customers of a SaaS service do not operate virtual networks of their own, the complementary customer criteria for COS-01, COS-03, COS-04 and COS-06 may have nothing to apply to; the system description should then say so explicitly.

What does an auditable zone model look like?

COS-03.01B requires distinguishing between trusted and untrusted networks and separating them, based on a risk assessment, into security zones for internal and external network areas and a DMZ where applicable. COS-04.01B requires security gateways at every network perimeter, COS-05.01B separate networks for administration. The separation may be logical, for example via VLAN, SDN or VRF. Our zone model for the example:

Networks the provider uses to create, migrate or orchestrate compute workloads are separated from the customer networks under COS-05.02B. With a managed Kubernetes cluster the platform runs the control plane; the provider describes how it restricts access to it to the administration network. How to run such a container platform ready for audit as a whole is shown on the page Containers and Kubernetes. For the office network, COS-02.01B specifies that the security requirements also cover firewalls, secure Wi-Fi configurations and VPN for remote access.

How do you document data flows under COS-07?

COS-07.01B requires traceable and up-to-date documentation showing how the subnets are allocated, how the network is zoned and segmented, how it connects with third-party and public networks and how data flows between subnets and system components. COS-02.01B requires defining which communication relationships and protocols are permitted. Both can be combined in a data flow matrix, which is at the same time the basis for the gateway rule set. An excerpt for the example:

Under COS-07.02B the documentation also includes the partitions, regions, zones or location in which customer data is stored, and under COS-07.03B a representation of the systems derived from the network topology and the asset inventory. Every row of the matrix should correspond to a rule in the gateway and vice versa; only then does the review under COS-03 become manageable.

Example control description for COS-03

COS-03.03B requires reviewing the design and implementation of the connections against the security requirements at least annually and in case of significant changes to the service, COS-03.05B reviewing the business justification for all services, protocols and ports at specified intervals, including the justifications for compensatory measures for protocols considered insecure. Our example control for the provider above (own wording, not catalogue text):

The six-monthly frequency for ports and protocols is our recommendation; the catalogue requires “specified intervals”, which you set in your policy. For a type 2 report the auditor checks whether every defined run took place in the period.

What evidence the auditor wants to see

For COS, evidence comes from configuration exports, network documentation and review records. Examples from our scenario:

An evidence register maps each subcriterion to its evidence; how to keep one 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 above. 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).

All criteria of the COS 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.

The additional criteria: COS-01.01AC (no unknown devices in the network), COS-04.01AS (redundant, highly available security gateways), COS-05.01AC (encryption of administration traffic where separation is not physical) and COS-06.01AC (for IaaS and PaaS, physical separation or encryption combined with logical separation). Whether COS-06 applies to a SaaS service depends on whether customers share a network environment; according to the supplementary information, the separation of stored and processed data is the subject of OPS-30 and OPS-31 (tenant separation).

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. What you can reuse from a certified ISMS overall is covered on the page C5 and ISO 27001.