CRA für SaaS: Umfang, eigene Maßnahmen und Beweise

Auf die Frage „Fällt SaaS unter den CRA?“ gibt es allein auf Grundlage des Abonnementmodells keine verlässliche Antwort. Der CRA regelt Produkte mit digitalen Elementen. Cloud-Computing-Dienste — einschließlich SaaS — werden zugleich vom NIS2-Rahmen erfasst. Entscheidend ist, was das Produkt ist, welche Software auf dem Markt bereitgestellt wird und ob ein entfernter Dienst integraler Bestandteil einer Produktfunktion ist.

Beginnen Sie mit Architektur und Bereitstellungsmodell, nicht mit der Marketingbezeichnung.

Zwei Fragen, die häufig vermischt werden

Ist der Cloud-Dienst selbst ein Produkt mit digitalen Elementen nach dem CRA?

Nehmen Sie das nicht allein deshalb an, weil Nutzer über einen Browser auf Software zugreifen.

Ist der entfernte Dienst Teil eines anderen Produkts mit digitalen Elementen?

Das kann der Fall sein. Der CRA definiert eine „Datenfernverarbeitungslösung“ als Datenverarbeitung aus der Ferne, für die die Software vom Hersteller oder unter seiner Verantwortung konzipiert und entwickelt wird und deren Fehlen das Produkt mit digitalen Elementen daran hindern würde, eine seiner Funktionen auszuführen.

Die Erwägungsgründe des CRA nennen das Beispiel einer mobilen Anwendung, die Zugriff auf eine API oder Datenbank benötigt, die über einen vom Hersteller entwickelten Dienst bereitgestellt wird. In dieser Situation kann der Dienst als Datenfernverarbeitungslösung in den Produktumfang fallen.

Ordnen Sie die Architektur zu, bevor Sie über den Anwendungsbereich entscheiden

Beschreiben Sie bei einem SaaS-Angebot getrennt:

An den Kunden gelieferte Software — Agent, Desktop-/Mobilanwendung, Appliance, Plugin, Bibliothek;
Web-Frontend — worauf der Nutzer im Browser zugreift;
Backend/API — aus der Ferne ausgeführte Funktionen;
Datenbanken und Verarbeitung — welche entfernten Elemente für Produktfunktionen erforderlich sind;
Drittanbieterintegrationen — was in der Verantwortung des Herstellers liegt und was nicht;
Marktmodell — wer die Lösung bereitstellt und unter welcher Marke;
Updates — welche Elemente der Hersteller verändert und wie sie die Sicherheit beeinflussen;
Unterstützung — wie lange jede relevante Komponente gewartet wird.

Diese Zuordnung unterstützt sowohl die Bewertung des Anwendungsbereichs als auch die spätere technische Dokumentation.

Drei Beispielsituationen

A. Cloud-Dienst ausschließlich im Browser

Der Nutzer meldet sich über einen Browser bei einem Dienst an, ohne dass ein gesondertes Software-/Hardwareprodukt geliefert wird. Springen Sie nicht von „SaaS“ zu „CRA gilt“. Prüfen Sie die CRA-Definitionen und aktuellen Leitlinien der Kommission. Bewerten Sie außerdem getrennt die NIS2-Pflichten, soweit sie für die Organisation relevant sind.

B. Softwareprodukt mit einem vom Hersteller betriebenen Backend

Der Kunde erhält eine Anwendung oder Komponente, deren wichtige Funktion ohne ein vom Hersteller konzipiertes Backend nicht arbeiten kann. Die Datenfernverarbeitung kann für CRA-Zwecke Teil des Produkts sein.

C. Ein Produkt verwendet einen unabhängigen Cloud-Dienst

Wird der Dienst außerhalb der Verantwortung des Herstellers konzipiert und entwickelt, kann sich die Beziehung von der zu einem eigenen Backend unterscheiden. „Die Daten liegen in der Cloud“ beantwortet für sich genommen die CRA-Frage nicht.

Dies sind Beispiele zur Orientierung und keine rechtlichen Einstufungen einer konkreten Architektur.

Warum das jetzt operativ wichtig ist

Artikel 14 gilt seit dem 11. September 2026 und erstreckt sich auf Produkte im Anwendungsbereich, die vor dem 11. Dezember 2027 in Verkehr gebracht wurden.

