Die korrespondierenden Kriterien für Kunden: C5 endet nicht beim Cloudanbieter

„Der Anbieter hat doch C5. Dann ist die Sicherheit jetzt seine Aufgabe.“

Das klingt komfortabel. Es ist nur falsch.

Ein Cloud-Anbieter kann eine sehr ordentlich gesicherte Eingangstür liefern. Wenn der Kunde anschließend sämtliche Mitarbeiter zu Administratoren macht, Mehrfaktor-Authentisierung deaktiviert und Sicherheitsmeldungen in ein Postfach schicken lässt, das seit dem Ausscheiden von Herrn Meier niemand mehr liest, bleibt das Ergebnis unsicher.

C5 benennt deshalb für zahlreiche Kriterien ausdrücklich Aufgaben auf der Kundenseite. Anbieter und Kunde halten jeweils eine Hälfte des Schutzschildes. Lässt einer seine Hälfte fallen, ist das Schild nicht mehr vollständig – egal, wie glänzend die andere Hälfte geprüft wurde.

Die kurze Antwort

Korrespondierende Kontrollen der Cloud-Kunden sind Sicherheitsmaßnahmen, von deren Umsetzung der Cloud-Anbieter bei der Gestaltung seines eigenen Kontrollsystems ausgeht. Erst die Kontrollen des Anbieters und die passenden Kontrollen des Kunden zusammen können hinreichende Sicherheit dafür schaffen, dass die betreffenden C5-Kriterien erfüllt werden.

Der C5-Prüfer untersucht diese Kundenkontrollen im Auftrag des Anbieters nicht. Er beurteilt, ob die benötigten Kundenkontrollen in der Systembeschreibung sachgerecht dargestellt sind. Ob ein konkreter Kunde sie tatsächlich umgesetzt hat und wirksam betreibt, bleibt außerhalb dieses Prüfungsauftrags.

Für den Kunden folgt daraus eine ziemlich klare Arbeitsanweisung:

1. benötigte Kundenkontrollen aus Bericht und Dokumentation ermitteln,
2. auf den eigenen Einsatz des Dienstes übertragen,
3. Verantwortliche und technische Umsetzung festlegen,
4. Maßnahmen einrichten und nachweisen,
5. Änderungen des Dienstes und der Vorgaben weiterverfolgen.

Der aktuelle fachliche Ausgangspunkt ist der C5:2026-Kriterienkatalog des BSI.

Kriterien oder Kontrollen – wie heißt das Ding eigentlich?

Der C5:2026 verwendet in den einzelnen Kriterienbereichen die wiederkehrende Überschrift „Korrespondierende Kriterien für Kunden“. Im Begriffsapparat definiert er dagegen die korrespondierenden Kontrollen der Cloud-Kunden, auf Englisch Complementary User Entity Controls oder kurz CUEC.

Das ist kein Widerspruch, aber eine kleine sprachliche Stolperkante:

• Das C5-Kriterium beschreibt, welches Ergebnis erreicht werden soll.
• Die Kontrolle des Cloud-Anbieters ist eine konkrete Maßnahme, mit der der Anbieter dazu beiträgt.
• Die korrespondierende Kontrolle des Kunden ist die dazu passende Maßnahme auf Kundenseite.

Ein Beispiel: Der Anbieter stellt Mehrfaktor-Authentisierung technisch bereit und dokumentiert ihre sichere Verwendung. Der Kunde aktiviert sie, bindet sie in sein Identitätsmanagement ein und sorgt dafür, dass die richtigen Benutzer sie tatsächlich verwenden. Das gemeinsame Sicherheitsziel entsteht nicht durch das bloße Vorhandensein eines Schalters.

Wichtig ist außerdem: Die im Kriterienkatalog genannten Kundenbeiträge sind ausdrücklich keine abschließende und für jeden Cloud-Dienst gleichermaßen gültige Aufstellung. Servicemodell, Funktionsumfang, Systemgrenzen und konkrete Ausgestaltung des Dienstes entscheiden mit. Bei IaaS liegt regelmäßig mehr technische Verantwortung beim Kunden als bei einem vollständig betriebenen SaaS-Dienst.

Geteilte Verantwortung ist keine geteilte Unklarheit

