GEDANKEN & FACHLICHE EINORDNUNG
Blog
Impulse zu Governance, Informationssicherheit und KI.
C5 – der Cloud Computing Compliance Criteria Catalogue des BSI – hat eine erstaunliche Karriere hinter sich. Was als Antwort auf die notorische Intransparenz großer Plattformen begann, ist heute vielerorts Prüfstandard, Einkaufsfilter und Beruhigungspille in einem. Genau darin liegt die Gefahr: Wenn C5 nur noch als Etikett am Anbieterprofil hängt, verliert er seine Kraft. Dann wird aus der Idee einer belastbaren, nachvollziehbaren und anschlussfähigen Prüfung ein Alibi. Und Alibis sind bequem – bis der erste Vorfall Druck erzeugt und plötzlich alle wissen wollen, was, wann, warum geprüft wurde, wer wofür verantwortlich ist und welche Belege den Unterschied machen. Dieser Beitrag zeigt, wie C5 vom Stempel zur Steuerung wird: als operativer Prüfrahmen, der Architektur, Betrieb, Einkauf, Recht, Revision und Aufsicht zusammenbringt, statt sie in parallelen Diskussionen verharren zu lassen.
Die Frage „Audit oder Alibi?“ entscheidet sich an einer simplen Beobachtung: Entstehen Beweise nebenbei im Betrieb – oder werden sie nachträglich zusammengetragen, wenn ein Audit im Kalender steht? Ein Katalog allein beantwortet das nicht. C5 liefert die Sprache (Kontrollziele, Kontrollen, Feststellungen, Zeiträume), aber erst die Umsetzung schafft Substanz. Dort, wo Unternehmen C5 am Lebenszyklus ausrichten, verändert er das Arbeiten:
Der Unterschied ist fundamental: Wer C5 so versteht, verschiebt Energie vom „Sammeln für Auditor:innen“ zum „Steuern für den Betrieb“. Das macht schneller, ehrlicher und resilienter.
Dass C5 zum Lippenbekenntnis verkommt, erkennt man an wiederkehrenden Mustern. Dazu gehören One-Off-Dokumente (wordschöne Richtlinien ohne Durchgriff in Systeme), Checklisten-Orgien (viel Abhaken, wenig Wirkung), Inselprotokolle (Logs dort, wo niemand sie braucht), Random-Screenshots (Momentaufnahmen statt Ketten) und Zertifikate als Gesprächsverhinderer („Wir sind C5-auditiert, also ist alles gut“). Kritisches Gegenmittel ist die Frage: „Wo ist der Schalter?“ – also der technische Punkt, an dem eine C5-Anforderung automatisch greift. Gibt es ihn, ist C5 lebendig. Gibt es ihn nicht, ist C5 Rhetorik.
C5 ist stark, weil er Rollen sauber trennt: Was liegt beim Provider? Was beim Kunden? Zwischen diese Seiten gehört ein Arbeitsvertrag – nicht nur juristisch, sondern operativ. Er enthält:
So wird aus „gemeinsamer Verantwortung“ kein freundlicher Nebel, sondern eine arbeitsteilige Taktung. Wenn der Provider einen Sicherheits-Hinweis verschickt, ist klar, welche Pipeline blockt, welche Ausnahme greift, welches Team entscheidet, welche Kundeninformation wann rausgeht und welches Evidenzpaket ins Archiv fällt.
Ein echter Prüfrahmen lebt von wenigen harten Regeln mit großem Hebel. Drei Beispiele:
Solche Regeln sind Prüf- und Betriebsziele zugleich. Auditor:innen sehen die Wirkung; Teams spüren die Hilfe.
Wenn C5 zum Prüfrahmen wird, gibt es ein Evidenzfundament. Es ist systemnah, signiert, versioniert und adressierbar. Es sammelt:
Entscheidend ist die Wiederverwendbarkeit. Dieselben Daten bedienen Betrieb, Management-Reports, Audits und Aufsichtsanfragen. Keine separaten „Audit-Ordner“ mehr, keine toten Excel-Kopien; stattdessen Sichten aus einem System der Wahrheit.
C5 wird dort scharf, wo Prüfziele an Zeit gekoppelt sind. Vier Uhren verleihen Zähne:
Dazu Time to Proof: Zeit bis zur belastbaren Evidenz für Dritte. Diese Uhren gelten je kritischem Prozess, nicht global. Sie haben Schwellen und Konsequenzen: Reißt eine Uhr, löst ein Gate aus, folgt ein Drill, verschiebt sich Budget. So wird Governance steuerbar.
C5 entfaltet gerade in der Lieferkette Wirkung – sofern Drittparteien den Anschluss liefern. Gute Verträge sichern:
Das Ziel ist weniger „Harte Hand“ als gemeinsame Professionalität. In einem Vorfall verhindert Anschlussfähigkeit den bekannten Satz „Wir warten noch auf Informationen des Dienstleisters“ – den niemand mehr hören will.
Backups sind Prüfungsstolz und Praxishürde. C5 stellt Fragen nach Strategie, Medien, Prozessen; echte Prüfrahmen beantworten zusätzlich: Wie vermeiden wir Schattenrisiken? Konkret:
Damit wird aus „Wir sichern“ ein „Wir können wirklich wiederherstellen und nachweisen, was gelöscht wurde“.
Ein Indikator für Reife sind Sätze, die plötzlich normal klingen:
Das ist keine Rhetorik. Das ist Betrieb, der Prüfziele ernst nimmt. Auditor:innen sehen die Spuren; Kund:innen spüren die Professionalität; Teams erleben Tempo statt Blockade.
Überkomplexe Policy-Landschaften erzeugen Ermüdung. Ein echter C5-Prüfrahmen setzt auf Reduktion. Zehn wirksame Schalter schlagen hundert Seiten Richttext:
Diese Schalter sind auditfest, menschenlesbar und maschinenausführbar. Genau diese Kombination macht C5 praktisch.
Viele Häuser stehen nicht bei Null, aber mittendrin. Der Weg zu C5 als Prüfrahmen ist inkrementell:
So verschiebt sich C5 vom Prüfpunkt zur betriebsnahen Steuerung – ohne Big Bang, aber mit spürbaren Effekten nach wenigen Wochen.
DORA, NIS2, BAIT/VAIT/KAIT, MaRisk, DSGVO, branchenspezifische Leitfäden: Niemand will fünfmal dieselben Nachweise bauen. C5 ist hier die Steckdose. Seine Kontrolllogik lässt sich präzise mappen. Wiederherstellung? C5-DR-Kontrollen plus eigene Restore-Drills. Meldepflichten? C5-Incident-Prozesse plus eigene Eskalationszeiten und Kommunikationspakete. Datenlöschen? C5-Lifecycle plus Löschnachweise in der Kundenschicht und Backups. Die Kunst besteht darin, Sichten zu erzeugen, nicht Silos. Ein Evidence Layer, viele Empfänger.
Cloud ist längst nicht mehr nur Compute und Storage. Daten- und KI-Plattformen, Feature Stores, Vektor-Datenbanken, Prompt-Filter, Content-Firewalls – all das gehört in den C5-Blick. Echte Prüfrahmen setzen Messpunkte im KI-Lebenszyklus: Sourcing, Kurierung, Training, Evaluation, Shadow-Serving, Monitoring, Retraining, Drift- und Bias-Kontrollen. Sie verknüpfen diese Punkte mit Zweckbindung und Löschpfaden – auch in abgeleiteten Artefakten. So werden Datenschutz und Ethik integriert, nicht addiert.
Einen Prüfbericht anhand einer konkreten Kontrollfrage lesen. Suchen Sie die relevante Anforderung, das geprüfte Vorgehen und mögliche Ausnahmen. Die Schlussfolgerung für den eigenen Betrieb sollte aus diesen Angaben ableitbar sein und nicht allein aus dem Vorhandensein eines Berichts.
Das Werk betrachtet Drittparteienrisiken als Steuerungsaufgabe zwischen Einkauf, IT, Compliance und Management. Es verbindet Abhängigkeiten mit Transparenz, Kontrollmechanismen und dem Anspruch, externe Leistungen über ihren Lebenszyklus beherrschbar zu machen.
Von Dr. Markus Groß
Cloud-Nutzung ist Vertrauensarbeit. C5 macht diese Arbeit messbar. Nicht, weil sich alles in Kennzahlen pressen ließe, sondern weil Zeiten, Schalter und Spuren disziplinieren. Sie schieben Interpretationsspielraum zurück, ohne Beweglichkeit zu rauben. Sie schaffen einen Gesprächsraum, in dem man mit Kund:innen und Aufsichten ergebnisorientiert reden kann: „So sind wir gebaut, so sind die Grenzen, so ist die Zeit, so ist der Beweis.“ Das ist der Unterschied zwischen Audit und Alibi.
Am Ende ist es einfach. C5 wird zum Alibi, wenn er nachgereicht wird, wenn Regeln erzählt, aber nicht exekutiert werden, wenn Evidenz kuratiert, aber nicht generiert wird. C5 wird zum Prüfrahmen, wenn er vorn beginnt: bei Architektur, in Pipelines, in Verträgen, in Drills, in Uhrwerken. Dann wirkt er an den Übergängen, die sonst brüchig sind: zwischen Provider und Kunde, zwischen Dev und Ops, zwischen Recht und Produkt, zwischen Vorfall und Kommunikation. Und dann kippt auch das Gefühl im Haus: Audits sind keine Siege über Prüfer:innen, sondern Bestätigungen für Systeme, die ohnehin funktionieren.
Die entscheidende Gewohnheit lautet: „Zeit schlägt Status – und Beweis schlägt Behauptung.“ Wer diesen Satz in Cloud-Projekte schnitzt, braucht keine Schaukästen. Er hat Antworten – im Log, im Gate, im Drill, im Forensikpaket. Das ist C5, neu definiert: kein Anhängsel, sondern ein Prüfrahmen, der den Alltag besser macht.
| Hinweis: Teile dieses Beitrags könnten unter Einsatz von KI-gestützten Tools erstellt oder überarbeitet worden sein. Weitere Informationen finden Sie im Impressum/Disclaimer. | Marken- und Bildrechte: Dargestellte Logos und genannten Marken liegen ausschließlich bei den jeweiligen Rechteinhabern. Nutzung erfolgt ausschließlich zu illustrativen Zwecken. |
Deine Bewertung hilft bei der Einordnung der Inhalte.
Interessant für dein Netzwerk? Teile den Beitrag direkt.
When you subscribe to the blog, we will send you an e-mail when there are new updates on the site so you wouldn't miss them.
We use cookies on our website. Some of them are essential for the operation of the site, while others help us to improve this site and the user experience (tracking cookies). You can decide for yourself whether you want to allow cookies or not. Please note that if you reject them, you may not be able to use all the functionalities of the site.
Comments 34
Ein hilfreicher Einstieg in das Thema. Wie würdest du die Verantwortung zwischen Anbieter und nutzender Organisation klarer aufteilen?
Die Zuständigkeiten sollten je Leistung beschrieben werden. Besonders wichtig finde ich den Umgang mit Daten, Änderungen und möglichen Ausfällen.
Ich würde gern einen Punkt vertiefen: welcher Nachweis die tatsächliche Wirksamkeit belegt. Wie lässt sich das mit überschaubarem Aufwand überprüfen?
Entscheidend wäre für mich, nicht nur die Durchführung zu dokumentieren. Auch die Wirkung und eine mögliche Abweichung sollten später nachvollziehbar sein.
Ich würde außerdem festhalten, welche Annahmen hinter der Bewertung stehen. Ändern sie sich, sollte nicht einfach derselbe Status fortgeschrieben werden.
Der Pilot ist aus meiner Sicht sinnvoll, wenn er nicht nur die formale Durchführung prüft. Entscheidend ist, ob anschließend eine bessere oder schnellere Entscheidung möglich ist.
Das überzeugt mich. Ein konkreter Fall mit klarer Zuständigkeit und Nachprüfung dürfte mehr zeigen als ein umfangreiches Modell ohne praktische Rückkopplung.
Was wäre bei Exitfähigkeit und Datenportabilität ein nachvollziehbares Kriterium für den Abschluss einer Maßnahme?
Der Abschluss sollte an einem überprüfbaren Ergebnis hängen. Zusätzlich würde ich festhalten, welche Einschränkungen bleiben und wann die Wirkung erneut geprüft wird. Für Exitfähigkeit und Datenportabilität würde ich den ersten Prüfschritt bewusst klein halten.
Welche Abweichung würde euch bei Exitfähigkeit und Datenportabilität veranlassen, die Entscheidung erneut aufzumachen?
Wenn eine tragende Annahme nicht mehr stimmt, wäre für mich eine neue Bewertung nötig. Dafür sollten Annahme, Auswirkung und Entscheidung zusammen dokumentiert sein; sonst wird die Änderung leicht übersehen. Mit Blick auf Exitfähigkeit und Datenportabilität würde ich den Umfang der Prüfung bewusst auf diese Entscheidung begrenzen.
Wie verhindert man, dass private Cloudspeicher zur einfachsten Lösung für ein ungelöstes Unternehmensproblem werden? Ich würde das am konkreten Anwendungsfall dieses Artikels festmachen.
Das ist ein wichtiger Punkt. Eine zugelassene Alternative müsste mindestens die benötigten Arbeitsabläufe unterstützen. Sonst bleibt die eigentliche Ursache der Schattennutzung bestehen.
Damit bin ich noch nicht ganz zufrieden. Wie würde man prüfen, ob die vorgeschlagene Lösung im Alltag tatsächlich eingehalten wird?
Für mich müsste sich zunächst erklären lassen, welche Entscheidung verbessert werden soll. Daraus würde ich den notwendigen Umfang ableiten, statt mit der maximalen Dokumentation anzufangen. Das bezieht sich für mich auf den hier beschriebenen Ansatz.
Was bleibt in der eigenen Verantwortung, obwohl ein Dienstleister die Technik betreibt?
Das ist ein wichtiger Punkt. Für mich müssten Zuständigkeiten und Übergaben sichtbar sein. Ein vertraglich zugeordnetes Thema ist erst dann praktikabel, wenn auch der tatsächliche Ablauf dazu passt.
Einverstanden, mit einer Einschränkung: Wenn die notwendige Information fehlt, funktioniert die Abwägung nicht. Woher sollte sie kommen? Meine Ausgangsfrage bleibt: Was bleibt in der eigenen Verantwortung, obwohl ein Dienstleister die Technik betreibt?
Ein vorhandener Nachweis wäre für mich zunächst nur ein Hinweis. Seine Aussagekraft hängt davon ab, ob er wirklich den betrachteten Ablauf und Zeitraum abdeckt. Ich würde das am konkreten Anwendungsfall dieses Artikels festmachen.
Damit kann ich mehr anfangen. Die Grenze zwischen einem hilfreichen Nachweis und zusätzlichem Papier bleibt für mich der entscheidende Punkt. Die Ausgangsfrage „Was bleibt in der eigenen Verantwortung, obwohl ein Dienstleister die Technik betreibt?“ ist damit für mich noch nicht vollständig beantwortet.
Einverstanden, mit einer Einschränkung: Wenn die notwendige Information fehlt, funktioniert die Abwägung nicht. Woher sollte sie kommen?
Wie würde man einen Anbieterwechsel planen, ohne erst beim Ausstieg über Datenformate nachzudenken?
Für mich liegt der Schwerpunkt hier: Die Rückgabe der Daten und die Weiterarbeit nach dem Wechsel würde ich bereits bei der Auswahl prüfen. Ein theoretischer Exportknopf wäre mir als Nachweis zu wenig.
Dazu eine Rückfrage: Wie bleibt die Nachweissammlung aktuell, ohne ein zweites Parallelarchiv aufzubauen? Gerade bei dieser Fragestellung würde ich die Abwägung offen dokumentieren.
Ich würde möglichst an die vorhandenen Abläufe und Ablagen anknüpfen. Ein eigener Prüfungsordner sollte nicht die einzige Stelle sein, an der ein Sachverhalt nachvollziehbar ist.
Ich sehe den größten Nutzen in saubere Verantwortungsgrenzen in der Cloud. Das sollte sich mit wenigen verständlichen Signalen und konkreten Beispielen prüfen lassen.
Ein weiterer Punkt: Reicht ein Prüfbericht des Anbieters, wenn die eigene Nutzung ganz anders aussieht? Ich würde das am konkreten Anwendungsfall dieses Artikels festmachen.
Für mich liegt der Schwerpunkt hier: Ich würde den betrachteten Dienst und die Grenzen des Berichts abgleichen. Eine Aussage über den Anbieter ersetzt für mich keine Prüfung der eigenen Konfiguration.
Ich finde den Ansatz plausibel, aber noch sehr grundsätzlich. An welchem konkreten Entscheidungspunkt würde er einen Unterschied machen? Das bezieht sich für mich auf den hier beschriebenen Ansatz.
Bei fehlenden Informationen würde ich die Unsicherheit sichtbar machen und eine vorläufige Entscheidung mit klarer Wiedervorlage treffen. Einfach so zu tun, als wäre alles bekannt, wäre die schlechtere Grundlage. Das bezieht sich für mich auf den hier beschriebenen Ansatz.
Welche minimale Lösung wäre für Kontrolle von Konfiguration und Berechtigungen vertretbar, wenn ein kleines Team mehrere Rollen gleichzeitig übernimmt?
Ich würde die Rollen dennoch getrennt dokumentieren und für die kritische Entscheidung einen zweiten Blick vorsehen. Entscheidend wäre für mich, ob das Ergebnis für den konkreten Fall nachprüfbar bleibt. Bei Kontrolle von Konfiguration und Berechtigungen sollte die Prüfung aus meiner Sicht auf den im Beitrag beschriebenen Zusammenhang begrenzt werden.
Wie würdet ihr Verantwortungsteilung mit dem Anbieter konkret prüfen, wenn die verfügbaren Nachweise lückenhaft sind?
Mein Vorschlag wäre, die Lücke offen dokumentieren und einen überprüfbaren nächsten Schritt vereinbaren, statt Vollständigkeit zu unterstellen. Anschließend sollte klar sein, wer die Wirkung prüft und wann erneut entschieden wird. Bei Verantwortungsteilung mit dem Anbieter sollte die Prüfung aus meiner Sicht auf den im Beitrag beschriebenen Zusammenhang begrenzt werden.