NIS2 Bankenwesen: Welche Pflichten Banken, Sparkassen und Zahlungsdienstleister zwischen DORA, BaFin und BSI jetzt einordnen müssen.

Banken und Kreditinstitute fallen unter NIS2 als wesentliche Einrichtungen im Finanzsektor, doch DORA hat als Lex Specialis Vorrang; für das Keyword NIS2 Bankenwesen ist deshalb die wichtigste Einordnung: DORA strukturiert seit dem 17. Januar 2025 die digitale operationale Resilienz, BaFin bleibt die zentrale Aufsicht, MaRisk und BAIT gelten weiter, und NIS2 wirkt ergänzend über nationale Umsetzung, Governance und mögliche Doppelregulierung fort.

Für Banken reicht es deshalb nicht, nur auf ein einzelnes Regelwerk zu schauen. Wer die NIS2-Landschaft im Bankenwesen verstehen will, muss vier Ebenen zusammenführen: die NIS2-Richtlinie in Deutschland, die operativen Mindestmaßnahmen aus dem Beitrag zu den NIS2-Anforderungen nach Artikel 21, die organisatorische Befähigung aus der NIS2-Schulung, und die Grundbegriffe aus dem Glossar zu NIS2-Richtlinie und KRITIS. Genau diese Verzahnung ist im Bankenwesen entscheidend, weil regulatorische Überschneidungen schneller zu Umsetzungsfehlern führen als fehlende Technik.

NIS2 im Bankenwesen: Überblick

Das Bankenwesen ist unter NIS2 kein Randsektor, sondern Teil der regulierten Finanzdienstleistungen. Die NIS2-Richtlinie erfasst den Finanzsektor ausdrücklich, zugleich hat die EU mit DORA einen spezialgesetzlichen Rahmen geschaffen, der für viele Finanzunternehmen die konkretere Grundlage für digitale operationale Resilienz bildet. Für deutsche Banken ist deshalb nicht die abstrakte Frage „Sind wir betroffen?“ entscheidend, sondern die Reihenfolge der Prüfung: zuerst DORA, dann die ergänzende NIS2- und BSIG-Logik, danach die Einbettung in BaFin-Regelwerke wie MaRisk und BAIT.

Für die Praxis ist die DORA-Abgrenzung wichtiger als jede Marketingformel. DORA regelt Governance, IKT-Risikomanagement, Vorfallmanagement, Testen digitaler operationaler Resilienz, Drittparteirisiken und das Management kritischer IKT-Dienstleister sehr viel konkreter als NIS2. Gerade deshalb ist DORA im Bankenwesen der operative Arbeitsrahmen. NIS2 verschwindet aber nicht aus dem Bild. Sie prägt weiter den sektoralen Grundzuschnitt, die europäische Cybersicherheitsarchitektur, die nationale Umsetzung in Deutschland und die Erwartung, dass Leitungsorgane, Meldewege und Sicherheitsmaßnahmen nachvollziehbar organisiert sind.

Diese Überlagerung erzeugt im Bankenwesen eine andere Ausgangslage als in vielen anderen Branchen. Ein Industrieunternehmen fragt häufig zuerst, ob es als wichtige oder besonders wichtige Einrichtung eingestuft wird. Eine Bank fragt zuerst, welche DORA-Pflichten bereits unmittelbar gelten, wie diese mit MaRisk, BAIT, ZAIT oder PSD2 zusammenlaufen und ob ergänzend NIS2- beziehungsweise BSIG-Pflichten relevant bleiben. Wer diese Logik umkehrt, baut leicht doppelte Projekte, doppelten Dokumentationsaufwand und unnötige Diskussionen mit Aufsicht, Revision und externen Prüfern.

