Warum Cybersicherheit in der Zusammenarbeit mit Lieferanten heute wichtiger ist als je zuvor

Die Anforderungen der NIS2Richtlinie treffen nicht nur Ihr eigenes Unternehmen – sie wirken entlang der gesamten Lieferkette. Jede Schnittstelle zu Lieferanten, Dienstleistern oder technischen Partnern kann zu einem Risiko werden, wenn Cybersicherheitsmaßnahmen nicht aufeinander abgestimmt sind. Genau das erleben wir in der Praxis immer wieder: unterschiedliche Reifegrade, fehlende Zertifizierungen und uneinheitliche Standards schaffen Lücken, die Angreifern ideale Angriffspunkte bieten.

Dieser Beitrag zeigt, welche Gefahren entstehen können, warum harmonisierte Sicherheitsanforderungen so wichtig sind – und wie Unternehmen gemeinsam Lösungen schaffen. 

Gemeinsame Cyberrisiken in vernetzten Lieferketten 

Unternehmen arbeiten heute mit einer Vielzahl externer Partner zusammen:
Rechenzentren, Cloud-Anbieter, Softwarelieferanten, Wartungsfirmen oder Service
Provider. Diese Partner verarbeiten Daten, greifen auf Systeme zu oder betreiben
eigene Infrastrukturen.
Dabei gilt ein einfacher Grundsatz: Cybersicherheit ist nur so stark wie das schwächste
Glied.

In unserer Beratungspraxis sehen wir immer wieder typische Risiken an diesen
Schnittstellen, die in der Zusammenarbeit häufig nicht ausreichend abgestimmt sind:

• Unsichere Systemzugänge von externen Dienstleistern (z. B. RemoteWartung)

• Unklare Patch- und Update-Prozesse, die bei Partnern deutlich verzögert erfolgen

• Unterschiedliche Authentifizierungsstandards (MFA vs. einfache Passwörter)

• Unzureichend gesicherte Cloud- oder SaaSDienste ohne formale Zertifizierung

• Fehlende Sensibilisierung der Mitarbeiter in den Partnerunternehmen

• ShadowIT, wenn Partner Tools einsetzen, von denen Ihr Unternehmen nichts weiß

Selbst dann, wenn Ihre internen Sicherheitsmaßnahmen bereits auf hohem Niveau
sind, können solche Schwachstellen diese Schutzmechanismen aushebeln. Genau
deshalb lohnt sich der Blick auf die gesamte Lieferkette, nicht nur auf das eigene
Haus.

Unterschiedliche Reifegrade: Wenn Zertifikate den Unterschied machen 

Viele Organisationen verfügen über etablierte Standards wie beispielsweise: 

• ISO/IEC 27001

• BSI ITGrundschutz

• TISAX

• NIS2-konformes ISMS

Diese Unternehmen arbeiten meist strukturiert, planvoll, auditierbar und mit klaren Rollenmodellen. 

Doch wie sieht die Realität aus?

Bei vielen kleineren oder weniger regulierten Partnern gibt es lediglich Basismaßnahmen, die oft auch nicht den Stand der Technik abbilden:

• Standard Firewall und Virenschutz ohne Überwachung  

• Spontan gewachsene ITStrukturen ohne nachvollziehbare Architektur 

• IncidentProzesse die weder systematisch verlaufen noch klare Verantwortlichkeiten festgelegt haben 

• Unvollständige oder stark individualisierte Dokumentation  

Das eigentliche Risiko entsteht dann, wenn Unternehmen aus pragmatischen Gründen
ihre eigenen hohen Standards absenken, um die Zusammenarbeit möglich zu machen.
Genau an dieser Stelle entstehen Compliance-Risiken und potenzielle Haftungsfragen
im Kontext von NIS-2. Denn ein Vorfall beim Lieferanten bleibt selten beim Lieferanten.
Er wird schnell zum Problem für Ihr eigenes Unternehmen.

