C5-Testat als SaaS-Anbieter: was auch mit kleinem Team prüffähig ist

Diese Seite richtet sich an Anbieter von Software als Dienst (SaaS), die ein C5-Testat planen, auch mit wenigen Beschäftigten. Wie man den Prüfungsgegenstand allgemein zuschneidet und was das Testat einer Hyperscaler-Plattform abdeckt, steht auf der Seite C5-Scope. Für KI-Dienste gibt es die Seite C5 für KI-SaaS, für Hersteller von Praxissoftware die Seite Praxissoftware-Anbieter.

Was ein SaaS-Anbieter im C5 selbst verantwortet

Alles, was er selbst baut, betreibt und entscheidet. Der Katalog geht bei Cloud-Diensten von geteilten Zuständigkeiten zwischen Anbieter, Subdienstleistern und Kunden aus und nennt als Beispiele einen SaaS-Dienst auf einer IaaS-Plattform und das Identitäts- und Zugriffsmanagement für das Personal des Kunden (Abschnitt 3.4.4). Software auf der Infrastruktur oder Plattform eines anderen Cloud-Anbieters gilt nach Abschnitt 3.4.6 in der Regel als Subdienstleister-Beziehung.

Kriterien, die nur für IaaS gelten, kann ein SaaS-Anbieter mit Begründung ausschließen; die Begründung muss sich auf Art und Ausgestaltung des Dienstes oder auf seine Grundsätze, Verfahren und Maßnahmen stützen, nie darauf, dass Kontrollen fehlen (Abschnitt 3.4.3). Die meisten Kriterien bleiben anwendbar, weil sie Organisation, Personal, Entwicklung und Betrieb betreffen.

Das Beispiel: Vertragsmanagement mit neun Beschäftigten

Fiktives Beispiel, kein Kunde. Ein Anbieter betreibt eine Software zur Verwaltung von Verträgen und Fristen für mittelständische Unternehmen. Ein Konzern verlangt in einer Ausschreibung einen C5-Typ-2-Bericht. Die Ausgangslage:

• Team: neun Beschäftigte, davon fünf in der Entwicklung, zwei in Betrieb und Support, zwei in Geschäftsführung und Vertrieb; dazu zwei freie Entwickler.
• Plattform: verwalteter Container-Dienst, verwaltete Datenbank und Objektspeicher eines Hyperscalers in einer Region in Deutschland.
• Werkzeuge als SaaS: Code-Hosting mit Build- und Bereitstellungskette (CI/CD), Fehlertracking, Identitätsanbieter für die Anmeldung der Beschäftigten, Ticketsystem für den Support.
• Dokumentation: wenige schriftliche Richtlinien, aber Infrastruktur als Code und vollständige Historie aller Änderungen im Code-Hosting.

Entscheidung 1: Welche Werkzeuge sind Subdienstleister?

Subdienstleister ist ein Dienstleister nach Abschnitt 3.4.6 nur, wenn zwei Merkmale zusammen vorliegen: Seine Leistung ist für Kunden relevant (Merkmal 1), und Kontrollen bei ihm sind zusammen mit den eigenen nötig, um Kriterien zu erfüllen (Merkmal 2); wie Sie das je Eintrag prüfen, zeigt die Seite Subdienstleisterinventar. Für SaaS-Anbieter stellt sich die Frage vor allem bei den eigenen Werkzeugen. Unabhängig vom Ergebnis gehören alle Service-Organisationen, die zur Erbringung des Dienstes beitragen, in das Verzeichnis nach SSO-04.

Die Einstufung stimmen Sie mit dem Prüfer ab. Lohnend ist die Frage, ob ein Datenfluss überhaupt nötig ist: Wer verhindert, dass Kundendaten in ein Werkzeug gelangen, spart sich die Subdienstleister-Angaben, braucht dafür aber einen Nachweis, dass die Sperre wirkt.

Entscheidung 2: Aufgabentrennung, wenn wenige Personen alles machen

OIS-04 verlangt, miteinander in Konflikt stehende Aufgaben auf Basis einer Risikobeurteilung zu trennen, etwa Entwicklung, Test und Freigabe von Änderungen oder die Verwaltung des Rechterahmens. Für kleine Anbieter wichtig ist OIS-04.03B: Kann die Funktionstrennung aus organisatorischen oder technischen Gründen nicht umgesetzt werden, richtet der Anbieter kompensierende Kontrollen ein, die unbefugte oder unbeabsichtigte Änderungen erkennen und eine zeitnahe Reaktion ermöglichen. Dazu kommt ein Verzeichnis der Konflikte und der Maßnahmen, die sie auflösen (OIS-04.04B). Hilfreich ist DEV-10.01B: Änderungen genehmigt „autorisiertes Personal oder autorisierte Systemkomponenten“, eine automatische Freigabe auf Basis definierter Kriterien ist also möglich.

