DORA-Umsetzung – Herausforderung: Abgrenzung kritischer Funktionen

1. Fehlende Leitlinie zur Abgrenzung kritischer/wichtiger Funktionen

Im Rahmen der Prüfungserfahrungen zur DORA-Implementierung wurde deutlich:
Es fehlt eine klare und nachvollziehbare Leitlinie zur Unterscheidung kritischer oder wichtiger Funktionen.
Ohne diese Grundlage lassen sich Funktionen, Prozesse, Verantwortlichkeiten und Sicherheitsanforderungen nicht sinnvoll als kritisch/ wichtig identifizieren, was alle folgenden Aktivitäten beeinträchtigt. Dies gilt für die Klassifizierung, die Beurteilung der Risiken sowie die Ableitung von Steuerungsmaßnahmen .

📌 Takeaway: Eine transparente und dokumentierte Funktionsklassifizierung ist der Schlüssel zu einem resilienten IKT-Risikomanagement.

2. Unklare Klassifizierung zur IT-Relevanz bei Dienstleistungsbezügen

Dienstleistungsbezug ≠ gleiches Risiko?

Eine weitere Erkenntnis der DORA-Prüfung:
Die IT-Relevanz einiger Dienstleistungen war nicht korrekt oder gar nicht als IKT-Dienstleistung zugeordnet – insbesondere bei „sonstigen Fremdbezügen“. Dieses Thema diskutieren wir just auch vielen Instituten im Rahmen unserer Zertifizierungen zum Outsourcing & TPR-Management Professional (cOMP). Insofern nehmen wir nach wie vor eine hohe Unsicherheit zur Klassifizierung in der Instituten zu diesem Thema wahr.
➡️ Die Folge: Fehlklassifizierungen, Unterschätzung potenzieller Risiken und lückenhafte Steuerung.

🎯 Lösung: Ein klar definierter Klassifizierungsprozess aller Dienstleister inkl. IT-Kritikalität ist unverzichtbar. Hierfür sollte man sich an den Prozessvorgaben der Aufsicht orientieren und in der eigenen schriftlich fixierten Ordnung ausprägen, wie bestimmte Interpretationen im Hause ausgelegt und gelebt werden. Ein Beispiel: was bedeutet eigentlich: “Wird die Dienstleistung für die Ausübung der Geschäftstätigkeit benötigt?” Eine zu enge Auslegung führt gerne zu Feststellungen.

3. Schwächen in der Risikoanalyse bzw. -bewertung

📉 Risikoanalyse unter Druck – Wo bleibt die Tiefe?

Ein häufig übersehener Punkt: Das verwendete Template zur Risikoanalyse/ bzw. -bewertung von Dienstleistungen zeigte erhebliche Mängel – von fehlenden Begründungen über oberflächliche Einschätzungen bis hin zu unzureichender Einbindung von BCM und IT-Sicherheit. Auch Lücken in der Dokumentation von Unterauftragsvergaben wurden festgestellt.

🔧 Empfehlung: Ganzheitliche Templates mit verbindlichen Mindestanforderungen an Inhalt, Tiefe und Risikobegründung sind essenziell.

