C5 und Unterauftragnehmer: Was passiert bei AWS, Azure und anderen Subdienstleistern?

Der SaaS-Dienst gehört Ihnen. Die Anwendung auch. Nur die Server stehen bei einem Hyperscaler, die E-Mails laufen über einen Spezialanbieter, das Monitoring über den nächsten und das Rechenzentrum betreibt ohnehin jemand anders. Auf dem Architekturdiagramm passt das alles noch auf eine Folie. Im C5-Projekt entwickelt die Folie plötzlich ein Eigenleben.

Die Versuchung ist groß, auf die Testate der großen Anbieter zu zeigen und das Thema damit für erledigt zu erklären. Doch ein C5-Bericht von AWS oder Azure testiert nicht automatisch Ihre Anwendung. Er beschreibt den Dienst und die Kontrollen des jeweiligen Anbieters in dessen Scope. Ihre eigene Sicherheitskette müssen Sie weiterhin beherrschen und nachweisen.

Die kurze Antwort

Ein Unterauftragnehmer wird für C5 dann zur relevanten Subdienstorganisation, wenn sein Beitrag für das Verständnis und die Sicherheit Ihres Cloud-Dienstes wesentlich ist und seine Kontrollen zusammen mit Ihren Kontrollen benötigt werden, um C5-Kriterien zu erfüllen.

Sie dürfen relevante Kontrollen eines Subdienstleisters mit der inklusiven Methode in die Prüfung einbeziehen oder mit der Carve-out-Methode abgrenzen. In beiden Fällen müssen Sie die Abhängigkeit transparent machen, erwartete Kontrollen definieren und den Anbieter überwachen. C5:2026 sagt unmissverständlich: Der Cloudanbieter bleibt letztlich dafür verantwortlich, dass Entwicklung und Betrieb seines Dienstes die anwendbaren Kriterien erfüllen.

Nicht jeder Lieferant ist eine Subdienstorganisation

Der aktuelle C5:2026-Katalog des BSI nennt zwei Merkmale, die gemeinsam vorliegen müssen.

Erstens muss der Dienst für das Verständnis der Architektur und der Erfüllung der C5-Kriterien relevant sein. Das ist typischerweise der Fall, wenn der Dienstleister zu Systemkomponenten beiträgt, auf sie zugreifen kann, vertrauliche Informationen verarbeitet oder Informationen zwischen sich und dem Cloud-Dienst überträgt.

Zweitens werden Kontrollen beim Dienstleister benötigt, die zusammen mit Ihren Kontrollen die Kriterien mit hinreichender Sicherheit erfüllen. Diese ergänzenden Kontrollen heißen Complementary Subservice Organisation Controls, kurz CSOC.

Die Firmenbezeichnung allein entscheidet also nichts. Ein kleiner DNS-Dienst kann für die Verfügbarkeit kritischer sein als ein großer Büroausstatter. Entscheidend sind Funktion, Zugriff, Datenfluss und Kontrollbeitrag.

AWS und Azure lösen nur ihre Schicht

Bei einem typischen SaaS-Dienst verteilt sich Verantwortung über mehrere Ebenen:

Ein Hyperscaler-Bericht kann wertvoller Nachweis für darunterliegende Kontrollen sein. Er beantwortet aber nicht, ob Sie sichere Netzregeln gesetzt, Schlüssel korrekt verwaltet, Änderungen geprüft, Vorfälle bearbeitet oder Kundenkontrollen verständlich beschrieben haben.

Die praktische Leitfrage lautet: „Welche C5-Kontrolle würde nicht mehr funktionieren, wenn dieser Dienstleister seinen Beitrag nicht liefert?“ Aus der Antwort entsteht die Kontrollkette.

Erst den eigenen Scope sauber ziehen

Bevor Sie Subdienstleister bewerten, muss klar sein, welcher eigene Cloud-Dienst geprüft wird. Produktvarianten, Regionen, Betriebsmodelle und optionale Komponenten können unterschiedliche Lieferketten besitzen. Unser Beitrag zum C5-Scope zeigt, warum nicht einfach das gesamte Unternehmen oder jedes Produkt automatisch im Testat steckt.

Erstellen Sie anschließend keine allgemeine Lieferantenliste, sondern eine dienstbezogene Abhängigkeitskarte:

1. Welche Komponenten erbringen den Cloud-Dienst?
2. Welches Unternehmen betreibt oder unterstützt jede Komponente?
3. Welche Daten werden verarbeitet, gespeichert oder übertragen?
4. In welchen Ländern geschieht das?
5. Welche C5-Kriterien hängen von externen Kontrollen ab?
6. Welche eigenen Kontrollen überwachen diesen Beitrag?