Besteht ein Angebot aus Anwendung, Komponente und Backend, muss das Team für das betreffende Produkt und Release wissen:

wo Schwachstellenmeldungen eingehen;
wer die Ersteinschätzung durchführt;
wie Auswirkungen auf das Produkt bewertet werden;
wie Korrekturen veröffentlicht werden;
wie Nutzer informiert werden;
wann die Bewertung einer CRA-Meldung ausgelöst wird.

Ohne klare Produktgrenze ist es schwierig, T0, verantwortliche Zuständigkeit oder den Umfang einer Meldung festzulegen.

Was in einer SaaS-Entscheidung zum Anwendungsbereich festzuhalten ist

Diagramm der Produktgrenze;
lokal gelieferte Elemente;
aus der Ferne ausgeführte Elemente;
die von jedem Element bereitgestellte Funktion;
ob das Entfernen des entfernten Elements eine Produktfunktion verhindert;
Verantwortung für die Entwicklung des entfernten Elements;
Vertriebs- und Markenmodell;
Rolle der Organisation;
für die Bewertung verwendete Rechts-/Leitliniengrundlage;
Person, die das Ergebnis genehmigt;
nächster Prüftermin.

Funktionen zuordnen statt eine Cloud-Bezeichnung bewerten

Die folgende Methode ist eine praktische Empfehlung zur Vorbereitung einer Bewertung. Ermitteln Sie für jede für Nutzer sichtbare Funktion, welche Software sie ausführt, wo diese läuft und wer für Konzeption und Entwicklung verantwortlich ist. Ein Hostingvertrag beschreibt die Zuständigkeit für Infrastruktur. Er beschreibt nicht zwingend die Verantwortung für Anwendungscode. Ein Hersteller kann eigene Software auf fremder Infrastruktur betreiben. Diese beiden Beziehungen müssen getrennt dokumentiert werden, sonst führt die Bezeichnung des Hostingangebots zu einer falschen Schlussfolgerung.

Prüfen Sie anschließend die Wirkung eines Ausfalls jedes entfernten Elements. Verliert die ausgelieferte Anwendung eine Produktfunktion, nur eine optionale Erleichterung oder arbeitet sie unverändert wie vorgesehen? Halten Sie die Grundlage fest: Architekturbeschreibung, Schnittstellenspezifikation, Test oder bestätigtes Produktverhalten. Der Test stützt Tatsachen der Bewertung. Er ersetzt nicht die rechtliche Einstufung. Diese Tatsachen werden anhand der Verordnung und der aktuellen Leitlinien der Kommission eingeordnet. Eine technische Feststellung und ihre rechtliche Bewertung gehören zusammen, bleiben aber unterscheidbar.

Benennen Sie das konkrete Produkt, statt „unsere Plattform“ als einen unklaren Gegenstand zu prüfen. Ein Browserdienst, ein herunterladbarer Desktop-Agent und ein gesondert vermarktetes SDK können unterschiedliche Bewertungen benötigen. Das Vertriebspaket verdeckt solche Unterschiede möglicherweise. Werden alle drei unter einem Abonnement angeboten, legt dieses Abonnement ihre CRA-Einordnung trotzdem nicht fest. Bewahren Sie Beziehungen zwischen den Produktaufzeichnungen auf. Dadurch lässt sich eine Änderung eines Elements auch bei den verbundenen Produkten nachvollziehbar prüfen.

Hypothetisches Beispiel: Ein SaaS-Anbieter ergänzt einen Agenten

Ein hypothetischer Anbieter betreibt zunächst einen Berichtsservice im Browser. Später bietet er einen herunterladbaren Agenten an, der lokale Betriebsdaten erfasst und an ein vom Hersteller entwickeltes Backend übermittelt. Die Architektur hat sich geändert, auch wenn auf der Preisseite weiterhin „SaaS“ steht. Das Team muss den Agenten als Softwareprodukt untersuchen und seine Funktionen mit dem Backend in Beziehung setzen. Die frühere Bewertung des Browserdienstes lässt sich nicht ohne Prüfung auf das neue Angebot übertragen.