Für Entscheider ist deshalb diese Kurzform am nützlichsten: NIS2 liefert den sektorübergreifenden Cybersicherheitsrahmen, DORA konkretisiert die digitale operationale Resilienz für Finanzunternehmen, BaFin-Regelwerke übersetzen Teile davon in die deutsche Aufsichtspraxis, und das BSI bleibt für die deutsche NIS2-Umsetzung ein relevanter Bezugspunkt. Daraus folgt keine regulatorische Entwarnung, sondern ein höherer Anspruch an Governance, Rollenklärung und Nachweisführung.

Welche Banken und Kreditinstitute im NIS2 Bankenwesen betroffen sind

Betroffen sind im Bankenwesen nicht nur Großbanken. Zum regulierten Umfeld gehören insbesondere Banken, Sparkassen, Genossenschaftsbanken, Kreditinstitute, Zahlungsdienstleister, E-Geld-Institute, bestimmte FinTechs mit Erlaubnispflicht, Wertpapierinstitute und weitere Finanzunternehmen. Welche Einheiten tatsächlich unter DORA, ergänzende NIS2-Logik oder sektorale Sonderregeln fallen, hängt jedoch nicht allein von der Marke oder der Branche ab, sondern von der juristischen Person, der konkreten Erlaubnis, den angebotenen Diensten und der Stellung innerhalb einer Gruppe.

Für den deutschen Markt ist die Einzelfallprüfung deshalb zentral. Eine große Universalbank mit mehreren Tochtergesellschaften kann zugleich klassische Bankprozesse, Zahlungsverkehr, Wertpapiergeschäft, Outsourcing-Strukturen und konzerninterne IT-Dienstleistungen abdecken. Nicht jede Einheit ist dann identisch einzuordnen. Auch kleinere FinTechs sind kein Automatismus: Wer unterhalb bestimmter Schwellen bleibt, fällt möglicherweise nicht in den vollen NIS2-Mechanismus, kann aber dennoch BaFin-reguliert sein und damit strenge IT-Anforderungen erfüllen müssen. Im Bankenwesen ist die aufsichtsrechtliche Erlaubnis oft aussagekräftiger als die Selbstbeschreibung als „Tech-Unternehmen“ oder „digitale Bank“.

Besonders praxisrelevant ist die Frage nach den Schnittstellen zwischen Instituten und Dienstleistern. Rechenzentren, Kernbanksystem-Anbieter, Cloud-Provider, Managed-Service-Partner, Identitätsdienstleister, Kartenprozessoren, Open-Banking-Plattformen und externe Entwickler sind im Bankenwesen keine bloßen Hilfsunternehmen. Sie prägen die tatsächliche Resilienz des Instituts. Deshalb reicht es nicht, nur die eigene Banklizenz oder Mitarbeiterzahl zu betrachten. Entscheidend ist, welche Dienste für Zahlungsverkehr, Kontozugang, Kreditvergabe, Wertpapierhandel, Meldewesen oder Kundenauthentifizierung kritisch sind und wie stark das Haus von Drittparteien abhängt.

Die folgende Tabelle vereinfacht die Regulierungslandschaft für das Keyword NIS2 Banken:

Diese Einordnung ist mehr als Formalismus. Im Bankenwesen hängen Schulungsinhalte, Meldewege, Auditnachweise und Investitionsprioritäten direkt davon ab, ob Ihr Haus als klassisches Kreditinstitut, Zahlungsdienstleister oder gruppeninterne Finanz-IT organisiert ist. Genau deshalb sollten Fachbereiche nicht nur mit dem Begriff NIS2-Richtlinie arbeiten, sondern auch verstehen, warum im Finanzsektor dieselbe Cyberlage in unterschiedlichen Normschichten verarbeitet wird.

Spezifische NIS2-Anforderungen für Banken und Zahlungsdienstleister

