C5 für SaaS-Anbieter: Bin ich überhaupt ein Cloudanbieter?

„Wir sind kein Cloudanbieter. Wir entwickeln Software.“ Dann zeigt jemand auf die Anwendung, die Kunden rund um die Uhr im Browser nutzen. Sie läuft auf zentral betriebener Infrastruktur, wird vom eigenen Team aktualisiert und verarbeitet Kundendaten. Unter der Haube stehen AWS, Azure, StackIt oder ein Rechenzentrum.

Das ist der Moment, in dem die Berufsbezeichnung ein wenig mit der technischen Realität diskutiert.

Viele SaaS-Unternehmen verstehen sich zuerst als Softwarehersteller. Das ist nachvollziehbar, beantwortet aber nicht die C5-Frage. Entscheidend ist nicht, was auf der Firmenwebsite bei „Über uns“ steht. Entscheidend ist, welche Leistung Sie Ihren Kunden tatsächlich bereitstellen und wer Entwicklung und Betrieb dieses Dienstes kontrolliert.

Die kurze Antwort

Wenn Kunden Ihre Software über ein Netz nutzen, Sie den Dienst zentral betreiben und dafür skalierbare Cloud-Ressourcen bereitstellen oder steuern, sind Sie nach der Logik von C5 sehr wahrscheinlich ein Cloudanbieter.

Dass die Infrastruktur bei einem Hyperscaler oder externen Rechenzentrum liegt, ändert daran grundsätzlich nichts. AWS, Azure oder ein Hostinganbieter können wichtige Subdienstleister sein. Gegenüber Ihren Kunden stellen jedoch Sie den SaaS-Dienst bereit. Damit sind Sie Anbieter dieses Cloud-Dienstes und verantwortlich für die Kontrollen in Ihrem Einflussbereich.

Nicht jedes online erreichbare Programm ist automatisch ein Cloud-Dienst. Eine einzelne fest zugewiesene Maschine, die nach manueller Bestellung für einen Kunden betrieben wird, kann eher klassisches Hosting sein. Aber auch dort entscheidet die tatsächliche Architektur und Bereitstellung – nicht das Etikett auf dem Angebot.

Was C5 unter Cloud Computing versteht

Der C5:2026-Kriterienkatalog des BSI beschreibt Cloud Computing als Netzwerkzugriff auf einen skalierbaren und elastischen Pool gemeinsam genutzter physischer oder virtueller Ressourcen. Die Bereitstellung und Verwaltung erfolgt bedarfsgesteuert und als Self-Service. Als Ressourcen nennt der Katalog ausdrücklich nicht nur Server, Netze und Speicher, sondern auch Software und Anwendungen.

Ein Cloud-Dienst ist danach eine IT-Leistung, die über Cloud Computing angeboten wird. Dazu gehören Infrastruktur, Plattformen und Software. Cloudanbieter ist schlicht die natürliche oder juristische Person, die diesen Cloud-Dienst bereitstellt.

Für SaaS-Unternehmen sind damit fünf Merkmale besonders nützlich:

1. Netzwerkzugriff: Kunden nutzen die Anwendung über Internet, private Verbindung oder eine andere Netzschnittstelle.
2. Zentraler Betrieb: Der Anbieter betreibt die produktive Leistung und spielt Änderungen zentral ein.
3. Geteilte Ressourcenbasis: Mehrere Kunden nutzen gemeinsame physische oder virtuelle Plattformressourcen, auch wenn Daten und Mandanten logisch getrennt sind.
4. Skalierbarkeit und Elastizität: Rechenleistung, Speicher oder Anwendungsinstanzen lassen sich dem Bedarf anpassen.
5. Bedarfsgesteuerte Bereitstellung: Kunden oder deren Administratoren können Konten, Funktionen oder Ressourcen automatisiert aktivieren und verwalten.

Nicht jedes Merkmal muss in der Werbung ausdrücklich versprochen werden. Es muss auch nicht alles vollautomatisch und in Sekunden geschehen. Die Gesamtschau zeigt, ob Sie einen Cloud-Dienst bereitstellen oder lediglich Software übergeben, die der Kunde selbst betreibt.

Der entscheidende Unterschied: Produkt liefern oder Dienst betreiben

Ein klassischer Softwarehersteller liefert Programmcode, Installationspakete oder Lizenzen. Der Kunde installiert und betreibt die Anwendung in seiner eigenen Umgebung. Der Hersteller kann Updates, Support und Wartung anbieten, kontrolliert aber nicht den produktiven Dienst des Kunden.

Ein SaaS-Anbieter liefert dagegen ein nutzbares Ergebnis: Der Kunde meldet sich an und verwendet die Anwendung. Der Anbieter organisiert Verfügbarkeit, Betrieb, Updates, Datensicherung, Protokollierung, Schwachstellenbehandlung und einen erheblichen Teil der Zugriffssicherheit. Damit verkauft er nicht nur Software, sondern betreibt eine fortlaufende IT-Leistung.

