BSI C5 erklärt: Was Cloud- und SaaS-Anbieter nachweisen müssen

Definition

BSI C5 ist ein Kriterienkatalog des Bundesamts für Sicherheit in der Informationstechnik (BSI) für Cloud Computing, der prüfbare Sicherheits- und Compliance-Anforderungen an Cloud-Dienste definiert. Er ist keine Produktzertifizierung, sondern bewertet das dienstleistungsbezogene interne Kontrollsystem (IKS) eines Cloud-Anbieters anhand eines Prüfberichts.

Einleitung

Wenn Kunden „Cloud, BSI“ in einem Satz nennen, geht es meist um eine Frage: Kann ich dem Dienst sicher und auditfest vertrauen? BSI C5 hilft, diese Frage strukturiert zu beantworten – nicht mit Marketing, sondern mit Kontrollen, Nachweisen und einem unabhängigen Prüfer. Für SaaS-Anbieter bedeutet das: weniger Endlos-Fragebögen, mehr Standardisierung im Security-Review und schnellere Freigaben, wenn der C5-Nachweis sauber steht.

BSI C5 Typ 1 und Typ 2: der entscheidende Unterschied

Ein

C5-Testat

gibt es typischerweise in zwei Prüfarten.

C5 Typ 1

beurteilt, ob Kontrollen zum Stichtag angemessen gestaltet sind.

C5 Typ 2

prüft zusätzlich, ob diese Kontrollen über einen Zeitraum wirksam betrieben wurden (also „läuft es wirklich so?“).

Für die Praxis heißt das: Typ 1 ist oft der schnellere Einstieg, wenn du erstmal Prüf- und Vertriebsfähigkeit herstellen willst. Typ 2 ist meist überzeugender für größere Kunden, weil er Wirksamkeit belegt und damit Risiken im laufenden Betrieb adressiert (zum Beispiel Monitoring, Schwachstellenmanagement oder Identitäts- und Zugriffsmanagement).

IKS und Kontrollen: worauf Auditoren und Kunden wirklich schauen

BSI C5 ist am Ende ein Test der Beherrschbarkeit deines Cloud-Dienstes. Das IKS verbindet Richtlinien, Rollen, Verfahren, technische Maßnahmen und Nachweise zu einem prüfbaren System. Entscheidend ist, dass Kontrollen nicht nur existieren, sondern zu deinem Dienst passen und wiederholbar funktionieren.

• Kontrollmatrix

  : Welche Kontrolle erfüllt welches Kriterium – mit Owner, Frequenz und Evidence.

• Systembeschreibung

  : Was ist „der Dienst“ konkret (Scope, Datenflüsse, Abhängigkeiten, Unterauftragnehmer).

• Monitoring und Reaktion

  : Wie werden Events erkannt, bewertet und bearbeitet (Incident Response, Problem- und Change-Prozesse).

Basiskriterien vs. Zusatzkriterien: so liest man den C5-Katalog

Der C5-Kriterienkatalog unterscheidet

Basiskriterien

und

Zusatzkriterien

. Basiskriterien bilden das Fundament für die meisten Cloud-Dienste. Zusatzkriterien greifen, wenn dein Szenario zusätzliche Anforderungen auslöst (z. B. bestimmte Betriebsmodelle, Datenschutzanforderungen oder sektor-spezifische Erwartungen).

Der Nutzen dieser Trennung: Du kannst den Aufwand besser steuern. Statt „alles für alle“ baust du Kontrollen passend zum Scope – und machst gegenüber Kunden transparent, welche Anforderungen berücksichtigt wurden und welche bewusst nicht anwendbar sind.

C5 vs. ISO/IEC 27001 vs. SOC 2: wo die Standards sich unterscheiden

ISO/IEC 27001

ist ein Managementsystem-Standard für Informationssicherheit (ISMS) und hilft, Governance und kontinuierliche Verbesserung aufzusetzen.

SOC 2

ist ein Prüfrahmen (häufig nach ISAE 3000) mit Trust Services Criteria, stark verbreitet im internationalen SaaS-Umfeld.

BSI C5

ist cloud-dienstbezogen, auf deutsche Erwartungen zugeschnitten und fokussiert stark auf prüfbare Nachweise rund um Cloud-Betrieb und Servicebereitstellung.

