Der C5-Scope: Was wird eigentlich testiert?

„Wir haben C5.“

„Für welchen Cloud-Dienst?“

„Für uns. Also für das Unternehmen.“

Das ist eine Antwort, die ungefähr so präzise ist wie: „Unser Auto hat TÜV.“ Welches Auto? In welchem Zustand? Wann geprüft? Und warum soll das etwas über die übrigen vier Fahrzeuge auf dem Hof sagen?

Bei C5 wird nicht pauschal „das Unternehmen“ mit einem großen Sicherheitshaken versehen. Gegenstand des Auftrags ist ein bestimmter Cloud-Dienst mit einem beschriebenen dienstbezogenen internen Kontrollsystem. Dazu gehören konkrete Systemgrenzen, Organisationseinheiten, technische Komponenten, Standorte, Subdienstleister, Kontrollen und ein bestimmter Zeitbezug.

Der C5-Scope ist deshalb keine einzelne Zeile. Er ist ein Ebenenmodell. Wer nur auf das Logo oder die erste Seite eines Prüfberichts schaut, sieht davon herzlich wenig.

Die kurze Antwort

Ein C5-Testat bezieht sich auf die Systembeschreibung und das darin dargestellte interne Kontrollsystem, das für Entwicklung und Betrieb eines konkret abgegrenzten Cloud-Dienstes relevant ist. Bei einer Typ-1-Prüfung wird dieser Gegenstand zu einem Stichtag betrachtet. Bei Typ 2 kommt die Wirksamkeit der Kontrollen während eines festgelegten Zeitraums hinzu.

Zum C5-Scope gehören mindestens diese Ebenen:

1. der bezeichnete Cloud-Dienst,
2. seine Funktionen, Varianten und Betriebsregionen,
3. die beteiligten Organisationseinheiten, Systeme und Standorte,
4. die angewendeten C5-Kriterien,
5. einbezogene oder ausgeklammerte Subdienstleister,
6. die beim Kunden vorausgesetzten Kontrollen,
7. Berichtstyp, Stichtag oder Zeitraum und verwendete C5-Version.

Der aktuelle fachliche Ausgangspunkt ist der C5:2026-Kriterienkatalog des BSI. Er macht deutlich: Prüfungsgegenstand ist nicht das abstrakte Sicherheitsgefühl rund um einen Anbieter, sondern dessen beschriebenes dienstbezogenes Kontrollsystem.

Damit das nicht in der Theorie hängen bleibt, begleiten wir jetzt einen frei erfundenen Dienst durch alle sieben Ebenen: MediSozial Cloud. Die SaaS-Lösung unterstützt ambulante Pflegedienste und soziale Leistungserbringer bei Klientendaten, Pflege- und Leistungsdokumentation, Diagnosen, Medikamentenplänen, Tourenplanung und Abrechnung. Im Dienst werden damit Gesundheitsdaten und – je nach Einsatz – Sozialdaten verarbeitet. Und damit fällt der Dienst unter die C5-Pflicht.

Ebene 1: Welcher Cloud-Dienst steht im Bericht?

Am Anfang steht die banal klingende Frage: Was ist eigentlich der Cloud-Dienst?

Ein Anbieter kann mehrere SaaS-Produkte betreiben, die sich zentrale Komponenten wie Identitätsmanagement, Monitoring und Rechenzentren teilen. Trotzdem müssen nicht alle im selben C5-Scope liegen.

Die Systembeschreibung soll Name, Art und Umfang der erfassten Cloud-Dienste erkennen lassen. Ein Produktname allein genügt dafür nicht. Unter demselben Namen können verschiedene Leistungsstufen oder Betriebsmodelle verkauft werden.

Ein sinnvoller Scope beantwortet deshalb Fragen wie:

• Welche Funktionen stellt der Dienst bereit?
• Welche Tarif- oder Betriebsvarianten gehören dazu?
• Werden mandantenfähige und dedizierte Umgebungen gleichermaßen erfasst?
• Sind Zusatzmodule, Schnittstellen und Administrationsportale eingeschlossen?
• Gehört nur der laufende Betrieb dazu oder auch die Entwicklung des Dienstes?

C5 betrachtet ausdrücklich das Kontrollsystem für Entwicklung und Betrieb. Das ist wichtig. Die Produktionsplattform kann ordentlich geschützt sein, während Quellcode, Build-Umgebung und Release-Prozess in einer ganz anderen organisatorischen Ecke liegen. Sind diese Tätigkeiten für den betrachteten Dienst relevant, gehören sie nicht einfach hinter den Vorhang.