Damit trennen Sie den Druckerlieferanten vom kritischen Plattformdienst. Das spart Arbeit und macht die wirklich wichtigen Abhängigkeiten sichtbar.

Inclusive oder Carve-out: zwei Wege, keine Tarnkappe

C5:2026 erlaubt für relevante Subdienstorganisationen zwei Darstellungs- und Prüfungsmethoden.

Die inklusive Methode

Bei der inklusiven Methode werden relevante Funktionen und Kontrollen der Subdienstorganisation in die Systembeschreibung des Cloudanbieters aufgenommen. Die Prüfung erstreckt sich auf diese einbezogenen Kontrollen. Das kann eine starke, direkte Aussage liefern, benötigt aber Zugang, Mitwirkung und prüfbare Nachweise beim Subdienstleister.

Für einen großen Hyperscaler ist eine individuell inklusive Prüfung häufig praktisch schwer zu organisieren. Bei einem eng verbundenen Konzernunternehmen oder dedizierten Rechenzentrumsbetreiber kann sie realistischer sein.

Die Carve-out-Methode

Bei der Carve-out-Methode bleiben die Kontrollen der Subdienstorganisation außerhalb der unmittelbaren Prüfung. Ihre Systembeschreibung nennt stattdessen, welche ergänzenden Kontrollen dort erwartet werden und mit welchen eigenen Kontrollen Sie deren Wirksamkeit überwachen.

Carve-out heißt nicht: „Der Hyperscaler macht das schon.“ Der C5-Katalog betont ausdrücklich, dass diese Methode nicht dazu dienen darf, relevante Kriterien zu ignorieren. Sie brauchen eine belastbare Überwachung, besonders nach SSO-05.

Die Wahl kann je Subdienstleister unterschiedlich ausfallen. Dokumentieren Sie Methode und Begründung früh, denn sie beeinflussen Systembeschreibung, Nachweise, Prüfungsplanung und die spätere Aussage für Kunden.

Was C5:2026 in der Systembeschreibung sehen will

Für jede relevante Subdienstorganisation verlangt C5:2026 deutlich mehr als Name und Logo. Offenzulegen sind insbesondere:

• Art der ausgeführten Leistungen,
• Name des Vertragspartners,
• Länder der Verarbeitung und Speicherung,
• Komplexität und Einzigartigkeit der Leistung,
• daraus entstehende Abhängigkeit mit Begründung,
• Verfügbarkeit eines C5-Prüfberichts,
• erwartete Kontrollen beim Subdienstleister,
• eigene Kontrollen zur Überwachung ihrer Wirksamkeit.

Die Abhängigkeit kann beispielsweise als niedrig, mittel, hoch oder sehr hoch eingestuft werden. Ein fremdes Rechenzentrum oder eine unverzichtbare Plattform ohne realistische Alternative landet schnell weit oben. Die Zahl allein hilft wenig; die Begründung macht sie brauchbar.

Für Kunden ist diese Transparenz zentral, wenn sie Scope und Grenzen eines C5-Berichts bewerten. Für Sie als Anbieter ist sie zuerst ein Steuerungsinstrument: Wo besteht ein Single Point of Failure, wo fehlt ein Exit und wo beruht Sicherheit nur auf einer Vertriebsfolie?

Wie Sie den Kontrollbeitrag nachweisen

Ein Stapel Zertifikate ist noch kein Lieferantenmanagement. Verknüpfen Sie externe Nachweise mit konkreten Risiken und Kontrollen.

Eine belastbare Akte pro kritischem Subdienstleister enthält typischerweise:

• Vertrag, Leistungsbeschreibung und Sicherheitsanforderungen,
• Architektur- und Datenflussbezug zum eigenen Dienst,
• aktuelle Prüfberichte oder Zertifikate samt Scope und Zeitraum,
• Bewertung von Abweichungen und Kundenkontrollen aus diesen Berichten,
• Zuordnung erwarteter CSOC zu eigenen C5-Kriterien,
• Leistungs-, Sicherheits- und Verfügbarkeitskennzahlen,
• Vorfall- und Änderungsinformationen,
• regelmäßige Reviewentscheidung mit Besitzer und Folgemaßnahmen,
• Exit-, Wechsel- oder Notfallüberlegungen bei hoher Abhängigkeit.