Erfassen Sie die Funktionen des Agenten: Datenerfassung, lokale Filterung, Authentifizierung, Übertragung sowie etwaige Anzeige- oder Steuerungsfunktionen. Prüfen Sie für jede Funktion, ob sie ohne das Hersteller-Backend arbeiten kann. Berücksichtigen Sie Updateverteilung und relevante entfernte Konfiguration in der Risikobewertung. Ein vorhandener Offline-Modus entscheidet die Frage nicht allein. Eine lokal ausführbare Funktion kann neben einer weiteren Funktion bestehen, die von Datenfernverarbeitung in der Verantwortung des Herstellers abhängt. Die konkrete Funktionsbeziehung muss deshalb sichtbar sein.

Das Ergebnis ist eine datierte Entscheidung mit bestätigten Tatsachen und offenen Fragen. Möglicherweise ist eine qualifizierte rechtliche Prüfung der Produktgrenze oder Rolle nötig. Gleichzeitig entstehen praktische Aufgaben: Schwachstellenkontakt für den Agenten, Release-Identifikation, sichere Updatebehandlung und Zuständigkeit für Nachweise, soweit einschlägig. Das ist kein behaupteter Kundenerfolg. Das Beispiel zeigt, wie eine geänderte Architektur zu einer erneuten Bewertung und nachvollziehbaren Folgeaufgaben führen soll. Benennen Sie für diese Aufgaben Verantwortliche und die betroffene Produktfassung.

Zuständigkeit für Drittanbieterdienste festhalten

Eine SaaS-Architektur nutzt häufig Identitätsdienste, Zahlungsdienste, Datenbanken, Nachrichtendienste und externe APIs. Beschreiben Sie, was der Hersteller entwickelt hat und was er lediglich verwendet. Eine für die Verfügbarkeit wichtige fremde Dienstleistung erfüllt dadurch nicht automatisch die CRA-Definition der Datenfernverarbeitung. Umgekehrt beseitigt ausgelagerte Infrastruktur nicht automatisch die Verantwortung für Software, die vom Hersteller oder unter seiner Verantwortung konzipiert und entwickelt wurde. Beides wäre eine unzulässige Verkürzung einer Prüfung, die konkrete Tatsachen braucht.

Führen Sie für wichtige Schnittstellen eine Zuständigkeitsaufzeichnung. Nennen Sie Dienst, unterstützte Produktfunktion, Vertragsparteien, Kontrolle über Anwendungsänderungen und Zugang zur Untersuchung eines Sicherheitsereignisses. Das ist eine empfohlene Methode zur Ermittlung von Tatsachen und kein zusätzlicher gesetzlicher Test. Ist eine Lieferantenbeziehung unklar, halten Sie die Unsicherheit fest und beschaffen Sie den Vertrag oder die Architekturangabe. Eine Einkaufsbezeichnung wie „Managed Service“ darf nicht ohne weitere Grundlage als abschließende Entscheidung über den Anwendungsbereich verwendet werden.

Sicherheitsarbeit bleibt auch dann notwendig, wenn ein Drittanbieterdienst für CRA-Zwecke außerhalb der Produktgrenze eingeordnet wird. Ein Ausfall oder eine Kompromittierung kann das Produkt weiterhin betreffen. Dokumentieren Sie diese Abhängigkeit in Risikobewertung und Betriebsplanung. Trennen Sie die rechtliche Grenze von der Gesamtheit technischer Risiken. Der Ausschluss aus einer bestimmten gesetzlichen Definition macht eine Abhängigkeit nicht ungefährlich. Die praktische Vorsorge muss daher die tatsächlichen Ausfall- und Angriffsszenarien betrachten und ihren Einfluss auf unterstützte Produktfunktionen beschreiben.

Release-Nachweise bei mehreren Mandanten pflegen

Ein entfernter Dienst kann häufig aktualisiert werden, während eine lokale Anwendung länger auf einer alten Fassung bleibt. Erfassen Sie, welche Kombinationen aus Anwendung, API und Konfiguration geprüft wurden. Ein einzelnes Feld „aktuelle Version“ kann unvereinbare oder unzureichend getestete Kombinationen verdecken. Release-Aufzeichnungen müssen unterstützte Kombinationen und dazugehörige Sicherheitsentscheidungen zeigen. Die angemessene Tiefe richtet sich nach Architektur und Änderungsgeschwindigkeit. Entscheidend ist, dass das Team bei einem Befund den geprüften Zustand wieder zuordnen kann.

