C5-Systembeschreibung schreiben: Inhalt, Aufbau, Prüfsicht

Wer ein C5-Testat anstrebt, schreibt in aller Regel eine Systembeschreibung. Sie ist das Dokument, in dem der Cloud-Anbieter seinen Dienst und das zugehörige interne Kontrollsystem so darstellt, dass Kunden die Informationssicherheit beurteilen können. Was das Testat insgesamt aussagt, steht auf der Seite C5-Testat; hier geht es nur um das Schreiben der Beschreibung.

Was ist die Systembeschreibung im C5?

Die Systembeschreibung ist die Beschreibung des internen Kontrollsystems, das für Entwicklung und Betrieb des Cloud-Dienstes relevant ist. Bei der Prüfung einer Erklärung (Attestation Engagement) ist sie der Prüfungsgegenstand; die Prüfung stützt sich zusätzlich auf eine schriftliche Erklärung der Geschäftsleitung (Management Statement; Katalog, Abschnitte 3.4.4.1 und 3.4.5.2). Der Katalog nennt das Dokument „Beschreibung“ oder „Systembeschreibung“, im Englischen „Description“.

Bei einer direkten Prüfung (Direct Engagement) stellt der Anbieter keine Systembeschreibung bereit. Der Prüfer erhebt das System selbst und stellt es im Bericht dar (Abschnitte 3.4.4.2 und 3.4.13). Der Katalog hält diese Variante für Anbieter geeignet, die ihr Kontrollsystem noch nicht ausreichend dokumentiert haben. Wie sich beide Prüfungsarten im Ablauf unterscheiden, steht auf der Seite Ablauf der C5-Prüfung.

Im fertigen Bericht steht die Systembeschreibung als dritter Bestandteil nach dem Prüfungsbericht des unabhängigen Prüfers und dem Management Statement, vor der Darstellung der Kontrollen mit Prüfungshandlungen und Ergebnissen (Abschnitt 3.4.13).

Die acht Mindestinhalte nach Abschnitt 3.4.5.1

Der Katalog verlangt eine sachgerechte Darstellung des Systems mit acht Mindestinhalten, „um Cloud-Kunden ausreichende Transparenz über die Informationssicherheit der im Umfang befindlichen Cloud-Dienste zu geben“. Die Spalte „Katalog“ zitiert die amtliche deutsche Fassung wörtlich, Auslassungen sind mit […] gekennzeichnet; die beiden anderen Spalten sind unsere Hinweise für die Praxis.

Zwei Regeln gelten für alle acht Punkte. Die Systembeschreibung darf keine Informationen auslassen oder verfälschen, die für die Erfüllung der anwendbaren C5-Kriterien relevant sind (Abschnitt 3.4.5.1 Nr. 2). Und eine Darstellung gilt nur dann als sachgerecht, wenn sie die Angaben zu den Rahmenbedingungen und zu den Subdienstleistern enthält (Abschnitt 3.4.7). Wer Punkt 3 oder Punkt 8 knapp hält, riskiert also die gesamte Beschreibung.

Was bei Typ 2 zusätzlich hineingehört

Bei einem Typ-2-Bericht verlangt der Katalog drei weitere Inhalte (Abschnitt 3.4.5.1): wesentliche Änderungen am internen Kontrollsystem im Prüfungszeitraum, wesentliche Ereignisse, die zu verfehlter Verfügbarkeit, zu unbefugtem Zugriff Dritter auf Kundendaten oder zu beeinträchtigter Integrität beziehungsweise unwirksamen Schutzmaßnahmen geführt haben, und die eingeleiteten Gegenmaßnahmen. Wesentlich sind Ereignisse typischerweise dann, wenn sie mehrere Kunden betreffen und der Anbieter die Betroffenen oder die Öffentlichkeit informiert. Die Angaben sollen transparent sein, ohne Schwachstellen oder Angriffspunkte offenzulegen.