Auch wenn DORA für viele Banken der speziellere Rahmen ist, bleibt die NIS2-Logik für die konkrete Maßnahmenarchitektur nützlich und teilweise ergänzend relevant. Der Kern besteht aus Risikomanagement, Incident Handling, Business Continuity, Lieferkettensicherheit, sicherer Entwicklung und Wartung, Wirksamkeitskontrollen, grundlegender Cyberhygiene, Kryptografie, Personalsicherheit und Zugangskontrolle. Genau diese Elemente tauchen im Bankenwesen in anderer Sprache wieder auf: in BAIT, in MaRisk, in ZAIT, in PSD2-Sicherheitsanforderungen und in DORA-Kapiteln zur digitalen operationalen Resilienz.

Für Banken ist der erste Schwerpunkt die Governance. Leitungsorgane dürfen Cybersicherheit nicht als reines IT-Betriebsthema behandeln. DORA verlangt eine klare Verantwortung der Leitungsorgane für das Management von IKT-Risiken; § 38 BSIG verlangt zusätzlich regelmäßige Schulung der Geschäftsleitungen betroffener Einrichtungen und die Überwachung von Risikomaßnahmen. In der Bankpraxis heißt das: Vorstand, zweite Verteidigungslinie, Informationssicherheit, Compliance und Revision brauchen eine gemeinsame Begriffs- und Eskalationsbasis. Ohne sie bleiben Vorstandsreporting, Priorisierung und Krisenentscheidungen inkonsistent.

Der zweite Schwerpunkt ist das IKT-Risikomanagement. Banken müssen ihre Kernprozesse in eine belastbare Resilienzlogik übersetzen: Kernbanksystem, Zahlungsverkehr, Online-Banking, Mobile Banking, Kundenauthentifizierung, Kartenprozesse, Treasury-Anwendungen, Wertpapierhandel, Dokumentenmanagement und Meldewesen dürfen nicht isoliert gesteuert werden. Maßgeblich ist, ob das Institut weiß, welche Systeme kritisch sind, welche Wiederanlaufzeiten gelten, welche manuellen Fallbacks existieren und welche externen Provider für den Betrieb unverzichtbar sind.

Der dritte Schwerpunkt ist das Vorfallmanagement. NIS2 und DORA sind sich darin ähnlich, dass sie keine bloße Incident-Policy auf Papier erwarten, sondern belastbare organisatorische Reaktionsfähigkeit. Für Banken bedeutet das mehr als ein SOC oder ein Ticketsystem. Benötigt werden Eskalationskriterien, Krisenrollen, Kommunikationspfade, Entscheidungsrechte, forensische Sicherung, Kundenkommunikation und regulatorische Meldelogik. Wer erst im Vorfall klärt, ob ein Online-Banking-Ausfall als erheblicher Sicherheitsvorfall gilt, verliert wertvolle Zeit.

Der vierte Schwerpunkt ist die Lieferkette. Im Bankenwesen sitzt das eigentliche Risiko oft in Auslagerungen und IKT-Drittparteien. Kernbanksysteme sind historisch gewachsen, Rechenzentrumsleistungen werden extern betrieben, PSD2-Schnittstellen öffnen Institute für Drittanbieter, und Cloud-Services werden für Analytik, Kommunikation oder bestimmte Backoffice-Funktionen eingesetzt. NIS2 und DORA ziehen daraus dieselbe Konsequenz: Drittparteirisiko ist kein Randthema für den Einkauf, sondern Teil des Sicherheits- und Betriebsmodells.

Der fünfte Schwerpunkt ist die dokumentierte Befähigung der Organisation. NIS2 verlangt Schulung und Sensibilisierung, das BSIG nennt dies ausdrücklich, und im Bankenwesen sind Fachrollen besonders differenziert. Eine allgemeine Awareness-Schulung reicht deshalb nicht. Zahlungsverkehr braucht andere Inhalte als Auslagerungsmanagement, Online-Banking andere als Revision, Vorstand andere als operativer IT-Betrieb. Genau daraus entsteht der praktische Bedarf an einer branchenspezifischen NIS2-Schulung, die regulatorische Überschneidungen im Bankenwesen nicht ausblendet.

Branchenspezifische Herausforderungen