Bei einem hypothetischen Dienst mit mehreren Mandanten kann ein Backendfehler alle Mandanten, nur einen Teil oder bestimmte Konfigurationen betreffen. Die zuständigen Personen für Meldung und Kommunikation benötigen diesen technischen Umfang. Die Zahl der Mandanten entspricht nicht automatisch der Zahl betroffener Nutzer. Ebenso darf nicht angenommen werden, dass jeder Kunde den neuesten Agenten installiert hat. Benennen Sie Informationsquelle und Bewertungszeitpunkt. Spätere Erkenntnisse können den Umfang verändern und müssen dann in die Fallchronologie aufgenommen werden.

Isolation, Zugriffskontrolle und Protokollierung benötigen eigene Risikobewertungen und Nachweise. Ein Compliance-Dokument beweist nicht, dass Mandantengrenzen funktionieren. Prüfen Sie das einschlägige Verhalten und verbinden Sie das Ergebnis mit der untersuchten Konfiguration. Enthalten Nachweise personenbezogene oder vertrauliche Informationen, wird der Zugriff auf den benötigten Personenkreis begrenzt. Diese Aussagen beschreiben empfohlene Entwicklungs- und Aufzeichnungsarbeit. Sie enthalten weder eine Sicherheitsgarantie für eine Plattform noch die Behauptung, dass ein bestandener Isolationstest sämtliche Produktanforderungen erfüllt.

CRA und organisatorische Pflichten getrennt beurteilen

Die Produktbewertung nach CRA und die Bewertung einer Einrichtung nach NIS2 stellen unterschiedliche Fragen. Ein Cloud-Anbieter benötigt gegebenenfalls eine organisatorische Prüfung anhand NIS2 und der einschlägigen nationalen Umsetzung. Ein Softwarehersteller kann daneben Produkte im CRA-Anwendungsbereich haben. Keine dieser Entscheidungen folgt durch bloßes Umbenennen aus der anderen. Halten Sie für jede Prüfung Rechtsgrundlage, Bewertungsgegenstand, Zuständigkeitsraum und verantwortliche Person fest. Damit wird deutlich, welche Aussage die jeweilige Entscheidung tatsächlich trägt und wo ihre Grenze liegt.

Vorhandene Sicherheitsverfahren dürfen wiederverwendet werden, wenn sie die jeweiligen Aufgaben tatsächlich unterstützen. Ein überwachter Sicherheitskontakt oder eine Chronologie kann beispielsweise Informationen für mehrere Bewertungen liefern. Meldekriterien, Empfänger und Fristen werden trotzdem für jede einschlägige Regelung geprüft. Die Vorbereitung eines CRA-Falls erfüllt nicht automatisch eine NIS2-Meldepflicht oder eine sektorspezifische Vorgabe. Bei einer gemeinsamen Fallakte müssen die Entscheidungen nach den einzelnen Rechtsgrundlagen klar unterscheidbar bleiben. Das vermeidet irreführende Freigaben nach dem Muster „Meldung erledigt“.

Diese Trennung verhindert zwei kostspielige Fehler. Einerseits können ohne ausreichende Grundlage sämtliche CRA-Produktanforderungen auf ein Angebot übertragen werden. Andererseits kann ein Ergebnis außerhalb des CRA-Anwendungsbereichs dazu führen, dass organisatorische oder vertragliche Sicherheitspflichten übersehen werden. Eine brauchbare Entscheidung nennt ihren Umfang: Gegenstand, Gesetz, Rolle und Annahmen. Sie darf nicht als allgemeine Aussage formuliert werden, das gesamte Unternehmen habe keine Cybersicherheitspflichten. Auch eine bewusst begrenzte Prüfung kann damit eine klare und belastbare Antwort liefern.

Änderungen dort prüfen, wo die Architektur entschieden wird

Wir empfehlen eine erneute Prüfung bei Änderungen von Produktfunktionen, ausgelieferter Software, Verantwortung für entfernte Verarbeitung, Vertrieb oder Unterstützungsannahmen. Verankern Sie diesen Schritt in Produktdesign und Release-Planung. Erfolgt er erst nach einer öffentlichen Ankündigung, können Entwicklungs- und Kundenzusagen bereits feststehen. Eine kurze frühe Bewertung benennt benötigte Informationen, bevor die Architektur nur noch mit erheblichem Aufwand geändert werden kann. Der Auslöser soll verständlich sein, damit Entwicklung und Produktmanagement ihn ohne Compliance-Fachwissen erkennen.