MediSozial Cloud im Beispiel: Erfasst wird die kostenpflichtige SaaS-Lösung MediSozial Care EU mit Webanwendung, mobiler Pflege-App und API. Das separat verkaufte Statistikmodul und eine kostenlose Angehörigen-App gehören nicht dazu.

Wie ein Anbieter überhaupt zu einem belastbaren Bericht gelangt, beschreiben wir im Praxisartikel Wie bekommt man ein C5-Testat?.

Ebene 2: Wo verlaufen die Systemgrenzen?

Nach dem Dienst kommt das System dahinter. Dazu können beispielsweise gehören:

• Anwendungen und Plattformkomponenten,
• Datenbanken und Speicherdienste,
• Netzwerk- und Sicherheitskomponenten,
• Entwicklungs-, Test- und Produktionsumgebungen,
• Identitäts- und Berechtigungssysteme,
• Protokollierung, Monitoring und Alarmierung,
• Backup- und Wiederherstellungsverfahren,
• Ticketsysteme und andere betriebliche Werkzeuge,
• Mitarbeiter, Rollen und Organisationseinheiten,
• physische Standorte und Rechenzentren.

Nicht jedes unternehmensweit genutzte System liegt deshalb automatisch vollständig im Scope. Ein zentrales Identitätsmanagement kann zum Beispiel mehrere Produkte versorgen. Für den C5-Bericht ist dann relevant, welche Teile und Kontrollen dieses Systems den betrachteten Cloud-Dienst unterstützen.

Hier hilft die Denkweise aus einem Informationssicherheitsmanagementsystem nach ISO 27001: Grenzen müssen nachvollziehbar sein, Schnittstellen dürfen nicht verschwinden und Abhängigkeiten gehören benannt. C5 und ISO 27001 sind trotzdem keine austauschbaren Etiketten. Die Unterschiede erklären wir in C5 und ISO 27001 im Vergleich.

MediSozial Cloud im Beispiel: Zum System gehören Produktivplattform, Datenbanken, IAM, Logging, Backup, Entwicklungsumgebung, Quellcodeverwaltung und Build-Pipeline. Die öffentliche Marketingwebsite und das interne Bewerbermanagement sind für Entwicklung und Betrieb des Dienstes nicht relevant und bleiben draußen.

Ebene 3: Welche Varianten, Regionen und Standorte gehören dazu?

Ein Cloud-Dienst kann in Frankfurt, Dublin und Virginia mit unterschiedlichen Rechenzentren, Unterauftragnehmern oder technischen Komponenten betrieben werden. Ein einheitlicher Markenname macht diese Unterschiede nicht ungeschehen.

Deshalb sollte ein C5-Bericht erkennen lassen:

• welche geografischen Regionen erfasst sind,
• welche Rechenzentrumsstandorte beteiligt sind,
• ob die Architektur überall gleich ist,
• welche Datenverarbeitung und Administration von wo erfolgt,
• ob bestimmte Kundenvarianten außerhalb des Scopes liegen.

Problematisch wird es, wenn Vertrieb oder Einkauf aus einer begrenzten Prüfung eine grenzenlose Werbeaussage basteln.

MediSozial Cloud im Beispiel: Der Bericht erfasst die EU-Umgebung in Frankfurt und Dublin. Eine technisch ähnliche Schweizer Umgebung wird separat betrieben und ist nicht enthalten. Ein Schweizer Kunde darf aus dem EU-Bericht deshalb keinen Nachweis für seine eigene Umgebung basteln.

Ebene 4: Welche C5-Kriterien werden angewendet?

Die Basiskriterien bilden den Mindestumfang einer C5-Prüfung. Darüber hinaus kann der Anbieter zusätzliche Kriterien oder einzelne zusätzliche Unterkriterien aufnehmen.

Bestimmte Kriterien dürfen als nicht anwendbar ausgeschlossen werden. Dafür braucht es aber eine nachvollziehbare Begründung in der Systembeschreibung. Nicht anwendbar bedeutet: Das Kriterium passt aufgrund der Art des Dienstes oder der eingesetzten Verfahren tatsächlich nicht. Es bedeutet nicht: Die Kontrolle funktioniert nicht, der Nachweis fehlt oder der Anbieter möchte darüber lieber nicht sprechen.

Diese Unterscheidung ist enorm wichtig:

• Nicht anwendbar: Der Sachverhalt existiert beim beschriebenen Dienst begründet nicht.
• Anwendbar, aber abweichend: Das Kriterium betrifft den Dienst, die Kontrolle ist jedoch nicht angemessen oder nicht wirksam.
• Zusätzlich aufgenommen: Über den Mindestumfang hinaus wird ein weiterer Prüfungsgegenstand vereinbart.