Warum gegenseitige Vereinbarungen unverzichtbar sind

Damit die Sicherheit in der Lieferkette gewährleistet ist, brauchen Unternehmen klar definierte, gemeinsam akzeptierte Regeln.

Aus unserer Erfahrung heraus empfehlen wir vertragliche Regelungen zu treffen, die beiden Seiten als Orientierung zur Stärkung der eigenen Cyberresillienz dienen können: 

• Mindest-Sicherheitsanforderungen festlegen 

• Dokumentationspflichten für den Nachweis von Sicherheitsmaßnahmen 

• Gemeinsame Vorgaben zu Identitäts- & Zugriffsmanagement 

• Regeln für den Austausch von Informationen und Daten 

• Meldepflichten für Sicherheitsvorfälle 

• Verpflichtung zu regelmäßigen Audits 

• Regeln für Remote Zugriffe und gemeinsame Systeme 

Wichtig ist dabei die Haltung: Gegenseitige Kontrollen sind kein Ausdruck von Misstrauen. Sie schaffen Klarheit, schützen beide Seiten und sorgen dafür, dass im Ernstfall nicht erst Zuständigkeiten und Erwartungen geklärt werden müssen.
Audits verstehen wir deshalb nicht als Sanktion, sondern als Instrument gemeinsamer Verbesserung.

Praktische Lösungen für eine sichere Zusammenarbeit

Wir unterstützen Unternehmen dabei, ihre Lieferkette so aufzustellen, dass Sicherheitsanforderungen nicht nur dokumentiert, sondern im Alltag auch wirklich gelebt werden.

✔ Gemeinsame Risikoanalysen durchführen 

Identifizieren Sie kritischer Schnittstellen und Systeme auf beiden Seiten. 

✔ Abgleich der Cybersicherheitsreife vornehmen 

Stellen Sie sich mit Ihrem Partner folgende Fragen: Wo steht der eigene Partner? Welche Lücken sind kritisch? Welche Maßnahmen sind realistisch? 

✔ Wir moderieren Workshops & Awareness-Programme  

Sensibilisieren Sie alle beteiligten Mitarbeiter bis zur Geschäftsleitung. 

✔ Wir unterstützen bei der Einführung struktureller Sicherheitsmaßnahmen 

Wir begleiten die Einführung oder Aufrechterhaltung von Managementsystemen (ISO 27001, TISAX, BSI-Grundschutz etc.) und erstellen mit Ihnen Policies, Rollenmodelle, Passwort- und Berechtigungskonzepte. 

✔ Lieferantenaudits planen und umsetzen 

Gemeinsam mit Ihrem Personal helfen wir bei der regelmäßigen Planung, vereinbaren Termine und sorgen für Transparenz der Ergebnisse. Damit Lieferantenaudits nicht als Kontrolle, sondern als gemeinsame Qualitätsmaßnahme erlebt werden

Wie wir Sie darüber hinaus konkret unterstützen

Wir unterstützen Unternehmen entlang der gesamten Sicherheitskette, insbesondere dort, wo NIS2 klare Pflichten definiert. 

Unsere Angebote für Ihre NIS2Konformität und sichere Lieferketten: 

1. Ausbildung interner Auditoren

• Praxisnahe Schulung interner Auditoren nach ISO 19011  

• Ausbau der Methodenkompetenz für Informationssicherheits- und andere Beauftragte 

• Wir entwickeln Umsetzungswissen speziell für Lieferantenaudits 

2. Schulungen aller Mitarbeiterebenen

• Individuelle Awareness für unterschiedliche Fachbereiche 

• Spezielle Trainings für Führungskräfte und Geschäftsleitung (NIS2Pflicht!) 

• Rollenbezogene Schulungen für IT, Einkauf und Vertrieb 

3. Unterstützung bei Lieferantenaudits