Beim Umstieg auf C5:2026 gelten die Anpassungen der Kontrollen als wesentliche Änderungen; endet ein Prüfungszeitraum am oder nach dem 28. Februar 2027, braucht die Beschreibung zusätzlich Angaben zu geplanten Änderungen (Abschnitt 3.5). Ein Enddatum dafür nennt der Katalog nicht; nur die BSI-FAQ begrenzt die Angaben auf Zeiträume, die vor dem 1. Juni 2027 enden. Die Fälle im Einzelnen zeigt die Seite C5:2026. Unsere Empfehlung für die Formulierung wesentlicher Änderungen und Ereignisse: Kunden sollen Ursache, Auswirkung und Gegenmaßnahme erkennen können, ohne dass ein Angriffspunkt sichtbar wird. Den Unterschied der Berichtstypen erklärt Typ 1 oder Typ 2.

Beispielgliederung für eine Systembeschreibung

Der Katalog gibt Inhalte vor, keine Gliederung. Die folgende Gliederung ist unsere Empfehlung; sie folgt den acht Mindestinhalten, damit Prüfer und Kunden jeden Punkt schnell finden.

1. Einleitung und Geltungsbereich: Zweck des Dokuments, Berichtstyp, Stichtag oder Zeitraum, Katalogfassung (C5:2020 oder C5:2026), geprüfte Dienste und Regionen (Mindestinhalt 1).
2. Unternehmen und Dienst: Organisation, Servicemodell, Funktionsumfang, Kundengruppen, nicht erfasste Module (Mindestinhalt 1).
3. Systemkomponenten: Architektur, Infrastruktur, Software, Daten und Datenflüsse, Netzwerk, Betriebs- und Entwicklungswerkzeuge, Personen und Rollen (Mindestinhalt 2).
4. Rahmenbedingungen des Dienstes: ein Unterkapitel je GC-01 bis GC-06, abgestimmt mit Vertrag und SLA, damit die Rahmenbedingungen nicht vom Vertrag abweichen (Mindestinhalt 3).
5. Internes Kontrollsystem: Kontrollumgebung, Risikobewertung, Information und Kommunikation, Überwachung (Mindestinhalt 5).
6. Anwendbare Kriterien und Kontrollen: Tabelle aller Kriterien mit Anwendbarkeit, Begründungen für Ausschlüsse, Auswahl der Zusatzkriterien, danach je Kriterium die zugeordneten Kontrollen (Mindestinhalte 4 und 5).
7. Umgang mit wesentlichen Ereignissen: Vorfall- und Notfallprozess, Kommunikation an Kunden (Mindestinhalt 6).
8. Korrespondierende Kundenkontrollen (CUEC): nummerierte Liste der Kontrollen, die Ihr Dienst beim Kunden voraussetzt, mit Bezug zum jeweiligen Kriterium (Mindestinhalt 7). Als Ausgangspunkt dienen die korrespondierenden Kriterien für Kunden, die der Katalog bei ausgewählten Kriterien angibt. Sie sind allgemein und nicht abschließend; die CUEC schreiben Sie für Ihren Dienst.
9. Subdienstleister: Methode (Carve-out oder Inclusive), Tabelle der Subdienstleister mit den Pflichtangaben, erwartete Kontrollen, eigene Überwachung (Mindestinhalt 8).
10. Nur Typ 2: wesentliche Änderungen, wesentliche Ereignisse, Gegenmaßnahmen; beim Umstieg geplante Änderungen nach Abschnitt 3.5.

Das Management Statement ist ein eigener Berichtsbestandteil und gehört nicht in die Gliederung der Beschreibung; darin bestätigt die Geschäftsleitung schriftlich, dass die Beschreibung das System sachgerecht darstellt (Abschnitt 3.4.5.2). Die Gliederung als bearbeitbare Datei liegt auf der Seite Vorlagen.

Wie konkret müssen Kontrollen beschrieben sein?