Ein vorhandenes ISO 27001-Lieferantenmanagement hilft stark. Es liefert Risikobewertung, Auswahl, Vertragsanforderungen und Reviews. C5 macht die Betrachtung jedoch dienst- und kontrollbezogener. Der Artikel C5 und ISO 27001 im Vergleich ordnet die beiden Systeme grundsätzlich ein.

Die eigene Überwachung muss Substanz haben

Besonders bei Carve-out lebt die Aussage davon, was Sie selbst tun. Nur einmal jährlich eine Zertifikatsdatei herunterzuladen ist bei einem hochkritischen Plattformanbieter dünn.

Kombinieren Sie je nach Risiko mehrere Signale:

• Berichte und Bescheinigungen auf Scope, Zeitraum und Feststellungen prüfen,
• Sicherheitsmeldungen und wesentliche Dienständerungen verfolgen,
• SLA- und Verfügbarkeitsdaten auswerten,
• eigene Kontrolltests an Schnittstellen durchführen,
• offene Risiken und Maßnahmen nachhalten,
• Regionen, Unterketten und vertragliche Änderungen prüfen,
• Wiederanlauf und Exit realistisch testen oder zumindest technisch planen.

Der Rhythmus folgt dem Risiko. Ein austauschbarer Hilfsdienst braucht weniger Aufmerksamkeit als die Plattform, ohne die Ihr gesamter Cloud-Dienst stillsteht.

Legen Sie außerdem fest, was bei einer schlechten Bewertung passiert. Eine Überwachung ohne Eskalationsweg sammelt nur höflich Probleme. Definieren Sie Schwellen für Maßnahmen, Risikofreigaben, technische Ersatzkontrollen und einen möglichen Wechsel. Bei einer sehr hohen Abhängigkeit sollte die Geschäftsleitung verstehen, welche Folgen ein Ausfall, eine wesentliche Vertragsänderung oder eine nicht behobene Prüfungsabweichung hätte. So verbindet sich die operative Lieferantenkontrolle mit dem Risikomanagement, statt als jährliche Dokumentenübung daneben zu stehen.

Auch Änderungen am bezogenen Dienst gehören in diesen Kreislauf. Eine neue Region, ein anderer Schlüsseldienst oder eine geänderte Plattformfunktion kann Datenflüsse und Kontrollzuordnung verschieben. Lassen Sie technische Änderungen deshalb nicht nur durch das eigene Change Management laufen, sondern prüfen Sie ihren Einfluss auf Subdienstleister, Scope und Systembeschreibung.

Typische Stolperfallen

Die häufigste Falle ist das ungeprüfte Vertrauen in eine bekannte Marke. Große Anbieter besitzen reife Kontrollen, aber deren Berichte haben Grenzen, Ausnahmen und Kundenpflichten. Die zweite Falle ist eine Lieferantenliste ohne Verbindung zur konkreten Architektur. Sie ist vollständig und trotzdem nutzlos.

Ebenfalls heikel sind unbekannte Unterketten. Ihr Vertragspartner nutzt seinerseits weitere Dienste. C5 verlangt nicht, jede Schraube des Internets aufzuschreiben, wohl aber die relevanten Leistungen, Kontrollen und Abhängigkeiten nachvollziehbar zu beherrschen.

Die vierte Falle ist ein verspäteter Start. Wenn die Prüfung bereits terminiert ist, lassen sich fehlende Vertragsrechte, abgelaufene Berichte oder unklare Datenregionen selten über Nacht heilen. Binden Sie Einkauf, Technik und Informationssicherheit ein, bevor der Beobachtungszeitraum beginnt. Wie der Gesamtweg aussieht, zeigt unser Beitrag zum Ablauf bis zum C5-Testat.

Ein pragmatischer Arbeitsplan

Beginnen Sie mit den fünf bis zehn Anbietern, ohne die der Dienst nicht laufen oder seine Sicherheitsziele nicht erreichen würde. Ordnen Sie Leistungen, Daten, Länder, Kriterien und Nachweise zu. Entscheiden Sie danach für jede relevante Subdienstorganisation über inklusive oder Carve-out-Methode. Erst dann erweitern Sie die Betrachtung.

Prüfen Sie zum Schluss die Kundensicht: Kann ein sachkundiger Leser aus Ihrer Systembeschreibung erkennen, wovon der Dienst abhängt und wie Sie diese Abhängigkeit beherrschen? Wenn die Antwort nur mit internem Architekturwissen möglich ist, ist die Beschreibung noch nicht fertig.