ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
Complementary customer controls are the controls a cloud customer has to operate for the provider’s C5 criteria to be met — the part of cloud security that stays on the customer’s side of the shared-responsibility line — and C5:2026 makes them formal in two ways. The catalogue marks, criterion by criterion, where “complementary customer criteria” exist, because “maintaining the information security of a cloud service is not the sole responsibility of the cloud service provider”; and the provider’s system description lists the complementary user entity controls (CUEC) the customer must implement, so that the auditor can assess whether the information is appropriate and the customer can see where to act. In German healthcare the mechanism has legal force: § 393 SGB V permits cloud processing of health and social data only if, among other conditions, “the complementary criteria for customers contained in the attestation report are implemented”. This guide explains what the criteria are and where they come from, the three audiences the catalogue says they serve, the C5 areas where they cluster with examples, the customer’s four-step process for implementing and evidencing them, the provider’s obligations in writing them, and the equivalent concepts in SOC 2 and ISAE 3402 the catalogue borrows from.
| Term | Meaning | Where it appears |
|---|---|---|
| Complementary customer criteria | The catalogue’s marking, on selected criteria, of the cooperation obligations that typically fall to the customer; not exhaustive and not generally valid for every cloud service | In the criteria text, per criterion, as supplementary information |
| Complementary user entity controls (CUEC) | The controls the customer (user entity) must implement, together with the provider’s controls, for the criterion to be met — the assurance-standard term from ISAE 3402 and SOC reporting | In the provider’s system description and, for healthcare, the attestation report the customer relies on |
| Complementary subservice organisation controls (CSOC) | The controls a subservice organisation — a hyperscaler under a SaaS provider — must implement for the provider’s criteria to be met | In the system description where the carve-out method is used |
| Shared responsibility | The general principle the catalogue states with an example: for infrastructure services the customer typically patches its own operating systems; for software services the provider does | Catalogue section 2.1 |
BSI says the complementary customer criteria support three groups. They support providers in identifying the criteria that typically require CUEC to be set up alongside the provider’s controls. They support auditors in assessing whether the system description gives appropriate information about the CUEC. And they support customers in understanding the information provided about the CUEC and where to set up such controls. The practical consequence is that the same list is read three ways: the provider writes it, the auditor tests it for appropriateness, the customer implements it — and, since § 393 SGB V, a healthcare customer’s lawful processing depends on the last step. Our guide to who needs BSI C5 covers the legal setting.
| C5 area | Typical complementary customer control | Why it is the customer’s |
|---|---|---|
| IAM Identity and access management | Provisioning, review and removal of the customer’s own users and roles in the service; enforcing MFA on customer accounts; managing the customer’s privileged users | The provider cannot know who at the customer should have access |
| CRY Cryptography | Where customer-managed keys are used (CRY-19), generation, storage, rotation and revocation of the customer’s keys; choosing encryption options the service offers | The customer holds the key |
| OPS Operations | For IaaS and PaaS, patching and hardening of customer-managed operating systems and applications; configuring backup options; reviewing logs the service exposes | The catalogue’s own example: infrastructure customers patch their own OS |
| PSS Product safety and security | Applying the provider’s secure configuration guidance (PSS-01); acting on vulnerability information (PSS-03); configuring session and authentication options | The service is delivered configurable; the configuration is the customer’s |
| COS Communication security | Configuring network access, allow-lists and encryption for connections from the customer’s side | The customer’s network is the customer’s |
| SIM Security incident management | Receiving and acting on incident notifications; reporting incidents the customer detects; the customer’s own response for its side | Incident handling has two ends |
| PI Portability and interoperability | Requesting data provision at contract end; confirming secure deletion; managing interfaces the customer builds | Contract-end actions are initiated by the customer |
| BCM Business continuity | The customer’s own continuity plan for the service’s unavailability; testing failover on its side | The provider’s RTO is not the customer’s plan |
| INQ Investigation requests | Designating the contacts the provider informs; the customer’s own legal response | Notification needs a recipient |
The list differs by service model — a SaaS customer has fewer and lighter CUEC than an IaaS customer — and by provider; the only authoritative list for a given service is the one in that provider’s system description. Our guide to C5 criteria covers the areas the CUEC attach to.
Our guide to BSI C5 attestation covers the system description the CUEC live in.
| Framework | Term | Relationship to C5’s complementary customer controls |
|---|---|---|
| ISAE 3402 / SOC 1 | Complementary user entity controls (CUEC); complementary subservice organisation controls (CSOC) | The source of C5’s terminology; the catalogue applies ISAE 3402 and IDW PS 951 analogously |
| SOC 2 | Complementary user entity controls in the system description | Same mechanism; SOC 2 reports list CUEC per trust services criterion |
| ISO/IEC 27017 | Shared roles and responsibilities between cloud service provider and cloud service customer — a control in the 2015 edition, retained in substance in the restructured 2026 edition | The management-system view of the same line |
| Cloud provider shared-responsibility models | Provider-published matrices by service model | Informal; C5 and the assurance standards make the customer side auditable |
What are complementary customer controls in C5?
The controls a cloud customer must implement, alongside the provider’s, for a C5 criterion to be met — marked in the catalogue as complementary customer criteria and listed in the provider’s system description as complementary user entity controls (CUEC). They exist because, in BSI’s words, maintaining the information security of a cloud service is not the sole responsibility of the provider.
Are customers audited on them?
Not by the C5 auditor, who assesses whether the provider’s description of the CUEC is appropriate. Customers are held to them by their own obligations: § 393 SGB V for healthcare, which requires the complementary criteria in the report to be implemented; and their own ISO 27001, NIS2 or supervisory audits where the cloud service is in scope.
Where do I find the list for a specific service?
In the provider’s C5 report — the system description section — for the current period. The catalogue’s per-criterion markings are generic; the report is specific to the service and its model.
Do they differ between SaaS and IaaS?
Yes. The catalogue’s own example: infrastructure customers typically patch their own operating systems; software customers do not. IaaS and PaaS customers carry more CUEC — patching, hardening, backup configuration — while SaaS customers’ CUEC concentrate on identity, configuration and incident contacts.
What happens if a healthcare customer does not implement them?
Under § 393(3) SGB V the processing of health and social data in the cloud is permissible only if the complementary criteria in the attestation report are implemented, so the customer’s processing loses its legal basis under that provision regardless of the provider’s attestation.
Treat complementary customer controls as the customer’s half of every C5 criterion: written by the provider as real controls in the system description, tested by the auditor for appropriateness, and implemented, evidenced and reviewed annually by the customer — with the healthcare rule as the reminder that a criterion met only on the provider’s side is, for the customer, not met at all.
The complementary customer criteria statement template, the system description with CUEC and CSOC sections, the customer-side CUEC implementation register and the control documents for all 17 objectives are in the BSI C5:2026 Cloud Toolkit, or start with the free templates.
September 21, 2026
September 20, 2026
September 20, 2026
September 19, 2026
September 19, 2026