• Mitarbeite bei der Auditplanung und Risikobewertung 

• Erstellung von Auditprogrammen und Fragenkatalogen 

• Durchführung von Audits gemeinsam oder vollständig delegiert 

• Bewertung des Reifegrades und Maßnahmenpläne 

4. Harmonisierung der Sicherheitsanforderungen

• Erstellung von Mindeststandards 

• Entwicklung von Lieferantenrichtlinien 

• Definition von Sicherheitsanhängen für Verträge (z. B. SLA, NDA, AVV) 

5. Begleitung bei der Umsetzung

• Einführung und Aufrechterhaltung eines Informationssicherheitsmanagementsystems 

• Aufbau eines durchgängigen Lieferketten-Sicherheitsmanagements 

• Coaching von Verantwortlichen im Tagesgeschäft 

Die NIS-2-Richtlinie macht deutlich: Cybersicherheit endet nicht an der Grenze Ihres Unternehmens.

Sichere Lieferketten entstehen dort, wo Unternehmen und ihre Partner Verantwortung gemeinsam tragen. Mit klaren Vereinbarungen, nachvollziehbaren Standards, regelmäßigen Audits und einem praxistauglichen Vorgehen schaffen Sie die Grundlage für mehr Sicherheit, mehr Resilienz und mehr Handlungsfähigkeit. Wir unterstützen Sie dabei, Ihre Partner systematisch einzubinden, Risiken frühzeitig zu erkennen und Sicherheitsanforderungen so umzusetzen, dass sie im Alltag funktionieren.

Wie hilft das Modell der geteilten Zuständigkeit dabei, die richtigen Steuerungsimpulse für Cloud-Services zu ermitteln und die Services zielgerichtet zu überwachen

Matthias Kurfels, Manager, Head of Competence Center “Governance, Risk, Compliance, Information Security, Data Protection” und Isaac Michael, Consultant Informationssicherheit sowie Informationssicherheitsbeauftragter, beide evolving systems consulting GmbH, Hamburg

Die Anforderung aus Artikel 28 Absatz 1 DORA, dass die Verantwortung für von Dritten bezogene Aktivitäten weiterhin beim Finanzunternehmen verbleibt, ist mit Blick auf das KWG und die MaRisk altbekannt. Aufgrund der hohen Komplexität von Cloud-Services ist die Umsetzung dieser Anforderung jedoch leichter gesagt als getan. Denn unabhängig davon, ob es sich bei einem Cloud-Service um SaaS, IaaS oder PaaS handelt, besteht dieser immer aus mehreren technischen Schichten, die in ihrer Gesamtheit das jeweilige Servicemodell darstellen. Abhängig vom Servicemodell und dem Schichtenmodell des jeweiligen Cloud Services Providers (CSP) sind er und der Cloudnutzer für eine oder mehrere Schichten verantwortlich (siehe Abbildung).

Zum Teil besteht für eine bestimmte Schicht auch eine gemeinsame Verantwortung. So weist beispielsweise ein bekannter Provider darauf hin, dass er in einem PaaS-Modell zwar

die Basissicherheit des Netzwerks stellt, der Administrator auf Nutzerseite jedoch auf Anwendungsebene die Netzwerksteuerungen konfigurieren muss. Die Sicherheit der Cloudnutzung in der Schicht „Netzwerk“ hängt somit davon ab, dass sowohl der CSP als auch der Nutzer ihrer jeweiligen Verantwortung nachkommen.

Und hier kommen wir zum Kern des Problems (und natürlich auch dessen Lösung). Jedes Unternehmen, das Cloudlösungen nutzt, muss sich fragen: „Arbeiten wir nach dem ‚TEAM-Prinzip‘ („Toll! Ein anderer macht’s“)? Oder wissen wir ganz genau, wo die Zuständigkeit unseres CSP aufhört und wir selbst aktiv werden müssen, um die Sicherheit der Cloud zu gewährleisten? Und wissen wir auch, welche Kontrollmechanismen der CSP eingerichtet hat und wie diese wirksam in unser IKS integriert werden können?“