Pragmatische Einordnung: ISO 27001 ist oft eine gute Grundlage fürs Management, SOC 2 kann bei US-/Global-Kunden Vertrauen schaffen. Für den deutschen Markt ersetzt das C5 aber nicht automatisch. Am besten wirkt ein Mapping: vorhandene Kontrollen wiederverwenden, Lücken gezielt schließen, statt doppelt zu dokumentieren.

Warum C5 für SaaS so wichtig ist: Shared Responsibility richtig scopen

Bei SaaS ist die größte Fehlerquelle nicht fehlende Technik, sondern ein unklarer Scope im Shared-Responsibility-Modell. Kunden wollen wissen, welche Sicherheitsanforderungen beim Anbieter liegen und was sie selbst konfigurieren müssen.

Wenn du das sauber dokumentierst, sinkt Reibung im Vertrieb: Security-Fragen werden zu klaren Antworten („wir stellen X bereit, ihr konfiguriert Y“). Außerdem wird Compliance messbar, weil Verantwortlichkeiten nicht zwischen Produkt, Betrieb und Kunde verschwimmen.

Aktuelle Versionen (z. B. C5:2026): was sich ändert

BSI veröffentlicht C5 in Versionen; mit

C5:2026

wurde der Katalog aktualisiert. Für dich ist weniger die Versionsnummer entscheidend als die Konsequenz: Kriterien, Evidence-Anforderungen und Erwartungshaltung entwickeln sich weiter, und deine Kontrolllandschaft muss mitziehen.

Best Practice: Plane Version-Updates wie ein Produkt-Release. Mit einer Gap-Analyse auf Kriterienebene (Katalog → Kontrollmatrix → Evidence) wird klar, was neu ist, was ersetzt wurde und welche Ressourcen du für die Aktualisierung brauchst.

Audit-Prozess und Prüfberichtsstruktur: so läuft es typischerweise

Geprüft wird durch einen

Wirtschaftsprüfer / unabhängigen Prüfer

. Am Ende steht ein Prüfbericht, der typischerweise aus Prüfbescheinigung, Systembeschreibung und den Ergebnissen je Kriterium besteht. Für Kunden ist genau diese Struktur wertvoll: Sie können nachvollziehen, was geprüft wurde, welche Kontrollen dahinterstehen und wo Einschränkungen liegen.

Der schnellste Weg zur Auditfähigkeit ist selten „mehr Tools“, sondern bessere Nachweise: einheitliche Logs, klare Ticket-/Change-Dokumentation, definierte Evidence-Owner und regelmäßige interne Kontrollen.

Praxis-Tipps für Cloud-Dienste: mit wenig Reibung zu prüfbaren Nachweisen

• Evidence automatisieren

  : Standardisiere Reports aus Monitoring, IAM-Reviews und Vulnerability-Scanning, damit Typ-2-Zeiträume nicht zur Suchaktion werden.

• Kontrollen produktnah schreiben

  : Formuliere Kontrollen so, dass Teams sie im Alltag erfüllen können (nicht als „Papierprozess“).

• Kunden-Readiness mitdenken

  : Dokumentiere Konfigurationspflichten und Secure Defaults, damit Kunden den Dienst sicher betreiben können.

Mini-Beispiel: warum C5 sich im Alltag „rechnet“

Ein SaaS-Anbieter hatte ein gutes ISMS, aber jede Kundenprüfung startete bei null: Fragebogen, Workshops, Nachreichungen. Nach dem Aufbau einer C5-fähigen Kontrollmatrix und eines konsistenten Evidence-Packages wurden Anfragen schneller beantwortbar, weil die relevanten Nachweise bereits strukturiert vorlagen. Ergebnis: weniger ad-hoc Arbeit im Engineering, mehr Planbarkeit im Vertrieb, klarere Verantwortlichkeiten im Betrieb.

Wann externe Unterstützung sinnvoll wird

Externe Unterstützung lohnt sich, wenn ein Audit-Termin nah ist, wenn Typ 2 angestrebt wird oder wenn interne Ressourcen für Dokumentation und Evidence fehlen. Ebenfalls sinnvoll: wenn du ISO 27001 oder SOC 2 hast und C5 als zielgerichtetes Mapping aufsetzen willst, statt parallel doppelte Kontrollen zu pflegen.