Die größte Herausforderung im Bankenwesen ist die Gleichzeitigkeit von Stabilität und Veränderung. Banken betreiben einerseits hochkritische Systeme mit jahrzehntealten Kernbankkomponenten, andererseits öffnen sie APIs, verlagern Dienste in die Cloud, digitalisieren Kundenkontakt und müssen rund um die Uhr Zahlungsverkehr, Login, Authentifizierung und Kontozugriff ermöglichen. Diese Mischung macht NIS2 im Finanzsektor praktisch anspruchsvoll: Nicht einzelne Sicherheitsmaßnahmen fehlen, sondern die durchgängige Verzahnung von Altlandschaft, neuer Architektur und regulatorischen Nachweisen.

Ein besonders typisches Problem sind Legacy-Core-Banking-Systeme. Das Research beschreibt, dass viele regionale Banken mit Systemen arbeiten, die weit über ein Jahrzehnt alt sind. Solche Landschaften sind oft stabil, aber schwer segmentierbar, schwer testbar und nur mit hohem Aufwand patchbar. Wenn dazu Web-Frontends, Mobile Apps, PSD2-Schnittstellen und externe Dienstleister kommen, steigt das Risiko an den Übergängen. Die regulatorische Folge ist klar: Ein Institut darf sich nicht darauf verlassen, dass ein historisch stabiles Kernsystem automatisch resilient genug ist.

Die zweite branchenspezifische Herausforderung ist Open Banking. PSD2 hat sichere Drittanbieteranbindungen und starke Kundenauthentifizierung zum Standard gemacht. Operativ bedeutet das für Banken deutlich mehr externe Abhängigkeiten, mehr API-Schnittstellen, mehr Identitäts- und Berechtigungslogik und mehr potenzielle Vorfallpfade. Ein Vorfall im Open-Banking-Umfeld ist deshalb selten nur ein Technikproblem. Er betrifft meist gleichzeitig Sicherheit, Kundenkommunikation, Rechtsbewertung, Zahlungsverkehr und die Frage, welche Behörde oder welcher Partner informiert werden muss.

Die dritte Herausforderung ist die Dokumentationsdichte. Banken leben ohnehin in einer stark formalisierten Aufsichtswelt. Mit DORA, MaRisk, BAIT, ZAIT, PSD2, Auslagerungsrichtlinien und ergänzender NIS2-/BSIG-Logik entsteht leicht der Eindruck, dass nur noch Dokumente produziert werden. Das greift zu kurz. Die eigentliche Herausforderung besteht darin, dieselbe operative Realität einmal sauber zu beschreiben und dann für verschiedene regulatorische Perspektiven wiederverwendbar zu machen. Wer für jedes Regelwerk ein eigenes Paralleluniversum baut, verliert Steuerbarkeit.

Die vierte Herausforderung ist die Rollenklärung im Krisenfall. In vielen Banken sind Vorstand, CISO, Compliance, Datenschutz, Betriebsorganisation, Fachbereich, Kommunikation und externe Provider beteiligt, sobald ein schwerer Vorfall Zahlungsverkehr oder Kundenzugang beeinträchtigt. Genau an dieser Stelle zeigt sich, ob Schulung und Governance funktionieren. Ein Institut kann technisch gut ausgestattet sein und trotzdem regulatorisch schwach reagieren, wenn unklar bleibt, wer die Erheblichkeit einstuft, wer meldet, wer Kunden informiert und wer die Wiederanlaufentscheidung trifft.

Praxisbeispiel: Regionalbank mit Altbanksystem, PSD2-APIs und ausgelagertem Rechenzentrum

Ein konkretes Beispiel aus der Research-Basis für das NIS2 Bankenwesen ist die mittelgroße Regionalbank mit historisch gewachsenem Kernbanksystem, stark genutztem Online-Banking, PSD2-Schnittstellen für Drittdienstleister und einem teilweise ausgelagerten Rechenzentrumsbetrieb. Genau diese Konstellation ist im deutschen Markt realistisch, weil sie klassische Bank-IT, regulatorische Drittparteiensteuerung und kundennahe Digitalprozesse miteinander verbindet.