Die Antworten darauf zu kennen ist sehr wichtig, denn bereits im Jahr 2022 wurde im Rahmen eines Berichts der Cloud Security Allianz darauf hingewiesen, dass die meisten Verstöße gegen die Cloud-Sicherheit das direkte Ergebnis einer Fehlkonfiguration sind1. Und die EZB weist in ihrem Leitfaden zur Cloudnutzung2 in Kapitel 2.1.2 darauf hin, dass sich die ex ante-Risikobewertung auch auf die Abstimmung der Kontrollmechanismen beziehen muss.

Ein Finanzunternehmen, das die inhärenten Risiken der Cloudnutzung analysieren und steuern will, muss also anhand der inzwischen sehr umfassenden Informationen, die die großen CSP zur Verfügung stellen, im Detail ermitteln,

· für welche Schichten und damit zusammenhängende Aktivitäten es selbst verantwortlich ist,

· wo ggf. gemeinsame Zuständigkeiten mit dem CSP bestehen und wie die Zusammenarbeit funktioniert,

· wo der CSP die alleinige Zuständigkeit besitzt und

· wie die Kontrollprozesse des CSP wirksam in das eigene IKS integriert werden können.

Am Beispiel des Business Continuity Managements würde das Ergebnis dieser Analyse bedeuten, dass die Schichten und Aktivitäten, für die das Unternehmen selbst verantwortlich ist, in dessen eigenes Notfallmanagement und damit auch Notfalltests einbezogen werden müssen. Für Schichten oder Aktivitäten mit gemeinsamer Verantwortung müssen die Vorgehensweisen und Maßnahmen konkret mit dem CSP vereinbart werden. Und bei allen Schichten und Aktivitäten, für die der CSP die alleinige Verantwortung trägt, wird es das BCM sowie das IKT-Drittbezugsmanagement interessieren,

· wie das Notfallmanagement einschließlich regelmäßiger Notfalltests beim CSP konkret aussieht, welche spezifischen Nachweise der CSP darüber bereitstellt und ob diese geeignet sind, sein Notfallmanagement zu beurteilen,

· ob die Reaktions- und Wiederanlaufzeiten des Cloudservices (und seiner relevanten Sub-Dienstleister) den Anforderungen des Auftraggebers entsprechen, und

· durch welche Maßnahmen übermäßige negative Auswirkungen auf zeitkritische Aktivitäten des Unternehmens begrenzt werden und ein nicht akzeptabler Schaden ausgeschlossen werden kann.

Dieses oben beschriebene Prinzip lässt sich auch auf andere Themengebiete ausweiten, z. B. die Gewährleistung der Datenschutzanforderungen. Für Schichten und Aktivitäten im Verantwortungsbereich des Finanzunternehmens würde das bedeuten, dass Anforderungen an die Zweckbindung, an Löschfristen oder „Privacy by Design“ in den eigenen Entwicklungs- und Betriebsprozessen umgesetzt und durch geeignete interne Kontrollen überwacht werden müssen. Bei gemeinsamen Zuständigkeiten ist zu klären, wie technische und organisatorische Maßnahmen ineinandergreifen, etwa bei Verschlüsselung, Identitäts- und Berechtigungsmanagement oder der Protokollierung von Zugriffen inklusive der Frage, wer die Protokolle einsehen darf. Für Schichten und Aktivitäten, die vollständig im Verantwortungsbereich des CSP liegen, ist durch das Finanzunternehmen in Erfahrung zu bringen,

· welche technischen und organisatorischen Maßnahmen zum Schutz personenbezogener Daten implementiert sind,

· welche Prüfberichte, Zertifizierungen oder Auditnachweise zur Bewertung dieser Maßnahmen bereitgestellt werden, und