🎯 Lösung: Neben der Verwendung von zwei Vorlagen zur Beurteilung der Risiken (einerseits für den Vendor “Due Diligence” und andererseits für den Sachverhalt “ex-ante-Risk-Assessment") sollten zwingend zumindest alle vorgegebenen Risiken der Verordnung mit zumindest einer Frage abgedeckt sein. Gerne kann auch je DORA-Risiko ein Set an Checkpunkten verwendet werden. Der Unterschied zwischen der Abdeckung an Risiken kann mitunter das Grading eines Findings (F1 bis F4) bereits positiv oder negativ beeinflussen.

4. Keine Nutzung von Prüfrechten beim Dienstleister

🔒 Vertrauen ist gut – Kontrolle ist Pflicht
Die Bank hatte zwar vertraglich verankerte Prüfrechte zur Bewertung von Sicherheitsmaßnahmen bei Dienstleistern eingeräumt – jedoch wurden diese nicht aktiv genutzt.

➡️ Ohne Einsicht in die reale Sicherheitslage bleibt das Risikobild unvollständig – insbesondere im Hinblick auf kritische Funktionen.

🎯 Lösung: Prüfrechte nicht nur vertraglich absichern, sondern auch operativ nutzen. Wir dürfen uns keinesfalls auf Dauer ausschließlich auf Zertifikate oder Berichte verlassen. Die kritisch wichtigen Dienstleistungen müssen in jedem Fall in den institutseigenen Prüfungsplanungen berücksichtigt und sollten in angemessenem Umfang auch tatsächlich vor Ort geprüft werden.

Nicht selten verfügen gerade kleinere Institute mitunter nicht über ausreichend Kapazitäten oder über das erforderliche Know-How, um z.B. Dienstleister wie die großen Hyperscaler bzw. IT Mehrmandantendienstleister zu prüfen.

5. Fehlende Leistungs-KPI’s oder Qualitätsvorgaben

Erste Prüfungserfahrungen 📊 Leistung messen – aber wie?

Neben Informationssicherheit sollten auch Leistungsgüte und Servicequalität zentral überwacht werden.
Die Prüfung ergab jedoch: Es existierten keine KPI-Vorgaben oder Leistungsstandards für die Dienstleister bzw. Dienstleistungen. Dies ist nicht gerade ein neues Finding, zeigt aber durch den ggf. größere Zahl an relevanten Sachverhalten eine prominentere Relevanz. Während in der Vergangenheit zumindest für Auslagerungen KPI Pflicht bzw. gelebte Praxis waren, erhält dieser Punkt nun auch für die IKT Dienstleistung nach DORA Lesart Relevanz.
🎯 Ohne Leistungskennzahlen bleibt die Steuerung von Drittparteien reaktiv statt vorausschauend.

💡 Jetzt ist der richtige Zeitpunkt, KPI-basierte Dienstleistersteuerung in DORA-Projekte zu integrieren.

➡️ Praxistipp aus eigener Erfahrung: KPI Bibliotheken mit Zuordnung zu den Arten an der Drittbezüge helfen – insbesondere den 1st Lines - geeignete KPI zu identifizieren und vermeiden endlose Diskussionen zwischen 1st und 2nd Lines. Bei der Erstellung der Bibliotheken sollten sowohl Fachbereichsverantwortliche als auch die unterschiedlichen verantwortlichen 2nd-Lines eingebunden werden.

6. Kein definiertes Soll für risikorelevante Informationen

Erste Prüfungserfahrungen: Informationsdefizite bei kritischen Services

Das Institut hatte keine klaren Anforderungen an die Bereitstellung risikorelevanter Informationen durch Dienstleister – besonders in Bezug auf kritische oder wichtige Funktionen. Hierbei wurde insbesondere bemängelt, dass nicht im ausreichenden Maße Berichte, Zertifikate oder Leistungsnachweise mit dem Dienstleister vereinbart wurden. Auch dies ist prinzipiell keine neue Anforderung und bestand auch im Bereich der Auslagerungen. Aber auch hier gilt, dass nun eine größere Anzahl von Bezügen – die zuvor nicht im Auslagerungsregime geregelt waren – von diesen Anforderungen tangiert werden.

➡️ Dadurch entsteht eine erhebliche Intransparenz über bestehende Risiken und Abhängigkeiten.

Spannend ist natürlich die Frage welche Dokumente in welchen Fällen als “risikorelevante Informationen” tatsächlich in die Verträge geschrieben werden. Welche Erfahrungen haben Sie hierzu gemacht?

Für einen Austausch und zur Diskussion kann gerne auch unser bmc-Dialog genutzt werden.

Praxistipp aus eigener Erfahrung: Es reicht natürlich nicht die Dokumente und erforderlichen risikorelevanten Informationen nur im Vertrag zu vereinbaren. Selbstverständlich besteht auch die Erwartung diese dann auch regelmäßig einzufordern und diese auch zu sichten und Schlüsse daraus zu ziehen.

🔍 Fazit: Ein definiertes „Soll“ an Informationen ist Grundlage für jedes funktionierende IKT-Risikomanagement.

Sie möchten das Thema weiter vertiefen? Sprechen Sie mit uns.