SaaS-Sicherheit nach DORA

Der Digital Operational Resilience Act (Verordnung (EU) 2022/2554) ist ein einheitliches Regelwerk für die digitale operationelle Resilienz des EU-Finanzsektors. Er gilt seit dem 17. Januar 2025 unmittelbar in allen Mitgliedstaaten. Er erfasst Banken, Versicherer, Wertpapierfirmen, Zahlungs- und E-Geld-Institute sowie weitere Finanzunternehmen.

Die Verordnung ruht auf fünf Säulen: ICT-Risikomanagement, Management und Meldung von ICT-Vorfällen, Tests der digitalen operationellen Resilienz, Management des ICT-Drittparteienrisikos und Informationsaustausch. SaaS fällt vor allem unter die Säule des ICT-Drittparteienrisikos.

Nahezu jede SaaS-Anwendung, die ein Finanzunternehmen nutzt, etwa Collaboration-Suiten, CRM, HR, Analytics oder Dokumentenmanagement, ist eine ICT-Leistung eines Dritten. Damit wird der Vertrag zu einer ICT-Drittvereinbarung nach dem DORA-Kapitel zum Drittrisiko.

Anbieter, die als kritische ICT-Drittdienstleister gelten, werden zusätzlich direkt von den Europäischen Aufsichtsbehörden beaufsichtigt. Diese Aufsicht verlagert die Verantwortung jedoch nicht: Gegenüber der eigenen Aufsicht ist das Finanzunternehmen für die Resilienz der Funktionen verantwortlich, die das SaaS trägt.

DORA verlangt von jedem Finanzunternehmen ein Informationsregister über alle ICT-Drittvereinbarungen. Jeder SaaS-Vertrag gehört hinein. Das Register erfasst die Identität des Anbieters, die Leistungen, ob sie kritische oder wichtige Funktionen unterstützen, die Kette der Unterauftragnehmer, die Datenstandorte und die Kündigungsrechte.

Die zuständigen Behörden erhalten das Register und berichten den Europäischen Aufsichtsbehörden darüber. Unvollständige SaaS-Einträge fallen daher in der Aufsichtsprüfung auf und bleiben nicht als interne Lücke bestehen. Ein genaues IT-Asset-Register ist der praktische Ausgangspunkt.

Die Bewertung ist eine Pflicht über den gesamten Lebenszyklus, keine Formalität beim Einkauf. Vor der Nutzung eines SaaS-Dienstes muss das Unternehmen die technische Leistungsfähigkeit des Anbieters, seine Sicherheitspraktiken, die Qualität des Supports und seine finanzielle Stabilität prüfen und bei veränderten Umständen wiederholen.

Konzentrationsrisiken erhalten besondere Aufmerksamkeit. Wenn viele Unternehmen von denselben wenigen SaaS-Plattformen abhängen, wird der Ausfall eines Anbieters zum sektorweiten Ereignis. Deshalb dokumentiert das Register auch, wie gut sich jeder Dienst tatsächlich ersetzen lässt.

DORA legt einen Mindestinhalt für ICT-Verträge fest. In der Praxis muss eine SaaS-Vereinbarung mindestens diese Regelungen enthalten:

DORA vereinheitlicht die Klassifizierung und Meldung schwerwiegender ICT-bezogener Vorfälle. Ein Vorfall, der bei einem SaaS-Anbieter beginnt, bleibt ein Vorfall des Unternehmens. Es muss erkennen, dass eine Abhängigkeit beeinträchtigt ist, und die Auswirkungen auf die eigenen Funktionen bewerten.

Nicht jeder schwerwiegende Vorfall ist eine Datenschutzverletzung. Auch der Ausfall eines Anbieters, der einen kritischen Dienst stoppt, kann meldepflichtig sein. Erst-, Zwischen- und Abschlussberichte müssen fristgerecht geliefert werden, und dafür muss man vorab wissen, welche Funktionen auf welchen Diensten beruhen.

Resilienztests müssen die Drittdimension einbeziehen. Testprogramme, bei bedeutenden Unternehmen auch Threat-led-Penetrationstests (TLPT) für die von der Behörde benannten Einheiten, sollen Szenarien berücksichtigen, in denen ein SaaS-Dienst nicht verfügbar, beeinträchtigt oder kompromittiert ist. Sie müssen prüfen, ob Wiederherstellung und Exit-Strategien unter Belastung halten, und nicht nur, ob sie auf dem Papier existieren.

Nicht jede Pflicht trifft jeden Dienst gleich. Solche Pflichten werden meist im Rahmen eines Compliance-Managements gesteuert, der Status unten hängt vom Anwendungsbereich ab.

Keine einzelne Kontrolle deckt das gesamte SaaS-Bild ab. Die Vertragsprüfung kontrolliert die Papiere, während Inventar und Aktivitätsprotokolle zeigen, was tatsächlich genutzt wird. Ohne Freigabe eingeführte Dienste, der Kern von Shadow IT, liegen in der Lücke dazwischen.

Die Verordnung legt die Pflichten fest, die Praxis beginnt aber damit zu wissen, welches SaaS die Organisation tatsächlich einsetzt. Dienste, die einzelne Teams nutzen, gelangen nie ins Register und werden nie bewertet, transportieren aber dieselben Datenflüsse wie genehmigte Dienste.

Keine der folgenden Kontrollen wird in der Verordnung namentlich genannt. Ohne sie lassen sich die genannten Pflichten in der Praxis jedoch kaum erfüllen. Dafür zu sorgen, welche Daten zu welchem Dienst gelangen dürfen, ist Aufgabe der Data Loss Prevention.

1. 1

   Mit dem Inventar beginnen

   Jede genutzte SaaS-Anwendung erfassen, auch solche, die Mitarbeitende selbst einführen.

2. 2

   Daten klassifizieren

   Festlegen, welche Daten zu welchem Dienst gelangen dürfen.

3. 3

   Eingangskanäle abdecken

   Data Loss Prevention auf Browser-Uploads, Synchronisationsclients und E-Mail anwenden, damit regulierte Daten nur zu Diensten im Register gelangen.

4. 4

   Nutzeraktivität protokollieren

   Eine Nachweisspur in und um SaaS-Anwendungen führen, für die Vorfallklassifizierung und Aufsichtsfragen.

Beginnen Sie bei den Daten, deren Offenlegung den größten Schaden anrichten würde, und kartieren Sie dann die Dienste, die sie erhalten können. Eine Richtlinie zur Datenklassifizierung gibt jedem Vertrag und jeder Kontrolle denselben Bezugspunkt.

Weiterlesen: Das Konzept von „Zero Trust“.