· ob Informations- und Prüfungsrechte des Instituts und der Aufsicht wirksam wahrgenommen werden können.

PRAXISTIPPS

· Analysieren Sie das Schichtenmodell Ihres CSP eingehend, um die Verantwortlichkeiten konkret zuordnen zu können.

· Vereinbaren Sie für die im Verantwortungsbereich des Dienstleisters liegenden Aktivitäten SLAs.

· Verschaffen Sie sich Gewissheit über die vom CSP durchgeführten Kontrollen und Maßnahmen zu den Aktivitäten, die in dessen Verantwortung liegen und stimmen Sie die Überwachung und Steuerung des CSP darauf ab

Link zur Pressemitteilung mit den zusammengefassten Ergebnissen: Cloud Security Alliance’s Top Threats to Cloud | CSA

Quelle: EZB-Leitfaden zur Auslagerung von Cloud-Diensten an Cloud-Anbieter

Viele Finanzunternehmen gehen davon aus, dass NIS–2 für sie nicht gilt, weil DORA als lex specialis greift. Das ist in einem entscheidenden Punkt ein gefährlicher Irrtum. Die Registrierungspflicht beim BSI bleibt bestehen und Verstöße können teuer werden. 

BaFin Regulierung ersetzt keine BSI-Registrierung

Für Banken, Versicherungen und KVGs wird häufig auf Erwägungsgrund 28 der NIS-2 Richtlinie verwiesen, weil dort DORA als lex specialis genannt wird. Das führt in der Praxis zu der Annahme, dass damit alle Pflichten aus dem NIS-2 Kontext erledigt sind. Allerdings stimmt das so nicht. Denn Finanzunternehmen werden gemäß § 28 Abs. 6 BSIG nicht von der Pflicht ausgenommen, sich als wichtige oder besonders wichtige Einrichtung gemäß § 33 BSIG im BSI Portal zu registrieren – auch dann nicht, wenn sie bereits durch die BaFin reguliert werden. 

Wen die Pflicht betrifft 

Registrierungspflichtig sind alle Finanzunternehmen, die dem Sektor Finanzwesen nach Anlage 1 BSIG Nr. 3 zugeordnet sind und die Wesentlichkeitskriterien in § 28 BSIG erfüllen. In diesen Fällen ist die Registrierung im BSI Portal spätestens bis zum 06.03.2026 erforderlich. 

Was passiert bei Nichtregistrierung? 

Wer die Registrierungspflicht ignoriert, riskiert Sanktionen. Nach § 65 Abs. 2 Nr. 6, Abs. 5 Nr. 5 BSIG drohen Bußgelder von bis zu 500.000 Euro. Viele Institute haben das aktuell nicht auf dem Radar, weil sie davon ausgehen, dass DORA sie von allen Pflichten nach NIS-2 ausnimmt. Finanzunternehmen sollten daher zeitnah prüfen, ob sie der Meldepflicht nach § 33 BSIG unterliegen und diese bei positiver Feststellung zeitnah vornehmen, um finanzielle Schäden zu vermeiden und ihrer gesetzlichen Pflicht nachzukommen!

Wie wir unterstützen 

Als ISO 27001:2022 zertifizierte IT-Unternehmensberatung begleiten wir Finanzunternehmen bei NIS2 und BSIG Compliance, DORA-Umsetzung, ISMS-Aufbau nach ISO 27001, Gap Analysen und Wesentlichkeitsbewertungen sowie bei Registrierung und Meldeprozessen im BSI Portal. Außerdem unterstützen wir bei der Auslagerungsgovernance und bei der sinnvollen Verzahnung von Risikoanalyse und Due Diligence. 

DORA gilt oft als lex specialis, doch die BSI Registrierungspflicht nach BSIG bleibt für viele Finanzunternehmen bestehen. Fristsicher handeln bis 06.03.2026 und Bußgelder vermeiden.