Cloud-Sicherheit wird gern mit dem Shared Responsibility Model erklärt. Geteilte Verantwortung darf aber nicht bedeuten, dass beide Seiten freundlich auf die jeweils andere zeigen.

Der Anbieter soll ein nachvollziehbares Modell der geteilten Sicherheitsverantwortung pflegen. Darin werden Schnittstellen, Abhängigkeiten, Mitwirkungspflichten, Kommunikationswege und die Verteilung von Sicherheitsaufgaben beschrieben. C5:2026 verlangt außerdem, dass der Anbieter alle erforderlichen korrespondierenden Kundenkontrollen mit Erläuterungen in seiner Cloud-Nutzerdokumentation beschreibt.

Der Kunde muss daraus eigene, konkrete Arbeit machen. Ein Satz wie „Der Kunde ist für die sichere Konfiguration verantwortlich“ hilft nur begrenzt, wenn niemand geklärt hat:

• welche Konfigurationen gemeint sind,
• welche Einstellungen überhaupt angeboten werden,
• welches Sicherheitsniveau der Kunde erreichen will,
• wer die Einstellungen vornimmt,
• wie Änderungen und Abweichungen erkannt werden.

Das Thema gehört deshalb in das eigene Informationssicherheitsmanagementsystem nach ISO 27001. Der C5-Bericht ist eine Eingabe für Risikomanagement, Lieferantensteuerung, Berechtigungsmanagement, technische Konfiguration und laufende Überwachung – kein Ersatz dafür.

Was der C5-Prüfer nicht geprüft hat

Wenn korrespondierende Kundenkontrollen notwendig sind, soll im Prüfbericht deutlich werden, dass der Prüfer weder deren angemessene Ausgestaltung noch ihre Wirksamkeit beurteilt hat. Das Prüfungsurteil über das Kontrollsystem des Cloud-Anbieters erstreckt sich nicht plötzlich in die Mandanten und Büros sämtlicher Kunden.

Das ist keine Lücke im Prüfverfahren, sondern eine saubere Grenze. Der Anbieter kann nicht für jeden einzelnen Kunden prüfen lassen, ob dieser:

• ausgeschiedene Mitarbeiter rechtzeitig sperrt,
• Rollen nach seinem eigenen Schutzbedarf vergibt,
• angebotene Protokollierung aktiviert,
• Sicherheitsmeldungen liest,
• virtuelle Maschinen patcht,
• sichere Regionen und Konfigurationen auswählt.

Der Bericht kann daher sinngemäß aussagen: Die anwendbaren C5-Kriterien können nur erfüllt werden, wenn die beschriebenen Kundenkontrollen zusammen mit den Kontrollen des Anbieters angemessen ausgestaltet und wirksam durchgeführt werden.

Das ist der Punkt, an dem aus „Der Anbieter hat C5“ die wesentlich nützlichere Frage wird: „Welche Annahmen macht sein geprüftes Kontrollsystem über uns?“

Warum Dienst, Regionen, Systemgrenzen und Kundenkontrollen überhaupt zum Prüfungsumfang gehören, behandeln wir gesondert in Der C5-Scope: Was wird eigentlich testiert?. Dieser Artikel hier bleibt trotzdem vollständig verständlich: Es genügt zu wissen, dass der Bericht einen bestimmten Dienst beschreibt und daraus konkrete Pflichten auf beiden Seiten entstehen können.

Wo findet der Kunde seine Aufgaben?

Die Kundenkontrollen stehen nicht zwingend in einer einzigen hübschen Tabelle mit der Überschrift „Liebe Kunden, bitte hier entlang.“ Sie können über mehrere Dokumente verteilt sein:

C5-Bericht und Systembeschreibung

Die Systembeschreibung soll die korrespondierenden Kontrollen der Kunden und ihr Zusammenwirken mit den Kontrollen des Anbieters darstellen. Für die Auswertung ist deshalb nicht nur das Prüfungsurteil wichtig. Die Beschreibung des Dienstes und seiner Abhängigkeiten liefert den praktischen Zusammenhang.

Shared Responsibility Model

Das Modell der geteilten Verantwortung zeigt, wer welche Sicherheits- und Betriebsaufgaben übernimmt. Es sollte konkreter sein als eine bunte Grafik mit zwei Wolken und einem Pfeil dazwischen.

