Complementary customer criteria in C5: turning customer obligations into a responsibility matrix

The information security of a cloud service never rests with the provider alone. C5:2026 has two terms for this that are easily confused. This page separates them, shows the way from the catalogue entries to the customer controls of your service and gives a completed responsibility matrix as an example. How the rest of the system description is structured is covered on C5 system description.

What are complementary customer criteria?

Complementary customer criteria are part of the catalogue: for selected C5 criteria, the supplementary information contains a separate section “Complementary Customer Criteria”. It describes in general terms which controls customers need in their own area of responsibility so that the criterion is met together with the provider’s controls. For many criteria it only shows a dash.

The catalogue itself states what these entries are for (section 2.1). They show “where potential cooperation obligations exist” and are expressly “not an exhaustive list that is generally valid for all cloud services”. They are meant to help three groups:

• the provider, when writing the system description, to find the criteria that typically assume customer controls,
• the auditor, to assess the information on these customer controls in the system description,
• the customer, to understand the information in the system description and set up its own controls.

How much cooperation depends on the service model is shown in the catalogue by an example: with infrastructure services, customers typically bring in the security updates for their operating system themselves, with software as a service this typically lies with the provider (section 2.1).

What are complementary customer controls (CUEC)?

Complementary customer controls, also called complementary user entity controls (CUEC), are the controls at the customer that your service assumes in the design of your own controls. They belong in the system description as item 7 of the minimum content (section 3.4.5.1, item 7). Unlike the catalogue entries, you write them for your service: specific, testable and in a form a customer can implement.

The auditor does not test the customer controls themselves at the customer. The procedures are limited to their fair presentation in the system description (section 3.4.4). In the audit report, the auditor then states that the applicable criteria can only be met if the customer controls are suitably designed and operating effectively (section 3.4.13, item 1.1). What this means for the value of the report is covered on C5 attestation.

How do you derive the CUEC for your service?

Go through all criteria in scope once, asking what your control assumes at the customer. The catalogue entries are the starting point; criteria without a catalogue entry can also need a customer control. Our recommended order:

1. Collect the catalogue entries. For every criterion in scope, note whether the catalogue lists complementary customer criteria. This is plain legwork and gives you the first column of the matrix.
2. Check against the service model. For each entry, decide whether the customer can do anything at all with your service. Networks, images or malware protection in the customer area are usually your responsibility or your platform provider’s with a pure SaaS application, not the customer’s. Record the decision with a one-sentence rationale.
3. Cross-read your own controls. Criteria without a catalogue entry can also need a customer control. An example: your withdrawal of access rights only works if the customer reports leavers or locks them out itself. If no CUEC states this assumption, it is missing from the description.
4. Word the CUEC. For each CUEC a number, the criterion it relates to and one sentence with the actor, the activity and the trigger or frequency. Your own words for your service, no copied catalogue text.
5. Align with contract and manual. Every CUEC has to appear in the service description, administration manual or onboarding. Customers cannot implement an obligation they do not know about.
6. Transfer into the system description. The numbered list is item 7. Refer to the relevant CUEC in the control descriptions so that auditors and customers can see the connection.

A warning that follows from the logic of the report: CUEC are not a place to shift gaps at the provider onto the customer. The catalogue means controls that you have assumed in the design of your controls. If you offload tasks there that the contract assigns to the provider, you create a contradiction between description and contract, and customers read the report precisely at this point.

Responsibility matrix: structure and completed example

The responsibility matrix is a table with one row per criterion where provider and customer work together. It records what the provider delivers, which CUEC the service assumes, who is responsible on each side, where the obligation is documented and how the customer learns about it. Item 7 of the system description and the customer documentation come out of it in one go.

Fictitious example, not a client. A provider runs a platform for video consultations and appointment management as SaaS for medical practices and medical care centres. The platform runs on an IaaS platform in a German region; the practices manage their users in their own tenant and can connect sign-in to their own identity directory. Extract from the matrix:

Criterion titles as in the English catalogue version 1.0.1; the “CUEC” column is our wording for the fictitious example. Three rows end without a CUEC, and that is intentional: the matrix also documents why a catalogue entry does not apply to the service. Auditors and customers can see that the catalogue entries were reviewed in full.

The blank matrix as a CSV and Excel file with all columns, including status and communication channel, is on the templates page.

How do customers implement the obligations?

For the customer, each CUEC is a task in its own control system. Our recommendation for providers: give customers a list with the report that answers three questions for each CUEC. Who is responsible at the customer? Which function of the service do they need for it, and where is it described? Which evidence shows the customer itself that the control is working, such as an access rights report, an export or a test notification to the contact address?

Customers with their own information security management take the CUEC into their control register. Smaller customers, such as medical practices, usually need a short checklist. Both come straight out of the matrix if the columns “Owner at the customer” and “Documented in” are maintained.

Relation to Section 393 SGB V

For providers in German healthcare, the catalogue part carries weight: Section 393(3) no. 3 SGB V requires that the “complementary customer criteria contained in the audit report of the attestation have been implemented”, and subsection 7 requires a “checklist of the complementary customer criteria” for the publication of attested systems (our translation of both). The law uses the name of the catalogue part, not the term CUEC; which details in the report are meant exactly is a legal question. A responsibility matrix that keeps both columns, the catalogue entries and the CUEC, covers both readings. The detailed assessment is on Section 393 SGB V; it is general information and has to be checked legally in each individual case.

Common gaps in customer obligations