Gestalten Sie die digitale Souveränität – mit Open Source und Projektmanagement im öffentlichen Sektor.

Die Digitalisierung der Verwaltung wirft eine Reihe von besonderen Herausforderungen auf, darunter unterschiedliche Zuständigkeiten, föderale Strukturen, komplexe fachliche Anforderungen und die Notwendigkeit, digitale Lösungen nachhaltig, transparent und wiederverwendbar zu gestalten. Ergänzend ist aktuell die Verlässlichkeit bestehender Technologiepartnerschaften neu zu bewerten. Open-Source-Plattformen bieten dafür ideale Möglichkeiten und professionelles Projektmanagement sorgt dafür, dass diese Potenziale wirksam genutzt werden.

Projektmanagement erfordert einen neuen Ansatz: Offenheit steuerbar machen

Projektmanagement umfasst mehr als nur Zeit, Budget oder Qualität. Das Ziel besteht darin, Strukturen zu etablieren, die Offenheit ermöglichen, ohne diese zu beeinträchtigen. Erfolgreiche Projekte entstehen dort, wo Prozesse, verantwortungsbewusste Mitarbeitende und eine gelebte Kultur von Vertrauen, Offenheit und konstruktiver Fehlerkultur zusammenwirken. Unsere Expertise liegt in der Verbindung von Fachlichkeit, Technik, Organisation und Governance. Es erfolgt eine Bündelung von Informationen und Perspektiven, deren Aufbereitung in einer für die Zielgruppe verständlichen Form sowie die Entwicklung tragfähiger Projektziele. Dies geschieht sowohl für operative Abläufe als auch für strategische Entscheidungen. Die gemeinsame Entwicklung und fortgesetzte Nutzung von Open Source stellt einen strategischen Ansatz dar, der nicht als Selbstzweck betrachtet werden sollte. Die Verwendung offener Komponenten ermöglicht Transparenz, Nachvollziehbarkeit und gemeinsame Weiterentwicklung. Mit dem Ansatz „Public Money Public Code“ stellen wir sicher, dass Lösungen, die mit öffentlichen Mitteln entwickelt wurden, prüfbar und wieder verwendbar sind.

OpenCode als Plattform bietet den Vorteil, dass bestehende Bausteine in unterschiedlichen Verwaltungen leichter nachgenutzt werden können. Zudem wird deren Sichtbarkeit gefördert. Dadurch wird verhindert, dass Lösungen mehrfach entwickelt werden müssen, und die verfügbaren Ressourcen und das Know-how werden effizient genutzt. Digitale Souveränität bezeichnet in diesem Kontext die Fähigkeit, fachliche Anforderungen in digitale Lösungen umzusetzen, die Kontrolle über die technische Infrastruktur zu wahren, Lösungen gemeinsam zu nutzen und weiterzuentwickeln sowie Transparenz, Wiederverwendbarkeit und nachvollziehbare Entwicklungslogik als Grundlage für nachhaltige digitale Lösungen zu gewährleisten.

Komplexität effizient steuern – ohne dabei die Offenheit zu verlieren

Verwaltungsprojekte sind häufig durch eine Vielzahl paralleler Prozesse, verteilter Informationen und unterschiedlicher Logiken gekennzeichnet: technische Standards, rechtliche Rahmenbedingungen, fachliche Anforderungen und föderale Abstimmungen müssen in Einklang gebracht werden. Professionelles Projektmanagement bündelt diese Perspektiven, schafft Struktur, Orientierung und Entscheidungsfähigkeit – ohne den offenen Entwicklungsprozess zu bremsen. Auf diese Weise werden Lösungen entwickelt, die in der Praxis umsetzbar, tragfähig und auf weitere Verwaltungen anwendbar sind.

Vier Prinzipien erfolgreicher Projekte im Open-Source-Umfeld