Cloud-Nutzerdokumentation

Nach C5:2026 soll der Anbieter dort alle erforderlichen Kundenkontrollen so erläutern, dass der Kunde sie in sein eigenes Risikomanagement übernehmen kann. Dazu gehören beispielsweise Anleitungen zur sicheren Konfiguration, zu Rollen, Authentisierung, Protokollierung und Schnittstellen.

Verträge und Leistungsbeschreibungen

Mitwirkungspflichten, Meldewege, Verantwortlichkeiten und Leistungsgrenzen können zusätzlich vertraglich beschrieben sein. Technische Dokumentation und Vertrag sollten sich dabei nicht gegenseitig Rätsel aufgeben.

Sicherheitsmeldungen und Änderungsinformationen

Neue Funktionen, Schwachstellen, geänderte Standardeinstellungen oder neue Regionen können den Kundenanteil verändern. Die einmalige Sichtung beim Einkauf reicht daher nicht. Unser Artikel zur laufenden Überwachung von Lieferanten zeigt, wie aus einer einmaligen Auswahl eine dauerhafte Steuerung wird.

MediSozial Cloud: ein frei erfundenes Praxisbeispiel

Damit die Kundenkontrollen nicht als abstrakte Wortwolke im Raum stehen, erfinden wir einen Dienst: MediSozial Cloud ist eine SaaS-Lösung für ambulante Pflegedienste und soziale Leistungserbringer. Sie verarbeitet Klienten- und Versichertendaten, Pflege- und Leistungsdokumentation, Diagnosen, Medikamentenpläne, Tourenplanung sowie Abrechnungsdaten – also je nach Einsatz Gesundheitsdaten und Sozialdaten.

Benutzer und ausgeschiedene Mitarbeiter

Der Anbieter stellt Benutzerverwaltung, Rollen und technische Sperrmöglichkeiten bereit. Der Pflegedienst muss aber wissen, wer dort arbeiten darf. Beginnt oder endet ein Arbeitsverhältnis, müssen Konten angelegt, angepasst oder gesperrt werden. Die Cloud kennt den letzten Arbeitstag nicht von allein.

Rollen und privilegierte Rechte

MediSozial Cloud bietet Rollen für Pflegekräfte, Einsatzplanung, Abrechnung und Administration. Der Kunde muss sie passend vergeben. Wenn aus Bequemlichkeit sämtliche Teamleiter Administratorrechte erhalten, ist das keine Schwäche des angebotenen Rollenmodells, sondern eine Kundenkontrolle, die auf dem Bauch liegt.

Mehrfaktor-Authentisierung und Sitzungen

Der Anbieter stellt MFA sowie konfigurierbare Sitzungsregeln bereit. Der Kunde bindet sie in seine Vorgaben ein, aktiviert sie und legt sinnvolle Sitzungszeiten fest. Besonders bei mobilen Geräten darf eine Anmeldung nicht bis zum nächsten Sommer offenbleiben.

Mobile Geräte

Pflegekräfte verwenden Smartphones unterwegs bei Klienten. Der Kunde muss diese Geräte absichern, Verlust behandeln, lokale Daten begrenzen und dafür sorgen, dass ausgeschiedene Mitarbeiter keinen Zugriff behalten. Die sichere SaaS-Plattform kann ein ungeschütztes Privattelefon nicht aus der Ferne in ein ordentlich verwaltetes Firmengerät verwandeln.

Protokollierung und Überwachung

MediSozial Cloud bietet Audit-Logs und Exportmöglichkeiten. Der Pflegedienst entscheidet, welche Ereignisse er benötigt, aktiviert die Funktionen, regelt die Aufbewahrung und wertet relevante Meldungen aus. Ein Log, das niemand anschaut, ist hauptsächlich sehr gewissenhaft gespeicherte Vergangenheit.

Schwachstellen- und Sicherheitsmeldungen

Der Anbieter informiert über bekannte Schwachstellen und notwendige Kundenmaßnahmen. Auf Kundenseite braucht es einen erreichbaren Empfänger, eine Bewertung und gegebenenfalls eine Behandlung im eigenen Risikomanagement. Das frühere Postfach von Herrn Meier ist kein Sicherheitsprozess.

Regionen und Datenverarbeitung