Stellen Sie sich vor, eine Schwachstelle in einer API-Anbindung oder in einem vorgeschalteten Authentifizierungsdienst führt zunächst zu auffälligen Login-Fehlern und später zu Verdachtsmomenten auf unberechtigte Zugriffe. Parallel ist das Kernbanksystem selbst nicht unmittelbar kompromittiert, aber die Online-Kanäle sind instabil, Kundinnen und Kunden können Transaktionen nur eingeschränkt durchführen, und der externe IT-Partner muss forensisch eingebunden werden. Aus technischer Sicht scheint das zunächst ein begrenzter Digitalvorfall zu sein. Aus regulatorischer Sicht laufen jedoch sofort mehrere Fragen parallel.

Erstens muss das Institut bewerten, ob ein meldepflichtiger IKT-Vorfall nach DORA oder nach sektorspezifischen BaFin-Vorgaben vorliegt. Zweitens ist zu prüfen, ob wegen der API-Anbindung oder des Zahlungsverkehrs auch PSD2-bezogene Pflichten ausgelöst werden. Drittens stellt sich die Frage, ob ergänzende Melde- oder Registrierungspflichten nach dem deutschen NIS2-Rahmen berührt sind oder ob das BSI jedenfalls im Gesamtsystem relevant wird. Viertens muss das Auslagerungsmanagement eingebunden werden, weil der Drittanbieterzugriff Teil des Vorfalls ist. Fünftens müssen Vorstand, Krisenkommunikation und Kundenservice konsistent informiert werden.

Genau dieses Beispiel zeigt, warum Banken NIS2 und DORA nicht als Konkurrenzregime behandeln sollten. Die Herausforderung besteht nicht darin, einen Begriff zu gewinnen, sondern eine Vorfallarchitektur zu haben, die beide Ebenen sauber bedient. Eine gute Bankenorganisation hat für solche Fälle vorab definiert, wer den Vorfall klassifiziert, wer den Kontakt zur BaFin hält, wann externe Forensik beauftragt wird, welche Mindestinformation intern verfügbar sein muss und wie Kundenkommunikation mit Aufsichtskommunikation abgestimmt wird.

Das Beispiel zeigt außerdem, warum Schulung im Bankenwesen branchenspezifisch sein muss. Ein allgemeiner Kurs zu Cyberhygiene würde hier kaum helfen. Benötigt wird ein gemeinsamer Handlungsrahmen für Vorstand, IT, Zahlungsverkehr, Auslagerungsmanagement, Compliance und Kommunikation. Genau darin liegt der praktische Nutzen einer spezialisierten NIS2-Schulung: Sie verkürzt nicht nur Wissenslücken, sondern reduziert Koordinationsfehler im Ernstfall.

Zusätzliche branchenspezifische Regulierungen im NIS2 Finanzsektor

NIS2 ist im Bankenwesen nie das einzige relevante Regelwerk. Für die meisten Institute ist DORA der zentrale Spezialrahmen für digitale operationale Resilienz. DORA adressiert Governance, IKT-Risikomanagement, Vorfälle, Tests, Informationsaustausch und Drittparteirisiken deutlich konkreter. Wer heute im Finanzsektor von „NIS2-Umsetzung“ spricht, ohne DORA an erste Stelle zu setzen, beschreibt die Regulierungsrealität deshalb unvollständig.

Daneben bleiben MaRisk und BAIT zentral. MaRisk verankert IT-Governance, Risikomanagement, Auslagerungssteuerung und Notfallorganisation im Gesamtsteuerungsrahmen der Bank. BAIT konkretisiert diese Anforderungen mit Fokus auf Informationssicherheit, Benutzerberechtigungen, Anwendungsentwicklung, IT-Betrieb, Auslagerungen und Notfallmanagement. Für Zahlungsinstitute und E-Geld-Institute kommt ZAIT hinzu. Für Zahlungsverkehrsdienste bleibt außerdem PSD2 mit starker Kundenauthentifizierung, sicherer Kommunikation und spezifischen Vorfalllogiken relevant.