Genau dort wird C5 relevant. Der Kriterienkatalog betrachtet das Kontrollsystem für Entwicklung und Betrieb eines konkreten Cloud-Dienstes. Er fragt also nicht nur, ob Ihr Quellcode ordentlich entwickelt wird. Er betrachtet auch, wie der Dienst bereitgestellt, überwacht, abgesichert, wiederhergestellt und gegenüber Kunden beschrieben wird.

Eine bestehende ISO 27001-Zertifizierung kann dabei stark helfen. Sie ändert aber weder Ihre Rolle noch ersetzt sie die dienstbezogene Prüfung. Warum Zertifikat und Testat nicht dasselbe sind, erklären wir in C5 und ISO 27001.

Typische Geschäftsmodelle im Schnellcheck

Die folgende Einordnung ist bewusst praktisch. Grenzfälle brauchen eine genaue Betrachtung von Vertrag, Architektur und Betriebsmodell.

Ein häufiger Denkfehler lautet: „Unsere Kunden teilen sich keine Datenbank, also sind wir keine Cloud.“ Mandantentrennung und Ressourcenteilung sind zwei verschiedene Dinge. Daten können streng getrennt sein, während Compute, Netzwerk, Plattformdienste oder physische Infrastruktur gemeinsam genutzt werden. Das ist im SaaS-Betrieb völlig normal.

AWS oder Azure machen Sie nicht zum bloßen Kunden

Wenn Ihr SaaS-Dienst auf AWS, Azure, Google Cloud oder einer anderen Plattform läuft, haben Sie zwei Rollen gleichzeitig:

• Gegenüber dem Hyperscaler sind Sie Cloudkunde.
• Gegenüber den Nutzern Ihrer Anwendung sind Sie Cloudanbieter.

Diese Rollen liegen übereinander wie technische Schichten. Der Hyperscaler verantwortet beispielsweise bestimmte physische Infrastruktur- und Plattformkontrollen. Sie verantworten unter anderem Ihre Anwendung, Konfiguration, Benutzerverwaltung, Softwareentwicklung, Datenverarbeitung, Monitoring, Incident-Reaktion und Kundenkommunikation – abhängig vom gewählten Servicemodell.

C5 erwartet, dass diese Abhängigkeiten nicht im Nebel verschwinden. Relevante Subdienstleister müssen identifiziert, risikobasiert bewertet, vertraglich gesteuert und überwacht werden. Ihre Testate und Berichte sind wichtige Nachweise. Sie ersetzen aber nicht Ihre eigenen Kontrollen.

Umgekehrt bleiben auch Aufgaben bei Ihren Kunden. Welche Pflichten für eine sichere Nutzung vorausgesetzt werden, muss verständlich beschrieben sein. Genau dazu dienen die korrespondierenden C5-Kriterien für Kunden.

Welcher Dienst wäre überhaupt im C5-Scope?

Wenn Sie sich als Cloudanbieter eingeordnet haben, ist noch nicht automatisch das ganze Unternehmen Gegenstand eines Testats. C5 bezieht sich auf konkret beschriebene Cloud-Dienste.

Ein SaaS-Unternehmen kann beispielsweise mehrere Produkte, Editionen, Regionen und Betriebsmodelle anbieten. Vielleicht läuft das Kernprodukt als Multi-Tenant-SaaS in der EU, eine ältere Version wird bei Kunden installiert und ein Zusatzmodul stammt von einem Partner. Diese Leistungen müssen nicht alle denselben C5-Scope haben.

Für einen belastbaren Scope sind mindestens folgende Punkte zu klären:

• Welche Anwendung, Editionen und Funktionen gehören zum Dienst?
• Welche Regionen und Standorte werden einbezogen?
• Welche Teams, Systeme und Entwicklungsprozesse tragen den Dienst?
• Welche zentralen Unternehmensfunktionen sind sicherheitsrelevant?
• Welche Subdienstleister und Plattformen werden genutzt?
• Welche Varianten oder kundenspezifischen Instanzen bleiben außerhalb?

Unser Artikel Der C5-Scope: Was wird eigentlich testiert? führt diese Abgrenzung im Detail aus. Für die Rollenfrage genügt zunächst: Sie können Cloudanbieter sein, ohne dass jedes Produkt Ihres Unternehmens ein Cloud-Dienst ist.

Bin ich verpflichtet, ein C5-Testat zu haben?

Cloudanbieter zu sein und ein C5-Testat vorlegen zu müssen, sind zwei unterschiedliche Fragen.

C5 ist ein Kriterienkatalog und Prüfungsrahmen für Cloud-Dienste. Daraus folgt keine pauschale Testatspflicht für jedes SaaS-Unternehmen. Relevant wird der Nachweis beispielsweise durch gesetzliche Vorgaben in bestimmten Einsatzfeldern, durch öffentliche Beschaffung, Ausschreibungen, Kundenverträge oder Markterwartungen.

Manche Unternehmen brauchen das Testat, weil ihre Kunden es verlangen. Andere nutzen C5 zunächst als Sicherheits- und Transparenzrahmen. Und wieder andere betreiben zwar SaaS, bedienen aber derzeit keinen Markt, in dem ein C5-Nachweis wirtschaftlich oder regulatorisch sinnvoll ist.