So kann eine kompensierende Kontrolle im Beispiel aussehen (eigene Beispiel-Kontrollbeschreibung):

Entscheidung 3: Interne Audits ohne eigene Revision

COM-03 verlangt mindestens jährlich interne Audits durch sachverständiges Personal, das nicht in der Weisungslinie des geprüften Bereichs steht (COM-03.02B). Lässt die Größe des Anbieters das nicht zu, setzt er alternative Maßnahmen um, damit die Prüfungen unparteiisch bleiben. Als sachverständiges Personal nennen die ergänzenden Informationen zu COM-03.01B auch beauftragte fachkundige Dritte; ein externer Auditor ist deshalb ein naheliegender Weg. Im Beispiel übernimmt ein externer Auditor das jährliche interne Audit. Er sollte nach unserer Empfehlung nicht derselbe sein, der später das C5-Testat erteilt, weil er sonst seine eigene Vorarbeit prüfen würde; ob das mit seiner Unabhängigkeit vereinbar wäre, beurteilt der Prüfer selbst (siehe Prüferauswahl).

Entscheidung 4: Freie Entwickler

Im Beispiel arbeiten die beiden freien Entwickler in den Prozessen des Anbieters mit: im selben Code-Hosting, mit denselben Freigaberegeln. Das ist nach den ergänzenden Informationen zu DEV-02 keine ausgelagerte Entwicklung; der Katalog nimmt die „Integration externen Personals in die Prozesse des Cloud-Anbieters“ ausdrücklich aus. Für die beiden gelten die eigenen Kontrollen des Anbieters, etwa zu Personal und Zugängen, dazu die Kontrolle aus Entscheidung 2.

DEV-02 greift erst, wenn ein Dienstleister Komponenten des Dienstes nach seinen eigenen Prozessen entwickelt, etwa eine Agentur, die ein Modul in ihrer eigenen Umgebung baut und liefert. Dann sind vertraglich festzulegen: sichere Entwicklung auf dem Niveau der eigenen, Abnahmeprüfung und Nachweise, dass bekannte Schwachstellen ausgeschlossen wurden (DEV-02.01B). Vorher steht eine Risikobeurteilung, unter anderem zu Quellcodeverwaltung, Zugängen zu Entwicklungs- und Testumgebungen und Unterauftragnehmern (DEV-02.02B). Wer in diesem Fall das Zusatzkriterium DEV-02.02AC aufnimmt, lässt Änderungen aus ausgelagerter Entwicklung zusätzlich von eigenem Personal testen. Siehe auch Themengebiet Entwicklung (DEV).

Prüfung einer Erklärung oder direkte Prüfung?

Der Katalog nennt die direkte Prüfung besonders geeignet für Anbieter, deren Kontrollsystem noch nicht ausreichend dokumentiert ist; der Prüfer nimmt das System dann selbst auf, eine Systembeschreibung des Anbieters entfällt (Abschnitt 3.4.4.2). Für ein kleines Team klingt das bequem. Nach unserer Einschätzung spart es aber weniger, als es scheint: Richtlinien nach SP-01, Risikobeurteilung und Nachweise brauchen Sie in beiden Fällen, und der Prüfer braucht für die Aufnahme Zeit Ihrer Fachleute. Im Beispiel entscheidet sich der Anbieter für die Prüfung einer Erklärung, weil der ausschreibende Konzern eine Systembeschreibung lesen will. Wie beide Prüfungsarten ablaufen, zeigt die Seite C5-Prüfung.

Nachweise aus den Werkzeugen statt aus Dokumenten

Ein kleines Team gewinnt Zeit, wenn Nachweise dort entstehen, wo ohnehin gearbeitet wird. Die folgende Liste gilt für das Beispiel; jeder Nachweis steht mit Herkunft, Verantwortlichem und Zeitbezug in einem Nachweisregister.

Mögliche Lücken bei kleinen SaaS-Anbietern

• Werkzeuge fehlen im Dienstleisterverzeichnis. Ursache: Sie wurden von der Entwicklung per Kreditkarte gebucht. Wirkung: Datenflüsse und Subdienstleister fehlen in der Systembeschreibung. Abhilfe: Abrechnungen der letzten zwölf Monate durchsehen und jedes Werkzeug einordnen.
• Funktionstrennung nur auf dem Papier. Ursache: Alle haben Administratorrechte „für den Notfall“. Wirkung: Die kompensierende Kontrolle greift nicht, weil sich Bereitstellungen außerhalb der Kette nicht erkennen lassen. Abhilfe: Notfallzugang einrichten, Dauerrechte entziehen, Nutzung protokollieren.
• Richtlinien ohne Freigabe und Version. Ursache: Regeln stehen in einem Wiki ohne Versionsstand. Wirkung: SP-01 verlangt Versionskontrolle und Genehmigung durch die oberste Leitung oder eine autorisierte Stelle. Abhilfe: Richtlinien im Code-Hosting versionieren und Freigaben dort dokumentieren.