Die sinnvolle Sichtweise lautet deshalb nicht „Welches Regelwerk gilt wirklich?“, sondern „Welche Regelwerke strukturieren denselben operativen Sachverhalt?“. Ein Identitätsvorfall im Online-Banking kann gleichzeitig Fragen aus DORA, BAIT, PSD2, Kundenkommunikation und ergänzender nationaler NIS2-Umsetzung berühren. Wer diese Normebenen früh kartiert, spart später Zeit bei Audits, Prüfungen und Vorfallbearbeitung.

Für das Management ist dabei ein Punkt besonders wichtig: Mehr Regulierung bedeutet nicht automatisch mehr Sicherheit. Sicherheit entsteht erst, wenn dieselben Kontrollen wiederverwendbar definiert werden. Ein gutes Berechtigungskonzept, eine belastbare Notfallorganisation, geübte Krisenkommunikation, dokumentierte Drittparteiensteuerung und regelmäßige Schulung erfüllen meist mehrere Regime zugleich. Eine Bank sollte deshalb kein separates NIS2-, DORA-, BAIT- und PSD2-Silo aufbauen, sondern eine gemeinsame Steuerungslogik.

Checkliste für Bankenwesen-Unternehmen

Banken, Sparkassen und Zahlungsdienstleister sollten NIS2 im Finanzsektor mit einer kompakten Umsetzungsroutine angehen. Diese Reihenfolge ist für die Praxis am belastbarsten:

1. Regulatorische Hauptlogik bestimmen: Prüfen Sie, welche Einheiten unmittelbar unter DORA fallen und wo ergänzende NIS2- beziehungsweise BSIG-Pflichten relevant bleiben.
2. Kritische Dienste priorisieren: Erfassen Sie Kernbanksystem, Online-Banking, Mobile Banking, Zahlungsverkehr, Authentifizierung, Kartenprozesse, Wertpapier- und Meldeanwendungen in einer gemeinsamen Kritikalitätslogik.
3. Drittparteien kartieren: Bewerten Sie Rechenzentren, Kernbankanbieter, Cloud-Services, API-Provider, Identitätsdienste und externe Administratorzugriffe nach Kritikalität und Ausfallwirkung.
4. Meldearchitektur definieren: Legen Sie fest, welche Vorfälle an BaFin, welche nach DORA, welche im PSD2-Kontext und welche ergänzend unter dem BSIG oder gegenüber dem BSI relevant sind.
5. Leitungsorgan und Schlüsselrollen schulen: Schulen Sie Vorstand, Informationssicherheit, Compliance, Auslagerungsmanagement, Zahlungsverkehr, Betrieb und Krisenkommunikation mit klaren Rollen- und Eskalationsrechten.
6. Nachweise konsolidieren: Führen Sie Policies, Tests, Risikoanalysen, Übungen und Schulungsnachweise in einer Form zusammen, die für Revision, Aufsicht und externe Prüfer wiederverwendbar ist.
7. Schnittstellen regelmäßig üben: Testen Sie nicht nur technische Wiederanläufe, sondern auch Behördenkommunikation, Kundenkommunikation und die Zusammenarbeit mit ausgelagerten IKT-Dienstleistern.

Wenn Sie diese Punkte ohne Parallelstrukturen aufsetzen wollen, ist eine spezialisierte NIS2-Schulung für Unternehmen der schnellste Einstieg. Für Banken ist besonders wichtig, dass Schulung nicht nur Artikel erklärt, sondern DORA-Abgrenzung, BaFin-Praxis, Meldewege und Drittparteiensteuerung in einen gemeinsamen Ablauf übersetzt.