Ein Kriterienverzeichnis ist also Teil der Scope-Lektüre. Wer nur fragt, ob irgendwo C5 draufsteht, übersieht, was tatsächlich einbezogen, ergänzt oder begründet ausgeschlossen wurde.

MediSozial Cloud im Beispiel: Die Basiskriterien werden vollständig angewendet. Ein zusätzlich vereinbartes Unterkriterium betrachtet ausführlicher den Schutz der besonders sensiblen Pflege- und Medikationsdaten. Ein Kriterium wird nur dann ausgeschlossen, wenn der betreffende Sachverhalt beim Dienst tatsächlich nicht vorkommt.

Ebene 5: Was passiert mit Subdienstleistern?

Cloud-Dienste stehen selten auf einem einsamen Server im eigenen Keller. Infrastruktur, Rechenzentren, DDoS-Schutz, E-Mail-Versand oder Identitätsdienste kommen häufig von Dritten.

C5 unterscheidet im Kern zwei Darstellungsweisen:

• Einbeziehungsmethode: Die relevanten Kontrollen des Subdienstleisters werden in die Systembeschreibung und den Prüfungsgegenstand einbezogen.
• Ausgliederungsmethode: Die Leistungen und benötigten Kontrollen des Subdienstleisters werden beschrieben, seine eigenen Kontrollen werden aber nicht in diesem Auftrag geprüft.

Auch bei der Ausgliederungsmethode bleibt der Cloud-Anbieter verantwortlich. Er muss die Abhängigkeit verstehen, Anforderungen festlegen und den Subdienstleister angemessen steuern und überwachen.

Aber: Der C5-Prüfer testiert im betreffenden Auftrag nicht automatisch die internen Kontrollen des ausgegliederten Unternehmens. Ein bekannter Infrastrukturbetreiber unter dem eigenen SaaS macht dessen gesamte Technik nicht stillschweigend zum Bestandteil des SaaS-Berichts.

MediSozial Cloud im Beispiel: Die Plattform läuft bei einem IaaS-Anbieter; Benachrichtigungen werden über einen weiteren Dienst verschickt. Beide werden über die Ausgliederungsmethode behandelt. Ihre Leistungen, Schnittstellen und benötigten Kontrollen werden beschrieben, ihre internen Kontrollen aber nicht in diesem Auftrag mitgeprüft.

Für die praktische Steuerung solcher Abhängigkeiten helfen unsere Artikel zur sicheren Auswahl und Steuerung von Cloud-Diensten, zur Überwachung von Lieferanten und zur Sicherheit in der IKT-Lieferkette.

Ebene 6: Was muss der Cloud-Kunde selbst tun?

Ein C5-Bericht kann korrespondierende Kontrollen beim Cloud-Kunden beschreiben. Das sind Maßnahmen, die der Kunde selbst einrichten muss, damit die Sicherheitsziele im Zusammenspiel erreicht werden.

Typische Beispiele können sein:

• der Kunde verwaltet seine Benutzer und Berechtigungen sauber,
• er aktiviert und konfiguriert Mehrfaktor-Authentisierung,
• er bewertet Meldungen und Sicherheitsinformationen des Anbieters,
• er richtet Schnittstellen und Verschlüsselungsoptionen korrekt ein,
• er schützt eigene Endgeräte, Konten und Zugangsdaten,
• er hält vertraglich vereinbarte Ansprechpartner aktuell.

Diese Kundenkontrollen werden im C5-Auftrag des Anbieters nicht beim Kunden geprüft. Der Bericht kann also sagen: Der Anbieter hat seinen Teil eingerichtet – unter der Annahme, dass der Kunde seinen Teil ebenfalls erledigt.

Das ist für Einkäufer einer der nützlichsten Teile des Berichts. Ein C5-Testat ist kein Freifahrtschein zum sicheren Nichtstun. Wer einen Dienst auswählt, sollte die genannten Kundenkontrollen in die eigene Einführung und den späteren Betrieb übernehmen.

MediSozial Cloud im Beispiel: Der Pflegedienst muss Benutzer sorgfältig anlegen und sperren, Rollen passend vergeben, MFA aktivieren und die eingesetzten Smartphones absichern. Ob er das wirklich tut, prüft der C5-Prüfer des Cloud-Anbieters nicht. Ein bisschen Eigenverantwortlichkeit des Cloud-Kunden ist also auch noch da.

Ebene 7: Typ, Zeitraum und Version

Auch die Zeit gehört zum Scope.

Bei Typ 1 wird das Kontrollsystem zu einem Stichtag betrachtet. Bei Typ 2 wird zusätzlich beurteilt, ob die Kontrollen während eines bestimmten Zeitraums wirksam waren. Ein Bericht aus dem vergangenen Jahr erzählt nicht automatisch, was heute gilt. Und ein Typ-1-Bericht belegt keine über Monate nachgewiesene Wirksamkeit.