Wenn verschiedene Verarbeitungsregionen angeboten werden, muss der Kunde diejenige auswählen, die zu seinen Anforderungen passt. Bei besonders schützenswerten Gesundheits- und Sozialdaten gehört diese Entscheidung bewusst getroffen und dokumentiert. Ein Dropdown-Menü ersetzt keine Risikobeurteilung.

Vorfälle und Ansprechpartner

Anbieter und Kunde benötigen abgestimmte Melde- und Eskalationswege. Der Pflegedienst muss intern klären, wer Meldungen entgegennimmt, bewertet und weiterbearbeitet. Wie man Sicherheitsereignisse und tatsächliche Vorfälle auseinanderhält, erklären wir in Sicherheitsereignis oder Sicherheitsvorfall.

Aus dem Bericht wird eine Arbeitsliste

Die ermittelten Kundenkontrollen sollten nicht in einer PDF-Markierung enden. Eine einfache CUEC-Matrix reicht für den Anfang:

Die Spalte Auslöser ist absichtlich nicht überall ein Kalender. Manche Kontrollen werden bei einem Ereignis gebraucht, andere in geplanten Intervallen und wieder andere laufend. Ein pauschales „jährlich“ löst keine Verantwortung, sondern verschiebt häufig nur das Vergessen auf einen festen Termin.

Vom C5-Bericht ins eigene ISMS

Für Unternehmen mit geregelten Sicherheitsanforderungen in Lieferantenvereinbarungen lassen sich CUEC gut in vorhandene Prozesse einbauen:

1. Dienst als Abhängigkeit erfassen: Welche Prozesse und Informationen hängen davon ab?
2. Kundenkontrollen zuordnen: Welche Rolle, Richtlinie oder technische Maßnahme setzt sie um?
3. Lücken als Risiken behandeln: Was fehlt, wie groß ist das Risiko und wer akzeptiert es?
4. Nachweise festlegen: Woran erkennt man später, dass die Kontrolle durchgeführt wurde?
5. Änderungen überwachen: Welche Anbieterinformationen können eine erneute Bewertung auslösen?
6. Wirksamkeit prüfen: Funktioniert die Kontrolle praktisch oder steht sie nur in einer Tabelle?

Bei der Auswahl eines neuen Dienstes sollten solche Aufgaben bereits in die sichere Auswahl und Steuerung von Cloud-Diensten einfließen. Sonst wird zuerst gekauft und anschließend überrascht festgestellt, dass wichtige Sicherheitsfunktionen nur im teureren Tarif verfügbar sind.

Typische Fehler bei C5-Kundenkontrollen

• Nur die Titelseite lesen: Dort stehen die eigenen Aufgaben selten in brauchbarer Tiefe.
• CUEC für unverbindliche Empfehlungen halten: Sie können für das Zusammenwirken der Kontrollen notwendig sein.
• Die Katalogbeispiele blind kopieren: Die konkrete Systembeschreibung und Nutzerdokumentation des Dienstes sind entscheidend.
• Technik ohne Verantwortlichen einrichten: MFA, Logs und Rollen brauchen Eigentümer und laufende Pflege.
• Verantwortung vollständig an die IT schieben: Fachbereiche, Personal, Einkauf und Informationssicherheit können ebenfalls beteiligt sein.
• Nach der Einführung nicht mehr hinschauen: Funktionen, Regionen, Risiken und Anbieterinformationen ändern sich.
• Das Testat mit sicherer Nutzung verwechseln: Ein geprüfter Anbieter und ein schlecht konfigurierter Mandant ergeben gemeinsam keinen sicheren Dienst.

Ob ein Unternehmen im Gesundheitswesen einen C5-Nachweis benötigt, ist eine andere Frage als die sichere Nutzung. Dazu gibt es unseren gesonderten Artikel C5-Pflicht nach § 393 SGB V. Und wer zunächst verstehen möchte, was das Testat überhaupt über den Anbieter aussagt, findet die Einordnung unter C5 und ISO 27001 im Vergleich.

Interesse geweckt?

Sie möchten einen C5-Bericht aus Kundensicht auswerten, korrespondierende Kontrollen in eine praktische Arbeitsliste übersetzen und in Ihr ISMS übernehmen? Sprechen Sie mit uns.