FAQ

Ist mein Bankunternehmen von NIS2 betroffen?

Banken und Kreditinstitute gehören zum regulierten Finanzsektor. In der Praxis müssen Sie aber zuerst prüfen, ob DORA als vorrangiger Spezialrahmen greift. NIS2 bleibt dennoch für die Einordnung des Gesamtregimes, die nationale Umsetzung in Deutschland und ergänzende Governance- und Organisationsfragen relevant.

Gilt NIS2 oder DORA für Banken?

Für viele Banken gilt DORA als Lex Specialis für digitale operationale Resilienz. NIS2 wird dadurch nicht bedeutungslos, sondern wirkt ergänzend fort. Praktisch sollten Banken deshalb mit einer Abgrenzungsmatrix arbeiten statt mit einer pauschalen Entweder-oder-Antwort.

Was müssen Banken zusätzlich zu DORA für NIS2 tun?

Banken sollten ergänzende Pflichten aus BSIG, Registrierungslogik, Leitungsschulung, Dokumentation und gegebenenfalls Behördenkommunikation prüfen. Außerdem sollten sie ihre Vorfall- und Governance-Prozesse so gestalten, dass sie nicht nur DORA-konform, sondern auch im nationalen NIS2-Kontext belastbar sind.

Welche Aufsichtsbehörde ist für Banken zuständig?

Im laufenden Aufsichtsverhältnis ist vor allem BaFin maßgeblich. Für die deutsche NIS2-Umsetzung und bestimmte Registrierungs- oder Meldepflichten ist zusätzlich das BSI relevant. Genau deshalb müssen Banken behördliche Zuständigkeiten nicht vereinfachen, sondern präzise abbilden.

Wie hängen MaRisk, BAIT und NIS2 zusammen?

MaRisk und BAIT konkretisieren für Banken die Anforderungen an Governance, IT, Auslagerung und Notfallmanagement. NIS2 setzt den sektorübergreifenden Cybersicherheitsrahmen, während DORA für viele Finanzunternehmen die speziellere Resilienzlogik vorgibt. Im Ergebnis müssen diese Ebenen zusammengeführt werden.

Müssen Banken Vorfälle doppelt melden?

Das kann je nach Sachverhalt erforderlich sein. DORA, BaFin-Vorgaben, PSD2-bezogene Meldepflichten und ergänzende BSIG- beziehungsweise BSI-Bezüge sind nicht automatisch deckungsgleich. Ein abgestimmter Mehrkanal-Meldeprozess ist deshalb im Bankenwesen sinnvoll.

Wie hängen MaRisk, BAIT und NIS2 mit Schulungspflichten zusammen?

Alle drei Ebenen setzen voraus, dass Zuständigkeiten praktisch wahrgenommen werden können. Schulung ist deshalb kein Nebenprodukt. Vorstände, Sicherheitsverantwortliche, Auslagerungsmanagement, Zahlungsverkehr und Krisenkommunikation müssen die regulatorischen Überschneidungen verstehen, um im Vorfall belastbar handeln zu können.

Fazit für Banken und Kreditinstitute

Für das NIS2 Bankenwesen ist die wichtigste Botschaft klar: DORA hat im Finanzsektor Vorrang, aber NIS2 verschwindet nicht. Banken müssen vielmehr mehrere Regime in einer gemeinsamen Resilienz- und Governance-Architektur zusammenführen. Wer nur auf Einzelvorschriften schaut, unterschätzt die eigentliche Herausforderung des Bankenwesens.

Die pragmatische Reihenfolge lautet deshalb: DORA-Abgrenzung klären, kritische Bankdienste und Drittparteien kartieren, Meldewege definieren, Nachweise konsolidieren und Schlüsselrollen dokumentiert schulen. Wenn Sie dafür einen belastbaren Einstieg suchen, ist unsere NIS2-Schulung der passende nächste Schritt.