Aufgrund unserer Erfahrung haben sich vier zentrale Elemente als besonders wirkungsvoll erwiesen:

• Nachvollziehbarkeit: Entscheidungen, Risiken und Ergebnisse werden transparent dokumentiert.

• Klarheit im Vorgehen: Rollen, Abläufe und Eskalationswege sind eindeutig definiert.

• Stabilität trotz Bewegung: Iterative Entwicklung wird mit verbindlichen Meilensteinen kombiniert.

• Nachhaltiges Wissensmanagement: Ergebnisse werden verständlich dokumentiert und für andere Stellen nachnutzbar aufbereitet.

Diese Prinzipien stellen sicher, dass Projekte steuerbar bleiben, Ergebnisse nachvollziehbar sind und Lösungen langfristig tragfähig werden.

Mehrwert für Verwaltung und Gesellschaft

Professionelles Projektmanagement ist der Raum, in dem Entwicklung und öffentliche Governance effektiv zusammenwirken. Das Ziel ist klar definiert: Digitale Souveränität durch Zusammenarbeit, Offenheit und Wiederverwendbarkeit – damit digitale Lösungen im öffentlichen Sektor effizient, nachvollziehbar und nachhaltig gestaltet werden können.

Gibt es bei der Anbahnung von IKT-Dienstleistungen für Risikoanalyse und Due Diligence eine „richtige“ Reihenfolge, oder sollte beides parallel erfolgen?

Matthias Kurfels, Manager, Head of Competence Center “Governance, Risk, Compliance, Information Security, Data Protection” und Christina Renner, Senior Consultant, Competence Center GRCID, beide evolving systems consulting GmbH, Hamburg

Die Auslagerung von IT-Leistungen ist fester Bestandteil der Bankpraxis. Cloud-Services, Plattformlösungen und spezialisierte IT-Anbieter erhöhen Effizienz und Flexibilität, führen jedoch auch zu steigenden Abhängigkeiten. Vor diesem Hintergrund kommt der umfassenden Beurteilung von Risiken eine zentrale Bedeutung zu.

Aus aufsichtsrechtlicher Sicht ist vorgesehen, dass die Risikoanalyse¹ vor dem Vertragsabschluss erfolgen muss, um sowohl den Vertrag als auch die Überwachungsprozesse auf die ermittelten Risiken abzustimmen. Bei Auslagerungen nach MaRisk kommt noch hinzu, dass anhand der Risikoanalyse die Wesentlichkeit einer Auslagerung bestimmt wird. Ergänzend dazu dient die Due Diligence zur Beurteilung, ob der potenzielle IKT-Drittdienstleister für die Erbringung des Services geeignet ist, alle rechtlichen und betriebswirtschaftlichen Voraussetzungen dafür mitbringt und auch die identifizierten Risiken (einschließlich aus weiterverlagerten Aktivitäten) angemessen steuern kann.

Was kommt zuerst – Risikoanalyse oder Due Diligence?

In der Praxis existieren zwei Verfahrensweisen: Ein Teil der Banken fängt mit einer umfassenden Due Diligence an und führt die Risikoanalyse im Anschluss durch. Das trägt dazu bei, dass die Ergebnisse der Sorgfaltsprüfung eine belastbare Risikobewertung ermöglichen. Dennoch ist zumindest eine vorläufige Risikoeinschätzung vor Beginn der Due Diligence erforderlich, um Fehlinvestitionen und inkonsistente Entscheidungen zu vermeiden. Der andere Teil der Banken führt die Due Diligence erst nach der Risikoanalyse durch, um diese – z. B. im Fall nicht wesentlicher Auslagerungen – kürzer halten zu können und damit Effizienzgewinne zu erzielen.

