Stand: 2026-11-01
Ein Typ-2-Bericht beurteilt die Kontrollen über einen Zeitraum. Was in diesem Zeitraum anders lief als geplant, gehört deshalb in die Systembeschreibung. Diese Seite behandelt nur diesen Teil; die übrigen Mindestinhalte erklärt die Seite C5-Systembeschreibung; den Unterschied der Berichtstypen erklärt die Seite Typ 1 oder Typ 2.
Was verlangt der Katalog für Typ 2 zusätzlich?
Drei Inhalte, die zu den acht Mindestinhalten hinzukommen (Abschnitt 3.4.5.1). Die Spalte „Katalog“ zitiert die deutsche Fassung 1.1.0 auszugsweise; die rechte Spalte ist unsere Empfehlung.
| Inhalt | Katalog (K-DE 1.1.0, 3.4.5.1) | Was praktisch hineingehört |
|---|---|---|
| Wesentliche Änderungen | „Angaben zu wesentlichen Änderungen des für die C5-Kriterien relevanten internen Kontrollsystems des Cloud-Anbieters, die während des festgelegten Zeitraums implementiert wurden“ | je Änderung: was sich geändert hat, ab wann, welche Kriterien betroffen sind, wie die Kontrolle davor und danach aussah |
| Wesentliche Ereignisse | Ereignisse und Bedingungen, die Ausnahmen vom Normalbetrieb darstellen und im Zeitraum dazu geführt haben, dass vertragliche Vereinbarungen zur Verfügbarkeit nicht erfüllt wurden, „unbefugte Dritte Zugang zu Daten von Cloud-Kunden erhalten haben“ oder die Integrität der Kundendaten beeinträchtigt wurde oder Schutzmaßnahmen nicht wirksam waren | je Ereignis: Art, Zeitraum, Auswirkung auf Kunden, Ursache auf Ebene der Kontrolle |
| Gegenmaßnahmen | „die vom Cloud-Anbieter eingeleiteten Maßnahmen, um solche Ereignisse und Bedingungen künftig zu verhindern“ | je Ereignis: Maßnahme, Stand, verantwortliche Stelle |
Für alle drei gilt die allgemeine Regel der Systembeschreibung: Sie darf keine Informationen auslassen oder verfälschen, die für die Erfüllung der anwendbaren Kriterien relevant sind (Abschnitt 3.4.5.1 Nr. 2). Ein Zeitraum ohne wesentliche Änderungen oder Ereignisse ist möglich; unsere Empfehlung ist, das dann ausdrücklich in die Beschreibung zu schreiben.
Wann ist eine Änderung wesentlich?
Der Katalog definiert „wesentlich“ für Änderungen nicht allgemein. Er legt nur einen Fall fest: Anpassungen des Kontrollsystems an C5:2026 gelten als wesentliche Änderungen und gehören in die Systembeschreibung (Abschnitt 3.5). Für alles andere empfehlen wir eine einfache Prüffrage: Ändert sich etwas an dem, was die Systembeschreibung über eine Kontrolle oder das System sagt?
| Typischerweise wesentlich (unsere Einordnung) | Typischerweise nicht wesentlich |
|---|---|
| eine Kontrolle läuft anders: neue Häufigkeit, neue Verantwortliche, neues Werkzeug, etwa ein Wechsel des Identitätsverzeichnisses | ein Release, das über das beschriebene Änderungsverfahren lief; das ist die Kontrolle in Betrieb |
| eine Kontrolle kommt hinzu oder fällt weg | Korrekturen am Wortlaut von Richtlinien ohne Folgen für die Durchführung |
| Systemkomponenten im Umfang kommen hinzu oder fallen weg, etwa eine neue Region oder ein neues Modul | Skalierung im beschriebenen Rahmen, etwa zusätzliche Instanzen desselben Typs |
| ein Subdienstleister (Subservice-Organisation) wird gewechselt oder die Methode Carve-out oder Inclusive ändert sich | Wechsel eines Dienstleisters, der kein Subdienstleister im Sinne von Abschnitt 3.4.6 ist |
| Zuständigkeiten in der Organisation ändern sich, etwa ein neuer Verantwortlicher für die Informationssicherheit | Personalwechsel innerhalb einer Rolle, deren Aufgaben gleich bleiben |
Halten Sie die Entscheidung je Änderung fest, mit dem Datum, ab dem die neue Fassung gilt. Ein Typ-2-Bericht deckt den ganzen Zeitraum ab; Prüfer und Kunden müssen erkennen können, welche Fassung einer Kontrolle in welchem Teil des Zeitraums lief.
Wann ist ein Ereignis wesentlich?
Für Ereignisse gibt der Katalog einen Maßstab: Ereignisse und Bedingungen sind „typischerweise wesentlich, wenn sie mehrere Cloud-Kunden betreffen und der Cloud-Anbieter die betroffenen Parteien oder die Öffentlichkeit informiert“ (Abschnitt 3.4.5.1). Offenzulegen sind Ereignisse mit einer der drei Folgen aus der Tabelle oben. „Typischerweise“ ist ein Anhaltspunkt, keine abschließende Regel. Unsere Empfehlung für die Entscheidung:
- Führen Sie im Vorfallmanagement ein Merkmal, ob ein Vorfall eine der drei Folgen hatte: Verfügbarkeit vertraglich verfehlt, unbefugter Zugang Dritter zu Kundendaten, Integrität beeinträchtigt oder Schutzmaßnahme unwirksam.
- Prüfen Sie für jeden so markierten Vorfall den Maßstab des Katalogs: mehrere Kunden betroffen und Betroffene oder Öffentlichkeit informiert?
- Entscheiden Sie Grenzfälle bewusst, etwa einen unbefugten Zugriff, der nur einen Kunden betrifft, und halten Sie die Begründung fest. Stimmen Sie Grenzfälle früh mit dem Prüfer ab.
Die Liste der geprüften Vorfälle mit Entscheidung ist zugleich ein guter Nachweis für Mindestinhalt 6, den Umgang mit wesentlichen Ereignissen.
Wie legen Sie offen, ohne Angriffspunkte preiszugeben?
Der Katalog verlangt beides zugleich. Die Angaben „sollten so transparent wie möglich sein, ohne Schwachstellen oder potenzielle Angriffspunkte offenzulegen“; die Einzelheiten dürfen die Informationssicherheit einzelner Kunden nicht gefährden und sollten deshalb keine detaillierte Beschreibung einzelner Ereignisse enthalten (Abschnitt 3.4.5.1). Wir empfehlen, jedes Ereignis in fünf Feldern zu beschreiben und für jedes Feld eine Grenze zu ziehen:
| Feld | Hinein | Nicht hinein |
|---|---|---|
| Art | Kategorie nach dem Katalog, etwa „Verfügbarkeit vertraglich nicht erfüllt“ | Namen von Angreifergruppen, Spekulationen |
| Zeitraum | Monat oder Kalenderwoche, Dauer der Auswirkung | minutengenaue Abläufe, aus denen sich Erkennungszeiten ablesen lassen |
| Auswirkung | welche Funktionen, ob mehrere Kunden, ob Daten betroffen waren | Namen betroffener Kunden, Datensatzzahlen einzelner Kunden |
| Ursache | auf Ebene der Kontrolle, etwa „Konfigurationsänderung ohne vorgesehene zweite Prüfung“ | Produktversionen, Adressen, Namen interner Systeme, noch offene Schwachstellen |
| Gegenmaßnahmen | Maßnahme und Stand, etwa „technische Sperre gegen Änderungen ohne Freigabe, umgesetzt im Juni“ | Details von Erkennungsregeln oder Sicherheitswerkzeugen |
Ein Prüfstein vor der Freigabe: Lesen Sie jeden Absatz einmal mit den Augen eines Angreifers. Lernt er daraus etwas über ein heute noch offenes Ziel, kürzen Sie auf die Ebene der Kontrolle.
Beispiel: Typ-2-Abschnitt einer Abrechnungsplattform
Fiktives Beispiel, kein Kunde. Ein Anbieter betreibt eine Abrechnungsplattform für Pflegedienste als SaaS. Der Typ-2-Zeitraum läuft vom 01.01.2027 bis 31.12.2027. Er beginnt vor dem 1. Juni 2027 und soll deshalb nur die Kriterien von C5:2020 umfassen (Abschnitt 3.5); weil er nach dem 28. Februar 2027 endet, braucht die Beschreibung Angaben zu geplanten Änderungen. Auszug in unserer Formulierung:
| Eintrag | Formulierung in der Systembeschreibung (fiktiv) |
|---|---|
| Wesentliche Änderung | „Seit dem 15. Mai 2027 melden sich Beschäftigte des Anbieters über ein neues zentrales Identitätsverzeichnis an. Die Kontrollen zur Vergabe und Überprüfung von Berechtigungen laufen seitdem über dieses Verzeichnis; Verantwortliche und Häufigkeit sind unverändert. Bis zum 14. Mai 2027 galt die bisherige Kontrolle wie in Kapitel 6 beschrieben.“ |
| Wesentliche Änderung (Anpassung an C5:2026) | „Zur Anpassung an C5:2026 erzeugt der Anbieter seit September 2027 bei jedem Build eine Stückliste der Softwarekomponenten und legt sie mit dem Release ab. Seit November 2027 regelt eine eigene Richtlinie das Patch-Management mit Fristen je Schweregrad; bis dahin war es Teil der Betriebsrichtlinie. Bis zur jeweiligen Umstellung galten die Kontrollen wie in Kapitel 6 beschrieben.“ |
| Wesentliches Ereignis | „Im März 2027 war die Plattform nach einer fehlerhaften Konfigurationsänderung an der Datenbankschicht rund sechs Stunden nicht erreichbar. Alle Kunden waren betroffen, die vertraglich zugesagte Verfügbarkeit wurde für diesen Monat nicht erreicht. Kundendaten gingen nicht verloren. Der Anbieter hat die Kunden am selben Tag informiert.“ |
| Gegenmaßnahmen | „Änderungen an der Datenbankschicht sind seit Juni 2027 technisch nur nach Freigabe durch eine zweite Person möglich. Die Notfallübung im Oktober 2027 hat den Wiederanlauf dieser Schicht einbezogen.“ |
| Geprüft, nicht wesentlich | „Im Zeitraum gab es keine weiteren Ereignisse mit einer der in Abschnitt 3.4.5.1 genannten Folgen, die mehrere Kunden betrafen.“ |
Die Formulierungen nennen Kategorie, Zeitraum, Auswirkung und Maßnahme, aber kein Produkt, keine Version und keinen Ablauf, aus dem sich ein Angriffsweg ablesen ließe.
Geplante Änderungen beim Umstieg auf C5:2026
Endet ein Prüfungszeitraum am oder nach dem 28. Februar 2027, hat der Anbieter zusätzlich Angaben zu geplanten Änderungen an Kontrollen in die Systembeschreibung aufzunehmen (Abschnitt 3.5). Der Katalog begründet das mit Transparenz für Kunden über die Fähigkeit des Anbieters, die neuen Kriterien künftig einzuhalten. Welche Fassung für Ihren Zeitraum gilt, zeigt das Fristenmodul auf der Seite C5:2026.
Ein Enddatum für diese Pflicht nennt der Katalog nicht. Die BSI-FAQ setzt eine Grenze hinzu: Die Angaben seien nötig, wenn der Zeitraum am 28. Februar 2027 oder später endet, „aber noch vor dem 1. Juni 2027“ liegt; außerdem bezieht die FAQ die Regel auch auf Typ-1-Stichtage, während der Katalog vom Ende eines Zeitraums spricht. Das ist eine Abweichung zwischen FAQ und Katalog. Maßgeblich ist der Katalog; klären Sie mit Ihrem Prüfer, wie er die FAQ-Lesart behandelt.
Zu jeder geplanten Änderung soll die Beschreibung, soweit anwendbar, vier Angaben enthalten: das überarbeitete Kriterium, die Art der Änderung, den Umsetzungsstatus und das Umsetzungsdatum. Fortsetzung des Beispiels, Kriterientitel nach C5:2026 in der deutschen Fassung 1.1.0:
| Kriterium (C5:2026) | Art der Änderung (fiktiv) | Status | Umsetzungsdatum |
|---|---|---|---|
| DEV-13 Transparenz über Softwarekomponenten | Stückliste der Softwarekomponenten wird bei jedem Build erzeugt und mit dem Release abgelegt | umgesetzt | September 2027 |
| AM-04 Software-Asset-Inventar | Software-Inventar wird aus den Stücklisten aller produktiven Komponenten zusammengeführt | nicht umgesetzt | geplant März 2028 |
| OPS-27 Umgang mit Schwachstellen - Richtlinien und Verfahren zum Patch-Management | eigene Richtlinie mit Fristen je Schweregrad, bisher Teil der Betriebsrichtlinie | umgesetzt | November 2027 |
| SSO-07 Sicherstellung von Transparenz innerhalb von Service-Organisationen | vertragliche Anpassung mit dem Plattformanbieter und dem Rechenzentrumsbetreiber | nicht umgesetzt | geplant Februar 2028 |
Zwei Dinge sollten Sie unterscheiden. Was Sie im Zeitraum bereits umgestellt haben, ist eine Anpassung an C5:2026 und damit zugleich eine wesentliche Änderung, die in den Typ-2-Abschnitt gehört, im Beispiel DEV-13 und OPS-27; der Katalog weist darauf hin, dass Bewertungen dann den Stand vor und nach der Anpassung umfassen können. Was erst geplant ist, steht nur in den Angaben zu geplanten Änderungen. Für diese Angaben prüft der Prüfer, ob sie sachgerecht dargestellt sind; ob die geplanten Kontrollen angemessen ausgestaltet oder wirksam sind, beurteilt er noch nicht (Abschnitt 3.5).
Wer liefert die Angaben, und wer gibt sie frei?
Die Angaben entstehen in drei Prozessen: Änderungen aus dem Änderungsmanagement und dem Informationssicherheitsmanagement, Ereignisse aus dem Vorfall- und Notfallmanagement, geplante Änderungen aus dem Umstiegsplan auf C5:2026. Unsere Empfehlung: Sammeln Sie laufend während des Zeitraums, nicht erst am Ende, und lassen Sie die Formulierungen vom Informationssicherheitsbeauftragten (ISB) gegenlesen, bevor sie in die Beschreibung gehen. Die Geschäftsleitung bestätigt im Management Statement, dass die Beschreibung das System sachgerecht darstellt; dazu gehört dieser Teil.
Typische Lücken bei Änderungen und Ereignissen
| Mögliche Lücke | Ursache | Wirkung | Abhilfe |
|---|---|---|---|
| Ereignis fehlt | Vorfall im Ticketsystem geschlossen, aber nie gegen die drei Folgen aus Abschnitt 3.4.5.1 geprüft | Beschreibung lässt relevante Informationen aus und ist dann nicht sachgerecht; das Prüfungsurteil kann eingeschränkt werden (Abschnitt 3.4.12) | Merkmal im Vorfallmanagement und Liste der geprüften Vorfälle führen |
| Zu viel Detail | Nachbericht des Vorfalls in die Beschreibung kopiert | Angriffspunkte und interne Systemnamen werden für alle Leser des Berichts sichtbar | fünf Felder mit Grenzen verwenden, Ursache auf Ebene der Kontrolle beschreiben |
| Änderung ohne Stichtag | Werkzeugwechsel beschrieben, aber nicht, ab wann die neue Kontrolle gilt | Prüfer und Kunden können nicht erkennen, welche Kontrolle in welchem Teil des Zeitraums lief | je Änderung das Datum und die Kontrolle davor und danach nennen |
| Geplante Änderungen fehlen | Zeitraum gegen C5:2020 geprüft, Pflicht aus Abschnitt 3.5 übersehen | Pflichtangabe fehlt in der Beschreibung | Fristenmodul auf C5:2026 für jeden Zeitraum prüfen, Umstiegsplan als Quelle nutzen |
Häufige Fragen
Brauchen auch Typ-1-Berichte Angaben zu wesentlichen Änderungen und Ereignissen?+
Müssen wir jeden Sicherheitsvorfall nennen?+
Was schreiben wir, wenn nichts Wesentliches passiert ist?+
Prüft der Prüfer die geplanten Änderungen für C5:2026?+
Bis wann sind Angaben zu geplanten Änderungen nötig?+
Weiterlesen
- Systembeschreibung C5: Mindestinhalte, Gliederung, Prüfung
- C5:2026: Neuerungen, Umstieg von C5:2020 und Übergangsfrist
- C5-Testat Typ 2 oder Typ 1: Unterschied, Zeitraum, Wahl
- C5 Management Statement: Erklärung der Geschäftsleitung
- C5-Prüfung: Ablauf, Dauer und Rückwärtsplanung zum Testat
- C5-Gap-Analyse: Lücken, Maßnahmenplan und Projektplanung
Quellen
- BSI: Kriterienkatalog Cloud Computing C5:2026, Version 1.1.0 (PDF, deutsch), Abschnitte 3.4.5.1 und 3.5, lizenziert unter CC BY-ND 4.0 (abgerufen am 2026-11-01)
- BSI: C5 FAQ, Frage „Ab wann ist der C5:2026 anzuwenden? Welche Übergangsfristen gelten?“ (abgerufen am 2026-11-01)
- BSI: C5:2026 Änderungshistorie (Excel), Blatt „Change History“ (abgerufen am 2026-11-01)
Diese Inhalte dienen der allgemeinen technischen und organisatorischen Information und stellen keine Rechtsberatung dar (keine Rechtsdienstleistung i. S. d. RDG).