Hinzu kommt die verwendete Katalogversion. Ein sauberer Vergleich berücksichtigt deshalb:

• C5-Version,
• Berichtstyp,
• Stichtag oder Prüfungszeitraum,
• wesentliche Änderungen während oder nach der Prüfung.

Die Unterschiede zwischen den Berichtstypen behandeln wir ausführlich unter C5 Typ 1 oder Typ 2.

MediSozial Cloud im Beispiel: Grundlage ist C5:2026. Der Typ-2-Bericht betrachtet den Zeitraum vom 1. Januar bis 31. Dezember 2027. Eine neue Funktion, die erst im Februar 2028 produktiv geht, kann davon noch nicht erfasst sein.

Der C5-Scope auf einen Blick

So könnte der Scope im Beispiel aussehen

Aus den sieben Entscheidungen lässt sich nun eine brauchbare Kurzbeschreibung bauen:

„Gegenstand des C5-Auftrags ist die in den EU-Regionen Frankfurt und Dublin betriebene SaaS-Lösung MediSozial Care EU einschließlich Webanwendung, mobiler Pflege-App und API sowie der für Entwicklung und Betrieb relevanten Systeme, Prozesse und Organisationseinheiten. Das Statistikmodul, die Angehörigen-App und die Schweizer Betriebsumgebung sind nicht erfasst. Die Leistungen des IaaS- und des Benachrichtigungsanbieters werden nach der Ausgliederungsmethode behandelt. Der Typ-2-Bericht nach C5:2026 bezieht sich auf den Zeitraum vom 1. Januar bis 31. Dezember 2027.“

Das ist noch keine vollständige Systembeschreibung. Es ist aber ein belastbarer Ausgangspunkt. Ein echter Scope muss zu Architektur, Verträgen und tatsächlicher Leistungserbringung passen; unser Beispiel lässt sich jetzt jetzt natürlich nicht per copy&paste auf Ihren Cloud-Dienst kleben. Aber Sie kennen jetzt den Algorithmus, um die Beschreibung Ihres C5-Diensts herleiten zu können.

So lesen Kunden den Scope richtig

Wer einen C5-Bericht zur Lieferantenbewertung erhält, sollte nicht bei der Prüfungsmeinung stehen bleiben. Prüfen Sie mindestens:

1. Passt der bezeichnete Cloud-Dienst genau zu der Leistung, die wir kaufen?
2. Sind unsere Region, Betriebsvariante und benötigten Module enthalten?
3. Welche wesentlichen Subdienstleister wirken mit und wie wurden sie behandelt?
4. Welche Kundenkontrollen müssen wir selbst umsetzen?
5. Welche Kriterien wurden ausgeschlossen oder zusätzlich aufgenommen?
6. Handelt es sich um Typ 1 oder Typ 2?
7. Welcher Zeitraum und welche C5-Version gelten?
8. Welche Abweichungen und wesentlichen Änderungen nennt der Bericht?

Erst dann lässt sich beurteilen, welchen Nachweiswert der Bericht für den eigenen Anwendungsfall hat. Ob ein Unternehmen im Gesundheitswesen einen C5-Nachweis benötigt, ist wiederum eine andere Frage. Diese behandeln wir gesondert im Artikel C5-Pflicht nach § 393 SGB V.

Typische Fehler bei Aussagen zum C5-Scope

• „Unser Unternehmen ist C5-zertifiziert.“ C5 führt zu einem Prüfbericht für einen beschriebenen Gegenstand, nicht zu einer pauschalen Unternehmenszertifizierung.
• „Das Produkt ist enthalten, der Name steht doch drin.“ Entscheidend sind auch Variante, Region, Systemgrenzen und Zeitraum.
• „Unser Infrastrukturbetreiber ist mitgeprüft.“ Das stimmt nur, wenn seine relevanten Kontrollen tatsächlich einbezogen wurden.
• „Der Kunde muss nichts mehr tun.“ Korrespondierende Kundenkontrollen können wesentliche Voraussetzungen sein.
• „Ein Kriterium fehlt, also wurde es nicht erfüllt.“ Es kann begründet nicht anwendbar sein. Die Begründung muss man lesen.
• „Der Bericht ist noch gültig.“ C5-Berichte haben nicht einfach eine plakative Zertifikatslaufzeit. Stichtag, Zeitraum und spätere Änderungen müssen bewertet werden.

Interesse geweckt?

Sie möchten den C5-Scope Ihres Cloud-Dienstes sauber abgrenzen oder einen vorgelegten C5-Bericht darauf prüfen, was er tatsächlich abdeckt? Sprechen Sie mit uns.