So konkret, dass ein Prüfer daraus eine Prüfungshandlung ableiten kann. Der Prüfer beurteilt die Ausgestaltung unter anderem nach Häufigkeit oder Zeitpunkt der Kontrolle, nach Befugnis und Kompetenz der verantwortlichen Person und nach den Tätigkeiten innerhalb der Kontrolle (Abschnitt 3.4.9). Die Unterkriterien sind ausdrücklich dazu da, Kontrollen zuzuordnen; die Unterkriterien eines Kriteriums sind zusammen zu lesen (Abschnitt 2.1). Ein Kriterium gilt als nicht erfüllt, wenn ein einziges Unterkriterium nicht erfüllt ist (Abschnitt 3.4.12).

Unsere Empfehlung: Jede Kontrolle bekommt dieselben Felder. Beispiel einer eigenen Kontrollbeschreibung (erfunden, kein Katalogtext):

Ob eine solche Kontrolle alle zugeordneten Unterkriterien abdeckt, beurteilt der Prüfer. Deckt sie ein Element nicht ab, meldet er die Lücke; kann der Anbieter eine weitere Kontrolle belegen, nimmt er sie in die Beschreibung auf (Abschnitt 3.4.8).

Anwendbarkeit, Ausschlüsse und Zusatzkriterien richtig begründen

Die Basiskriterien sind der Mindestumfang jeder Prüfung. Ausschließen dürfen Sie ein Kriterium nur mit einer Begründung, die sich auf Art und Ausgestaltung des Dienstes oder auf Ihre Grundsätze, Verfahren und Maßnahmen bezieht, etwa reine IaaS-Kriterien bei einem SaaS-Dienst. Der Prüfer beurteilt, ob die Begründung sachgerecht dargestellt ist. Ausdrücklich unzulässig ist ein Ausschluss, weil Kontrollen fehlen, nicht wirksam sind oder der Anbieter die Erfüllung nicht nachweisen will (Abschnitt 3.4.3). Verlangt ein Kriterium einen risikobasierten Ansatz und hat die Risikobewertung kein zu behandelndes Risiko ergeben, gehört auch diese Begründung in die Darstellung der Anwendbarkeit.

Zusatzkriterien wählt der Anbieter frei, auch einzelne Unterkriterien; die Auswahl ist in der Beschreibung zu begründen. Ein verschärfendes Zusatz-Unterkriterium ersetzt in der Beschreibung das Basis-Unterkriterium, ein erweiterndes erscheint zusammen mit den Basis-Unterkriterien (Abschnitt 3.4.3).

Subdienstleister und Kundenpflichten in der Beschreibung

Für jeden Subdienstleister nennt die Beschreibung die gewählte Methode, Carve-out oder Inclusive (Abschnitt 3.4.6). Beim Carve-out bleiben die Kontrollen des Subdienstleisters außerhalb von Beschreibung und Prüfung; die Beschreibung nennt aber die Kontrollen, die Sie beim Subdienstleister voraussetzen (Complementary Subservice Organisation Controls, CSOC), und Ihre eigene Überwachung nach SSO-05. Wie Sie die Methode wählen und was ein Plattformtestat abdeckt, steht auf der Seite C5-Scope. Für die Pflichtangaben je Subdienstleister lohnt ein eigenes Verzeichnis, ein Subdienstleisterinventar; eine Vorlage dafür liegt auf der Seite Vorlagen.

Die korrespondierenden Kundenkontrollen (CUEC) prüft der Prüfer nicht beim Kunden. Er prüft nur, ob die Annahmen darüber in der Beschreibung sachgerecht dargestellt sind (Abschnitt 3.4.4.1). Im Bericht steht dann, dass die Kriterien nur erfüllt werden können, wenn auch diese Kundenkontrollen wirksam sind (Abschnitt 3.4.13). Für Kunden im Gesundheitswesen ist das mehr als eine Formalie: § 393 Abs. 3 Nr. 3 SGB V verlangt, dass „die im Prüfbericht des Testats enthaltenen, korrespondierenden Kriterien für Kunden umgesetzt sind“. Das Gesetz verwendet den Namen des Katalogteils, nicht den Begriff CUEC; welche Angaben im Bericht genau gemeint sind, ist rechtlich zu klären, siehe § 393 SGB V.