Die letztgenannte Vorgehensweise mag aus der MaRisk-Sicht sinnvoll sein, kann jedoch bei IKT-Dienstleistungen dazu führen, dass erst bei der Due Diligence das Fehlen wesentlicher Voraussetzungen für den Drittbezug bemerkt werden könnte. Wenn der Dienstleister z. B. nicht die erforderlichen Informationssicherheitsanforderungen erfüllt² oder seine organisatorischen Fähigkeiten zur Steuerung von Risiken unzureichend sind³, war der zuvor betriebene Aufwand für die Risikoanalyse faktisch umsonst, weil solche Drittbezugsvoraussetzungen nicht durch die kurzfristige Nachreichung von Dokumenten hergestellt werden können. Somit ist gerade bei IKT-Dienstleistungen die Frage der Reihenfolge besonders relevant, um Grundlage, Tiefe und Fokus der Risikoanalyse sachgerecht zu gestalten.

Lösungsansätze zur Auflösung des Spannungsfelds

Wenn die bislang nachgelagerte Due Diligence z. B. aufgrund von Restriktionen des Workflow-Tools nicht vorgezogen werden kann, könnten wichtige Voraussetzungen, die nicht kurzfristig durch Dokumente nachgewiesen werden können, bereits als Mindestanforderung im Rahmen der Ausschreibung definiert werden. Alternativ könnten einzelne kritische Kriterien, die für den betreffenden Drittbezug individuell ermittelt wurden, gezielt vor der eigentlichen Risikoanalyse abgefragt und „außer der Reihe“ beschafft werden, während weniger kritische Aspekte im weiteren Verlauf der (nachgelagerten) Due Diligence ergänzt werden. Und ein weiterer Ansatz besteht darin die Risikoanalyse und Due Diligence prozessual miteinander zu verzahnen, was die BaFin in ihrer Veranstaltung am 04.12.2025 ausdrücklich empfohlen hat⁴. Unabhängig davon, welcher der genannten Lösungsansätze gewählt wird, ist es immer wichtig, die Vollständigkeit und die inhaltliche Tiefe der Risikoidentifikation zu gewährleisten. Vor allem wenn ein gemeinsamer Fragenkatalog für Auslagerungen nach MaRisk und IKT-Drittbezüge nach DORA verwendet wird, müssen die spezifischen IKT-Risiken, insbesondere bei Cloud-Services, gesondert vertieft werden.

Wie bei Cloud-Services die Qualität der Risikoanalyse durch eine Orientierung am Shared-Responsibility-Modell verbessert werden kann, wird im nächsten Beitrag erläutert, der im März 2026 erscheint.

PRAXISTIPPS

· Falls bei IKT-Dienstleistungen die Due Diligence erst nach der Risikoanalyse erfolgt: Stellen Sie sicher, dass Sie bereits vor Beginn der Risikoanalyse über alle wichtigen Informationen aus der Due Diligence verfügen.

· Gewährleisten Sie vor allem bei IKT-Dienstleistungen, dass die Risikoanalyse alle Aspekte – vor allem etwaige spezifische Aspekte des betreffenden Services, die kein Teil ihres Standardvorgehens sind – berücksichtigt.

· Versuchen Sie – sofern möglich – die Risikoanalyse und die Due Diligence in einem gemeinsamen Prozessschritt durchzuführen, um von gegenseitigen Impulsen zu profitieren und alle Informationen zu einem Sachverhalt gebündelt verarbeiten zu können.

¹ In diesem Artikel wird vereinfachend sowohl für die Risikoanalyse nach MaRisk als auch die Risikobewertung nach DORA der Begriff „Risikoanalyse“ verwendet.

² Erfordernis gemäß Artikel 28 Absatz 5 VO (EU) 2022/2554

³ vgl. Artikel 6 Absatz 1 DV (EU) 2024/1773

⁴ BaFin – IT-Aufsicht im Finanzsektor: Das erste Jahr DORA: BaFin – Veranstaltungen – IT-Aufsicht im Finanzsektor: Das erste Jahr DORA

Quelle: https://www.fch-gruppe.de/newsletter/