BSI C5 — ausgeschrieben Cloud Computing Compliance Criteria Catalogue — ist ein Kriterienkatalog des Bundesamts für Sicherheit in der Informationstechnik. Er beschreibt, welches Sicherheitsniveau ein Cloud-Dienst mindestens haben sollte, und er beschreibt es so konkret, dass ein Prüfer es beurteilen kann.
Gedacht ist er für zwei Gruppen. Anbieter von Infrastruktur-, Plattform- und Softwarediensten legen mit ihm offen, wie sie arbeiten. Kunden — vor allem Behörden, Banken und Versicherer — benutzen ihn, um Anbieter vergleichbar zu machen, ohne jeden einzeln auditieren zu müssen.
Der Punkt, an dem die meisten Missverständnisse beginnen: C5 führt zu keinem Zertifikat. Geprüft wird nicht durch eine akkreditierte Zertifizierungsstelle, sondern durch einen Wirtschaftsprüfer nach den Regeln für Prüfungen sonstiger Sachverhalte. Ergebnis ist ein Testat mit einem Prüfungsbericht, der ausdrücklich auch Ausnahmen und Einschränkungen benennen darf. Genau dort steht oft das Interessante.
Der Katalog ist zudem eine deutsche Setzung, keine internationale Norm. Im Inland ist er bei öffentlichen Aufträgen faktisch Standard. Außerhalb des deutschsprachigen Raums kennt ihn kaum jemand — dort wird nach ISO 27001 oder SOC 2 gefragt.
Was der Katalog verlangt
C5 ordnet seine Anforderungen in siebzehn Themenbereiche. Jeder Bereich enthält Basiskriterien, die für jeden geprüften Dienst gelten, und Zusatzkriterien für Dienste mit erhöhtem Schutzbedarf. Die Zusatzkriterien sind optional, werden aber in Ausschreibungen zunehmend mitgefordert.
| Kürzel | Bereich | Worum es im Kern geht |
|---|---|---|
| OIS | Organisation der Informationssicherheit | Verantwortlichkeiten, Risikosteuerung, Berichtswege |
| SP | Sicherheitsrichtlinien und Arbeitsanweisungen | Regelwerk, Freigabe, Bekanntgabe, Überprüfung |
| HR | Personal | Eignungsprüfung, Verpflichtung, Schulung, Austritt |
| AM | Asset Management | Inventar, Klassifizierung, Umgang mit Datenträgern |
| PS | Physische Sicherheit | Rechenzentrum, Zutritt, Stromversorgung, Brandschutz |
| OPS | Regelbetrieb | Kapazität, Protokollierung, Schadsoftware, Datensicherung |
| IDM | Identitäts- und Berechtigungsmanagement | Konten, Rechtevergabe, privilegierte Zugänge, Rezertifizierung |
| CRY | Kryptografie und Schlüsselmanagement | Verschlüsselung bei Übertragung und Speicherung, Schlüsselwechsel |
| COS | Kommunikationssicherheit | Netztrennung, Übergänge, Erkennung von Datenabfluss |
| PI | Portabilität und Interoperabilität | Datenexport, Schnittstellen, geordnete Beendigung |
| DEV | Beschaffung, Entwicklung und Änderung | sichere Entwicklung, Test, Freigabe von Änderungen |
| SSO | Steuerung von Dienstleistern und Lieferanten | Subunternehmer, Weitergabe von Anforderungen, Überwachung |
| SIM | Umgang mit Sicherheitsvorfällen | Erkennung, Meldung, Aufarbeitung, Information der Kunden |
| BCM | Kontinuität des Geschäftsbetriebs | Wiederanlauf, Redundanz, Übungen |
| COM | Compliance | interne Prüfung, rechtliche Anforderungen, Nachweisführung |
| INQ | Ermittlungsanfragen staatlicher Stellen | Prüfung, Eskalation, Umgang mit Auskunftsersuchen |
| PSS | Produktsicherheit und -verfügbarkeit | Härtung des Dienstes selbst, Fehlerbehandlung, Schwachstellen |
Dazu kommen Angaben, die der Anbieter offenlegen muss, ohne dass sie im engeren Sinn geprüfte Maßnahmen wären: in welchem Rechtsraum die Daten liegen, welcher Gerichtsstand gilt, welche Subunternehmer beteiligt sind, welche weiteren Nachweise vorliegen. Für Kunden sind diese Rahmenangaben oft entscheidungsrelevanter als einzelne Kriterien.
Der Unterschied zu einer Normanforderung liegt im Detailgrad. Wo eine Managementsystemnorm verlangt, Zugriffsrechte zu regeln, benennt C5, dass privilegierte Zugänge gesondert zu behandeln, regelmäßig zu überprüfen und protokolliert nachzuvollziehen sind. Das macht die Erfüllung überprüfbar und nimmt der Organisation zugleich Auslegungsspielraum. Wer aus einem Managementsystem kommt, empfindet den Katalog deshalb zunächst als eng.
Zwei Bereiche sind der eigentliche Unterschied zu allgemeinen Sicherheitsnormen. INQ verlangt einen definierten Umgang mit behördlichen Auskunftsersuchen — die Frage, wer unter welchen Umständen Zugriff auf Kundendaten erhält, wird damit zur prüfbaren Anforderung. PI verlangt, dass Kunden ihre Daten in verwendbarer Form zurückbekommen. Beides adressiert die Abhängigkeit, die durch Auslagerung entsteht, nicht nur die technische Sicherheit.
Für wen sich C5 lohnt — und für wen nicht
C5 lohnt sich, wenn Ihre Kunden danach fragen. Das klingt banal, ist aber die ehrlichste Antwort: Der Katalog hat keinen nennenswerten Eigennutzen jenseits des Nachweises, weil er nichts verlangt, was ein ordentlich geführtes Informationssicherheits-Managementsystem nicht ohnehin abdecken würde.
Danach gefragt wird typischerweise bei Aufträgen der öffentlichen Hand, im Finanzsektor, bei Kunden aus dem Gesundheitswesen und bei Betreibern kritischer Infrastrukturen, die ihre Dienstleister nachweisen müssen. In diesen Ausschreibungen ist das Testat oft Zulassungsvoraussetzung und nicht Bewertungskriterium — ohne es kommt Ihr Angebot nicht in die Wertung.
Gegen ein C5-Projekt sprechen drei Konstellationen:
Der Dienst ist zu jung. Ein Typ-2-Testat setzt voraus, dass Sie Nachweise über einen zusammenhängenden Zeitraum vorlegen können. Wer den Dienst seit vier Monaten betreibt, kann keinen Zwölfmonatszeitraum prüfen lassen.
Der Markt liegt im Ausland. Ein Testat, das Ihr Gegenüber nicht kennt, hilft im Vertrieb nicht. Dort wirken ISO 27001 und SOC 2.
Der Dienst ist keine Cloud im Sinne des Katalogs. Für klassisches Hosting ohne Mandantentrennung und Selbstbedienung passen viele Kriterien nur mühsam. Das führt zu einem Testat mit vielen Einschränkungen, das mehr Fragen aufwirft als beantwortet.
Für Kunden gilt die Frage in umgekehrter Richtung. Ein C5-Testat einzufordern ist sinnvoll, wenn Sie den Dienst für Daten mit erhöhtem Schutzbedarf nutzen oder wenn Sie selbst nachweispflichtig sind. Bei einem Werkzeug ohne personenbezogene oder geschäftskritische Daten treiben Sie damit die Kosten Ihres Lieferanten in die Höhe, ohne Ihr eigenes Risiko messbar zu senken. Die verhältnismäßige Anforderung ergibt sich aus der Schutzbedarfsfeststellung, nicht aus dem Beschaffungsformular.
Der Weg zum Testat
Der Ablauf einer Zertifizierung mit Stufe-1- und Stufe-2-Audit gilt hier nicht. C5 folgt der Logik einer Wirtschaftsprüfung, und die unterscheidet sich in vier Punkten.
Sie beauftragen einen Wirtschaftsprüfer, keine Zertifizierungsstelle. Die Auswahl ist damit eine andere: Erfahrung mit Cloud-Prüfungen und mit Ihrem Technologiestack zählt mehr als das Akkreditierungszeichen.
Sie schreiben die Systembeschreibung selbst. Sie legt fest, was geprüft wird — welcher Dienst, welche Regionen, welche Schnittstellen, welche Maßnahmen. Der Geltungsbereich entsteht hier, nicht im Prüfungsvertrag.
Der Prüfzeitraum will geplant sein. Beim Typ 2 muss jede Maßnahme über den gesamten Zeitraum nachweisbar gelaufen sein. Eine Berechtigungsrezertifizierung, die im Prüfzeitraum einmal ausgefallen ist, wird zur Ausnahme im Bericht. Deshalb beginnen die meisten Anbieter mit einer internen Bestandsaufnahme, schließen Lücken, und starten den Prüfzeitraum erst danach.
Der Prüfer sammelt Belege, keine Zusagen. Anders als im Zertifizierungsaudit wird nicht nur befragt und stichprobenartig eingesehen, sondern Kontrollnachweis für Kontrollnachweis abgearbeitet: Tickets, Freigaben, Protokollauswertungen, Berechtigungslisten, Änderungsdatensätze. Der Aufwand auf Ihrer Seite liegt deshalb weniger im Audittermin als in der Bereitstellung der Nachweise über Wochen.
Es gibt kein Überwachungsaudit und keinen Dreijahreszyklus. Stattdessen wiederholen Sie die Prüfung, in der Regel jährlich und lückenlos anschließend. Für die Wirksamkeitsprüfung der eigenen Maßnahmen heißt das: Sie brauchen laufende Nachweise, nicht eine Aufräumaktion vor dem Audittermin.
Woran C5-Projekte scheitern
Die Systembeschreibung ist Marketing. Sie beschreibt den Zielzustand, nicht den Betrieb. Der Prüfer testet gegen die Beschreibung — und findet Abweichungen, die es ohne die geschönte Formulierung nicht gäbe.
Subunternehmer sind ungeklärt. Wer auf einer fremden Infrastruktur aufsetzt, muss entscheiden: Wird der Vorlieferant in die Prüfung einbezogen oder ausgeklammert? Beim Ausklammern muss der Kunde dessen Nachweise zusätzlich einholen. Das steht dann im Bericht und wird regelmäßig überlesen — bis es in der Lieferantenprüfung auffällt.
Nachweise existieren, aber nicht über den ganzen Zeitraum. Protokolle werden erzeugt, aber die Auswertung ist nur für die letzten Wochen belegbar. Zugriffsrechte werden geprüft, aber die Prüfung des zweiten Quartals fehlt. Der Typ 2 verzeiht das nicht.
Die Aufgaben des Kunden sind nicht benannt. Der Anbieter erklärt, was er tut, aber nicht, was der Kunde tun muss. Das Testat wirkt dadurch umfassender, als es ist, und schafft ein Haftungsrisiko in beide Richtungen.
Das Testat wird nicht gelesen. Auf Kundenseite der häufigste Fehler: Man prüft, ob ein Testat vorliegt, nicht, was darin steht. Ein Bericht mit sechs Ausnahmen und ein Bericht ohne Ausnahmen sehen im Lieferantenverzeichnis identisch aus.
Die Prüfung wird als IT-Projekt geführt. Personal, Vertragswesen, Beschaffung und Recht liefern einen erheblichen Teil der Kriterien. Eignungsprüfungen bei Einstellungen, Verpflichtungserklärungen, Regelungen zu Auskunftsersuchen, Verträge mit Subunternehmern: Wenn nur die IT eingebunden ist, fehlen diese Nachweise am Ende, und zwar geschlossen in ganzen Kriterienbereichen.
Änderungen im Prüfzeitraum werden nicht mitgeführt. Ein Rechenzentrumswechsel, eine Migration, ein neuer Subunternehmer: Solche Ereignisse verändern die Systembeschreibung mitten im Zeitraum. Wer sie erst beim Abschlussgespräch erwähnt, verhandelt am Ende über eine Einschränkung, die bei rechtzeitiger Abstimmung vermeidbar gewesen wäre.
Abgrenzung zu verwandten Nachweisen
| Nachweis | Prüfungsgegenstand | Ergebnis | Wer prüft |
|---|---|---|---|
| BSI C5 | Ausgestaltung und Wirksamkeit definierter Cloud-Kriterien | Testat Typ 1 oder Typ 2, bezogen auf einen Zeitraum | Wirtschaftsprüfer |
| ISO/IEC 27001 | Managementsystem für Informationssicherheit | Zertifikat, drei Jahre mit Überwachungsaudits | akkreditierte Zertifizierungsstelle |
| ISO/IEC 27002 | Maßnahmenkatalog, aus dem sich Anhang A speist | kein eigenes Zertifikat | entfällt |
| ISO/IEC 27017 | cloudspezifische Ergänzung der Maßnahmen | Erweiterung des Geltungsbereichs der 27001-Zertifizierung | Zertifizierungsstelle |
| SOC 2 | Kriterien des US-Berufsstands, Typ I und Typ II | Prüfungsbericht, international verbreitet | Wirtschaftsprüfer |
| ISO/IEC 22301 | Fortführung des Geschäftsbetriebs nach Störungen | Zertifikat | Zertifizierungsstelle |
Die praktische Konsequenz: C5 und ISO 27001 konkurrieren nicht, sie ergänzen sich. Das ISMS liefert die Struktur — Risikobehandlung, Statement of Applicability, interne Audits, Managementbewertung. C5 prüft, ob die daraus abgeleiteten Maßnahmen im Cloud-Betrieb tatsächlich gelaufen sind. Anbieter, die zuerst das ISMS aufbauen und danach das Testat angehen, kommen erfahrungsgemäß mit deutlich weniger Reibung durch die Prüfung als umgekehrt.
Eine Einschränkung zum Schluss: Der Katalog wird fortgeschrieben. Welche Fassung Ihre Prüfung zugrunde legt und ob ein Auftraggeber eine bestimmte Ausgabe verlangt, sollten Sie vor Projektstart klären — die Kriterienzahl und einzelne Anforderungen unterscheiden sich zwischen den Fassungen.