Wer schreibt die Systembeschreibung?

Der Cloud-Anbieter. Der Prüfungsbericht des unabhängigen Prüfers hält fest, dass der Anbieter für die Erstellung der Beschreibung und der Erklärung verantwortlich ist, einschließlich Vollständigkeit, Richtigkeit und Art der Darstellung (Abschnitt 3.4.13 Nr. 1.2). Die Geschäftsleitung bestätigt anschließend im Management Statement, dass die Beschreibung das System sachgerecht darstellt (Abschnitt 3.4.5.2).

In der Praxis empfehlen wir eine federführende Person aus dem Informationssicherheitsmanagement, die Beiträge der Fachbereiche einsammelt: Betrieb und Plattform für Komponenten und Kontrollen, Entwicklung für Änderungsprozesse, Recht oder Einkauf für Rahmenbedingungen und Subdienstleister, die Geschäftsleitung für Kontrollumgebung und Freigabe. Externe Berater können strukturieren, formulieren und gegenlesen. Der Prüfer selbst ist dafür keine Adresse: Er muss vor Annahme des Auftrags seine Unabhängigkeit sicherstellen (Abschnitt 3.4.2). Blackfort Technology begleitet die Erstellung, das Testat erteilt ein unabhängiger Prüfer.

Was der Prüfer an der Systembeschreibung prüft

Der Prüfer beurteilt, ob die Beschreibung das System zum Stichtag oder über den Zeitraum sachgerecht darstellt (Abschnitt 3.4.4.1). Konkret verlangt der Katalog (Abschnitt 3.4.7):

• Er liest die Beschreibung und beurteilt, ob die Aspekte im Prüfungsumfang sachgerecht dargestellt sind, mit besonderem Blick auf den Mindestinhalt.
• Er stellt durch Befragungen zusammen mit Beobachtung und Einsicht in Aufzeichnungen fest, ob das beschriebene System so implementiert ist.
• Er prüft, ob die Angaben zu den Rahmenbedingungen und zu den Subdienstleistern enthalten sind; ohne sie ist die Darstellung nicht sachgerecht.

Stellt der Prüfer fest, dass die Beschreibung das System in wesentlichen Belangen nicht sachgerecht darstellt, ist sein Prüfungsurteil einzuschränken oder zu versagen (Abschnitt 3.4.12). Eine schön formulierte Beschreibung, die vom gelebten Betrieb abweicht, ist deshalb gefährlicher als eine knappe, die stimmt.

Vorhandene SOC-2- oder ISO-Dokumentation wiederverwenden

Eine Systembeschreibung aus einer anderen Prüfung, etwa für SOC 2, dürfen Sie wiederverwenden, müssen sie aber an die Anforderungen des C5 an die Systembeschreibung anpassen (Abschnitt 3.4.4.1); Rahmenbedingungen, korrespondierende Kundenkontrollen und Subdienstleister (Mindestinhalte 3, 7 und 8) schreiben Sie dabei eigens für den C5. Was sich im Einzelnen übernehmen lässt, zeigen die Seiten C5 und SOC 2 und C5 und ISO 27001.

Beispiel: Systembeschreibung für einen KI-Befundassistenten

Fiktives Beispiel, kein Kunde. Ein Anbieter betreibt einen KI-Assistenten, der Radiologiebefunde vorstrukturiert, als SaaS für Kliniken. Der Dienst läuft auf einer IaaS-Plattform in einer deutschen Region, die Modellinferenz auf eigenen GPU-Instanzen. Geplant ist eine Erstprüfung als Typ 2 mit sechs Monaten Zeitraum.

Drei typische Lücken und wie Sie sie schließen