Deshalb sollte die Reihenfolge lauten:

1. Cloudanbieterrolle und konkreten Cloud-Dienst bestimmen.
2. Kunden, Einsatzfelder und Anforderungen prüfen.
3. Geplanten Testat-Scope festlegen.
4. Readiness und Aufwand bewerten.

Die Pflichtfrage behandeln wir separat in C5-Pflicht: Braucht Ihr Unternehmen ein C5-Testat?. So vermeiden Sie sowohl blinden Aktionismus als auch das vorschnelle „Betrifft uns nicht.“

Sieben Fragen für Ihre eigene Einordnung

Wenn Sie bei mindestens fünf der folgenden Fragen klar mit Ja antworten, sollten Sie Ihr Angebot sehr ernsthaft als Cloud-Dienst prüfen:

1. Nutzen Kunden unsere Anwendung über eine Netzverbindung statt durch eigenen lokalen Betrieb?
2. Steuern wir die produktive Bereitstellung, Updates und wesentliche Betriebsprozesse?
3. Nutzen mehrere Kunden eine gemeinsame physische oder virtuelle Ressourcenbasis?
4. Lassen sich Ressourcen oder Funktionen bedarfsabhängig skalieren?
5. Können Kunden Konten, Nutzer, Funktionen oder Kapazitäten automatisiert verwalten?
6. Verarbeiten oder speichern wir Kundendaten innerhalb des laufenden Dienstes?
7. Versprechen wir Verfügbarkeit, Support, Wiederherstellung oder andere laufende Serviceeigenschaften?

Die Zahl fünf ist dabei keine offizielle BSI-Schwelle. Sie ist eine praktische Warnlampe. Eine einzige besonders prägende Eigenschaft kann wichtiger sein als mehrere schwache Indizien. Entscheidend bleibt das Gesamtmodell.

Dokumentieren Sie Ihre Einordnung mit einer kurzen Leistungsbeschreibung und einem Architekturüberblick. Halten Sie fest, was Kunden erhalten, wer den Betrieb kontrolliert, welche Ressourcen geteilt werden und welche Dienstleister beteiligt sind. Damit schaffen Sie gleichzeitig die erste Grundlage für einen späteren Scope.

Was sich für ein SaaS-Unternehmen praktisch ändert

Die Einordnung als Cloudanbieter bedeutet nicht, dass Sie morgen ein neues Organigramm drucken müssen. Sie verschiebt aber den Blick auf Informationssicherheit.

Ihr Produkt, der technische Betrieb und das Managementsystem müssen als zusammenhängender Dienst betrachtet werden. Produktmanagement, Entwicklung, Operations, Support, Einkauf und Informationssicherheit liefern jeweils Teile des Kontrollsystems. C5 lässt sich nicht allein beim ISB abstellen wie ein Paket an der Rezeption.

Ein sinnvoller erster Arbeitsstand enthält:

• eine Beschreibung des SaaS-Dienstes und seiner Systemgrenzen;
• eine Architektur- und Datenflussübersicht;
• ein Shared-Responsibility-Modell;
• ein Verzeichnis relevanter Subdienstleister;
• eine Zuordnung vorhandener Kontrollen zu C5:2026;
• eine Liste fehlender Kontrollen und Nachweise;
• eine Entscheidung über Ziel, Typ und Zeitpunkt der Prüfung.

Wie aus diesem Stand ein Testat-Projekt wird, zeigt C5: Wie bekommt man ein C5-Testat?. Die Unterschiede zwischen Stichtags- und Zeitraumprüfung finden Sie in C5 Typ 1 oder Typ 2.

Typische Fehlannahmen

„Wir besitzen keine Server.“ Das ist kein Gegenargument. Cloudanbieter können ihre gesamte Infrastruktur von Subdienstleistern beziehen.

„Wir nennen es Plattform, nicht Cloud.“ Auch der Name entscheidet nichts. Eine Plattform kann ein Cloud-Dienst sein.

„Jeder Kunde hat eine eigene Instanz.“ Dedizierte Instanzen können weiterhin aus einem skalierbaren Ressourcenpool bereitgestellt und zentral betrieben werden.

„Wir sind zu klein für C5.“ Die Definition des Cloudanbieters kennt keine Mindestmitarbeiterzahl. Ob ein Testat wirtschaftlich sinnvoll oder gefordert ist, steht auf einem anderen Blatt.

„Der Hyperscaler ist C5-testiert, damit sind wir abgedeckt.“ Sein Bericht kann einen Teil Ihrer Lieferkette abdecken. Ihr SaaS-Dienst, Ihre Anwendung und Ihre Kontrollen werden dadurch nicht automatisch testiert.

Interesse geweckt?

Sie betreiben SaaS und möchten Ihre Cloudanbieterrolle, den passenden Scope und die C5-Anforderungen sauber einordnen? Sprechen Sie mit uns. Wir helfen Ihnen, aus Produktarchitektur und Betriebsmodell eine belastbare Entscheidungsgrundlage zu machen.