Die verantwortliche Person für die Änderung zeigt alte und geplante Produktgrenze. Sie benennt unveränderte und neue Tatsachen. Wird keine Änderung des Anwendungsbereichs angenommen, gehört die Begründung in die Aufzeichnung. Ein angekreuztes Feld „keine Auswirkungen“ genügt dafür nicht. Verbinden Sie Folgeaufgaben mit Zuständigkeit und Release. So entsteht eine überprüfbare Historie, ohne für jede kleine technische Anpassung ein vollständiges Rechtsgutachten zu verlangen. Die Prüfung richtet sich auf Tatsachen, die die bisherige Schlussfolgerung wirklich beeinflussen können.

Wählen Sie für die erste Übung ein tatsächliches Angebot und zeichnen Sie ausgelieferte Software, entfernte Verarbeitung und fremde Dienste auf einer Seite. Die Entwicklung bestätigt Funktionen und Verantwortung. Anschließend prüft die entscheidungsbefugte Person die Schlussfolgerung zum Anwendungsbereich. Das Ergebnis ist eine freigegebene Bewertung oder eine genau benannte offene Frage. Es ist keine automatische SaaS-Ausnahme und keine unbelegte Zusage, ein Browserdienst erfülle sämtliche CRA-Anforderungen. Diese klare Begrenzung macht die Aufzeichnung später für technische und rechtliche Änderungen nutzbar.

Wie Pulsar helfen kann

Pulsar kann die Entscheidung zum Anwendungsbereich und unterstützende Artefakte aufbewahren und das Ergebnis mit Risiken, Dokumenten, Maßnahmen, Anbietern und Nachweisen verbinden. Wenn sich die Architektur in einem späteren Release ändert, kann die Entscheidung erneut zur Prüfung vorgelegt werden, statt als veraltete PDF-Datei liegen zu bleiben.

Pulsar sollte ohne überprüfbare Grundlage und menschliche Genehmigung nicht selbstständig eine rechtlich endgültige Antwort „CRA gilt / gilt nicht“ liefern.

Pulsar GRC an einem Bewertungsablauf ansehen

Üben Sie eine Anforderung und ein überprüftes Ergebnis

Nutzen Sie ein fiktives Produkt bestehend aus einem Desktop-Client und einem vom Hersteller betriebenen Backend. Dies ist ein Beispiel für eine synthetische Architektur und keine Erklärung, dass jeder SaaS-Dienst unter CRA fällt. Erfassen Sie zunächst die Produktfunktion, die Rolle des Backends und die Frage, die einer qualifizierten Umfangsprüfung bedarf. Bewahren Sie die Rechtsquelle und den Überprüfungsbeschluss im Protokoll auf.

Sobald die Anwendbarkeitsannahmen des Beispiels explizit sind, wählen Sie eine relevante Anforderung und eine Aktion aus. Weisen Sie einen Eigentümer und ein Datum zu und legen Sie dann fest, welche Beweise das Ergebnis der Aktion belegen würden. Die Aktion kann beispielsweise eine Produktzugriffsregel überprüfen und die fiktive Testbeschreibung und das Ergebnis anhängen. Eine autorisierte Person prüft die Beweise anhand des angegebenen Kriteriums. Eine an die Aktion angehängte Datei schließt diese Überprüfung allein nicht ab.

Lesen Sie in Pulsar nach dem Speichern die Anforderung, die verknüpfte Aktion, die Quellversion und die Beweise noch einmal durch. Bitten Sie einen Kollegen, die nächste Verantwortung ohne Erklärung des Autors zu identifizieren. Das konkrete Testergebnis ist ein prüfbarer Teil der Produktarbeit. Es handelt sich nicht um eine automatische CRA-Klassifizierung, Konformitätsbewertung, CE-Erklärung oder Einreichung bei einer Behörde.

Pulsar bietet eine 14-tägige Testversion an, für die eine Zahlungsmethode erforderlich ist. Überprüfen Sie vor der Bestätigung den ausgewählten Plan, den Preis nach dem Test und die Stornierungsbedingungen. Verwenden Sie für diese Übung synthetische Datensätze. Eine echte Produktentscheidung erfordert eine eigene Architektur und eine qualifizierte Prüfung.