Die NIS2 Richtlinie verpflichtet Firmen, die in einen der regulierten Sektoren fallen und größer als der Grenzwert (Size Cap) sind, dazu:

Hinsichtlich dieser Sicherheitsanforderungen nennt NIS2 selbst lediglich einige grundlegende Eckpunkte. Die Maßnahmen müssen auf einem gefahrenübergreifenden Ansatz beruhen, der sowohl digitale Bedrohungen als auch die physische Sicherheit von IT-Systemen abdeckt.

Zudem nennt NIS2 einige Themen, die mindestens abgedeckt werden müssen: Risikoanalysen, der Umgang mit Sicherheitsvorfällen, Business Continuity, Sicherheit der Lieferkette, Security Awareness, Verschlüsselung, Zugriffskontrolle sowie Multi-Faktor-Authentifizierung.

Mit der Veröffentlichung im Bundesgesetzblatt am 5. Dezember 2025 ist das Umsetzungsgesetz zu NIS2 in Deutschland mit über einem Jahr Verspätung nun offiziell in Kraft getreten.

Da es keine Übergangsfristen für regulierte Unternehmen gibt, müssen sich betroffene Betriebe nun unmittelbar bei den für sie zuständigen Behörden registrieren und mit der Umsetzung der nötigen Sicherheitsmaßnahmen beginnen.

NIS2 in Deutschland: Was sind die nächsten Schritte?

Die Umsetzung von NIS2 in Österreich erfolgt über das NISG 2026, das am 12. Dezember 2025 offiziell verkündet wurde. Aufgrund einer längeren Übergangsfrist tritt das Gesetz jedoch erst mit Oktober 2026 in Kraft.

Anschließend haben betroffene Unternehmen 3 Monate für die Registrierung bei dem neu geschaffenen Bundesamt für Cybersicherheit und 12 Monate, um erstmals den Nachweis über die Wirksamkeit ihrer Risikomanagementmaßnahmen zu erbringen.

Seit dem 27.06.2024 liegt ein erster Entwurf für einen Durchführungsrechtsakt vor, in dem die EU die Sicherheitsanforderungen in NIS2 konkretisiert. Dieser Rechtsakt gilt nur für IT-Dienstleister, da diese Branche nicht von Mitgliedsstaaten, sondern direkt von der EU reglementiert wird.

Dennoch erlaubt der Durchführungsrechtsakt einen ersten Einblick in die genauen Anforderungen von NIS2. Die Vorgaben für andere Branchen müssen erst durch Verordnungen auf nationaler Ebene festgelegt werden, dürften aber in Umfang und Strenge sehr ähnlich ausfallen.

Zur Einhaltung von NIS2 müssen Organisationen eine Sicherheitsrichtlinie erstellen, die ihre Vorgehensweise bei der Absicherung ihres Netzwerks und ihrer IT-Systeme beschreibt. Die Richtlinie muss für die Ziele der Organisation angemessen sein, die zur Erfüllung notwendigen Ressourcen bereitstellen und entsprechende Rollen und Verantwortungen festlegen.

Die Sicherheitsrichtline muss in regelmäßigen Abständen, sowie nach erheblichen Vorfällen oder Veränderungen der IT überprüft und bei Bedarf angepasst werden. Die Richtlinie muss auch weitere relevante Dokumente und themenspezifische Policies auflisten.

Regulierte Betriebe müssen ein Risikomanagement-Framework etablieren, mit dem sie Risiken für die Sicherheit von IT-Systemen identifizieren und behandeln. Dazu müssen Risiko-Assessments durchgeführt werden. Die Geschäftsleitung muss die darauf aufbauenden Maßnahmen absegnen beziehungsweise die verbleibenden Restrisiken akzeptieren.

Organisationen müssen Prozesse für die Identifikation und den Umgang mit Risiken an ihre Belegschaft kommunizieren. Der Risikomanagement-Prozess muss einem gefahrenübergreifenden Ansatz folgen, auf relevanten Kriterien aufbauen und, soweit möglich, an gängige Standards anknüpfen. Der Risikomanagement-Prozess muss auch festlegen, wer für die Implementierung der Maßnahmen verantwortlich ist. Auch das Risk Management Framework muss regelmäßig sowie nach Vorfällen und Veränderungen überprüft und aktualisiert werden.

Organisationen müssen die Einhaltung der Sicherheitsrichtlinie und weiteren Policies regelmäßig durch ein Compliance-Monitoring System kontrollieren. Die Effektivität der Sicherheitsrichtlinie ist von qualifizierten Personen und unter Vermeidung von Interessenskonflikten zu überprüfen.

Von NIS2 betroffene Betriebe müssen eine Richtlinie für den Umgang mit Sicherheitsvorfällen erstellen, die den korrekten Ablauf für die Erkennung und den Umgang mit möglichen Vorfällen regelt.

In der Incident Handling Policy wird festgelegt, wer zuständig für die Erkennung und Reaktion auf Vorfälle ist, welche Maßstäbe für die Klassifizierung von Vorfällen gelten, welche Maßnahmen gesetzt werden müssen und welche Berichtspflichten zu erfüllen sind – etwa an Behörden und nationale CSIRTs.

Die Reaktion auf IT-Vorfälle erfolgt in drei Stufen: Die Eindämmung, welche die weitere Ausbreitung verhindert. Die Behebung, die ein erneutes bzw. fortlaufendes Auftreten des Vorfalls verhindert. Und die Wiederherstellung des normalen Betriebs.

Maßnahmen bei der Bewältigung von IT-Vorfällen müssen aufgezeichnet und forensisch relevante Daten gesichert werden. Nach einem Vorfall muss seine Ursache festgestellt und wenn möglich behoben werden. Bei einem Post-Incident Review müssen zudem mögliche Verbesserungen der Notfallprozesse identifiziert werden. Auch Notfallpläne müssen regelmäßig getestet werden.

NIS2 verpflichtet Betreiber, die Aktivitäten ihrer IT-Systeme durch geeignete Tools zu überwachen um mögliche Vorfälle schnell zu erkennen und darauf reagieren zu können. Das Monitoring soll automatisiert ablaufen. Die Auswertung und Klassifizierung von relevanten Ereignissen obliegt jedoch der Organisation.

Ereignisse werden in einem Event Log aufgezeichnet und ausgewertet. Dazu zählen:

Das Event Log wird zentral gespeichert, gegen unberechtigten Zugriff abgesichert und durch regelmäßige Backups vor Verlust geschützt. Betreiber schaffen zudem einen Prozess, der es Kunden, Mitarbeitern oder Zulieferern erlaubt, verdächtige Ereignisse zu melden.

Zur Erfüllung von NIS2 müssen regulierte Betriebe einen Notfallplan erstellen, der die Betriebsfortführung (Business Continuity) und Wiederherstellung des Normalbetriebs (Disaster Recovery) abdeckt. Darin sind Rollen, Aufgaben, Abläufe, wichtige Kontakte, benötigte Ressourcen und genaue Wiederherstellungspläne geregelt. Der Notfallplan muss auf einer Risiko- und Business-Impact-Analyse aufbauen und regelmäßig getestet werden.

Firmen müssen Backups ihrer Daten anlegen, diese sicher verwahren, ihre Integrität prüfen und durch regelmäßige Tests sicherstellen, dass die angelegten Kopien für eine Wiederherstellung ausreichen. Auch bei Personal und IT-Infrastruktur muss das Unternehmen für genügend Redundanz sorgen, um die Ausfallsicherheit zu gewährleisten.

Supply Chain Security ist eines der größten Fokusthemen der NIS2 Richtlinie. Betroffene Firmen müssen den Umgang mit Zulieferern und Dienstleistern über eine Supply Chain Policy regeln, die notwendige Vertragsbestimmungen sowie Kriterien für die Auswahl von Dienstleistern festlegt.

Bei der Auswahl von Zulieferern müssen Firmen unter NIS2 die Sicherheitspraktiken des jeweiligen Dienstleisters in Betracht ziehen sowie durch Diversifizierung die Abhängigkeit von einzelnen Anbietern minimieren (Vendor Lock-In). Firmen müssen zudem ein Verzeichnis sämtlicher direkter Zulieferer und Dienstleister anlegen. Dieses muss auch im Unternehmen verwendete IT-Produkte abdecken.

Darüber hinaus definiert NIS2 Anforderungen an Service-Level-Agreements (SLAs) mit Zulieferern. Diese müssen Anforderungen an die personelle und IT-Sicherheit festlegen, die auch bei Auftragsweitergabe bestehen. Zulieferer müssen sich verpflichten, Vorfälle umgehend zu melden, die die IT-Systeme des Kunden gefährden, und entsprechende Schwachstellen zu beheben. Organisationen erhalten das Recht, Zulieferer zu auditieren oder Einblick in unabhängige Audits zu erhalten. Die Einhaltung des Service Level Agreements ist laufend zu überwachen.

Von NIS2 regulierte Organisationen müssen Sicherheitsrisiken durch die Nutzung von IT-Produkten und Dienstleistungen minimieren, indem sie:

Ebenso ist bei der Entwicklung eigener Software auf sichere Development-Prozesse und Vorgaben wie Security by Design und Zero Trust zu achten.

Für die sichere Nutzung von IT-Produkten müssen Firmen diese durch die richtige Konfiguration abhärten, sich vor Malware schützen, Sicherheitsupdates zeitnah einspielen, Veränderungen durch ein Change Management regeln, Schwachstellenscans durchführen und weitere Sicherheitslücken durch Security Tests identifizieren.

Welche Anforderungen stellt NIS2 an die Cybersicherheit in Unternehmen? Adobe Stock, (c) Goodpics

Zur Erfüllung von NIS2 müssen Organisationen ihr Netzwerk angemessen absichern. Dazu braucht es unter anderem ein aktuelles Netzwerkdiagramm, Zugriffskontrollen innerhalb des eigenen Netzwerks, Prozesse für sicheren Remote-Zugriff, das Sperren nicht benötigter Ports und Zugänge, sowie die Nutzung moderner, sicherer Protokolle.

Darüber hinaus muss das Netzwerk durch Segmentierung in unterschiedliche Bereiche aufgeteilt werden, abhängig von den Sicherheitsanforderungen und Risikoanalysen für verschiedene Systeme.

Aufbauend auf Risikoanalysen und vergangenen Vorfällen müssen Organisationen Prozesse zur Bewertung und Verbesserung der aktuellen Sicherheitsmaßnahmen entwickeln, etwa Security Assessments oder Sicherheitstests. Dazu muss die Organisation festlegen, welche Maßnahmen wie häufig und mit welchen Methoden überprüft werden und wer verantwortlich für die Kontrolle und Auswertung der Ergebnisse ist.

Unternehmen müssen ihre Mitarbeitenden über digitale Risiken, die Wichtigkeit von IT-Security und Praktiken der Cyberhygiene informieren. Dazu sind regelmäßige Schulungen für bestehende und neue Angestellte nötig, die alle relevanten Themen der Sicherheitsrichtlinie abdecken und an aktuelle Gefahren angepasst werden.

Für Mitarbeitende, die zur Erfüllung ihrer Rolle zusätzliche Kenntnisse über Cyber Security benötigen, muss die Organisation ein vertiefendes Trainingsprogramm implementieren.

Abhängig von der Klassifikation von Informationsassets und dem Schutzbedarf der jeweiligen Daten, muss die Organisation geeignete Prozesse zur Verschlüsselung von Daten implementieren. Dabei ist auf den korrekten Umgang und die sichere Verwaltung kryptographischer Schlüssel zu achten.

Von NIS2 regulierte Unternehmen müssen sicherstellen, dass sämtliche Mitarbeiter, sowie direkte Zulieferer und Dienstleister, die für sie gültigen Sicherheitsrichtlinien kennen, verstehen und befolgen. Dies gilt ebenso für die Geschäftsführung und Personen mit privilegierten Konten oder Admin-Zugriff.

Pflichten, die über die Beendigung des Beschäftigungsverhältnisses hinaus bestehen (etwa Verschwiegenheit), müssen vertraglich explizit festgelegt werden. Zugänge ehemaliger Mitarbeiter oder Dienstleister müssen durch Verfahren für die Zugriffskontrolle automatisch entfernt werden.

Zudem kann es notwendig sein, bestimmte Funktionen im Unternehmen nur an Personen mit einem bestandenen Background-Check zu übertragen. Welche Funktionen einen Background-Check voraussetzen, muss die Organisation selbst festlegen. Die Durchführung muss in Einklang mit geltendem Recht erfolgen.

NIS2 verpflichtet Firmen, eine Richtlinie für Zugriffskontrolle (Access Control Policy) zu etablieren, die den Zugriff auf IT-Ressourcen durch Mitarbeitende, Gäste, externe Dienstleister sowie durch Apps und Systemprozesse steuert.

Organisationen müssen den gesamten Lebenszyklus von IT-Systemen und Benutzerkonten managen. Konten und ihre Aktivitäten müssen einer einzelnen Person klar zuordenbar sein. Die Nutzung geteilter Konten ist nur bei zwingender Notwendigkeit und nach Genehmigung durch die Organisation erlaubt.

Der Zugang zu Konten muss durch sichere Authentifizierung geschützt werden, insbesondere Multi-Faktor-Authentifizierung. Nach wiederholten fehlgeschlagenen Logins muss der Zugang gesperrt werden und eine Änderung der Zugangsdaten ist erforderlich. Admins müssen separate Konten für Admintätigkeiten verwenden.

Die Vergabe, Anpassung, Löschung und Dokumentation von Zugriffsrechten muss den Best Practices der Funktionstrennung und des Least Privilege Prinzips folgen. Ändert sich die Rolle eines Mitarbeiters oder verlässt er die Organisation, muss sein Zugriff entsprechend angepasst werden.

Der Zugriff auf IT-Ressourcen muss durch den jeweiligen Dateneigentümer freigegeben werden. Organisationen müssen sämtliche vergebenen Rechte aufzeichnen und in regelmäßigen Intervallen überprüfen – durch sogenannte User Access Reviews. Nicht mehr benötigte Rechte sind dabei zu entfernen.

Organisationen müssen im Rahmen von NIS2 für die sichere Verwaltung von Informationen und sonstigen Assets sorgen. Dazu muss ein Inventar sämtlicher Assets erstellt werden, die den Normalbetrieb der Organisation unterstützen. Das Asset-Inventar muss laufend aktualisiert werden. Dabei muss nachvollziehbar sein, wer welche Änderungen durchgeführt hat.

Die Organisation muss eine Klassifizierung von Assets vornehmen, abhängig von ihrem jeweiligen Schutzbedarf. Es muss eine Richtlinie für den Umgang mit Assets erstellt werden, die den gesamten Lebenszyklus der Daten bzw. Objekte abdeckt und Anweisungen für den sicheren Gebrauch, Transport und Zerstörung von Assets enthält. Beim Austritt aus der Organisation muss sichergestellt werden, dass sämtliche Assets zurückgegeben werden.

Ebenso muss eine Richtline für die Nutzung von Wechseldatenträgern etabliert werden. Die Verwendung tragbarer Speichermedien ist darin grundsätzlich untersagt, außer der Einsatz ist für den Betrieb der Organisation erforderlich. In diesem Fall müssen Firmen das automatische Ausführen von Dateien blockieren und Datenträger auf Schadcode scannen. Datenträger müssen während Transport und Nutzung überwacht und nach Möglichkeit durch Verschlüsselung abgesichert werden.

Der gefahrenübergreifende Ansatz von NIS2 erfordert, regulierte Betriebe auch gegen physische Gefahren abzusichern. Dazu zählt, den unberechtigten Zugang zu Anlagen durch geeignete Schutzmaßnahmen und Zugangskontrollen zu verhindern.

Unternehmen müssen sich zudem gegen Betriebsausfälle infolge einer Störung der Gas-, Wasser- oder Energieversorgung absichern. Um den durchgehenden Betrieb von Informationssystemen zu sichern, müssen Organisationen alle dafür relevanten Faktoren überwachen, etwa Prozesse zur Steuerung von Temperatur und Luftfeuchtigkeit. Ebenso müssen Schutzmaßnahmen gegen physische Gefahren und Naturkatastrophen wie Feuer, Flut oder Blitzschlag getroffen werden.

Die Anforderungen von NIS2 sind weitgehend identisch mit der Sicherheitsnorm ISO 27001. Das ist auch nicht weiter verwunderlich: Beide Dokumente haben das Ziel, eine umfassende Absicherung von IT-Systemen gegen digitale und physische Bedrohungen zu gewährleisten. Bei dieser Aufgabe sind zwangsläufig dieselben Themen von Relevanz.

Dennoch gibt es einige Unterschiede zwischen NIS2 und ISO 27001:

NIS2 ist eine EU-Richtlinie zur Informationssicherheit (Network and Information Security) in essenziellen Bereichen der öffentlichen Versorgung. Sie ersetzt die ursprüngliche NIS-Richtlinie aus dem Jahr 2016 und erweitert diese um strengere Sicherheitsanforderungen, zusätzliche Sektoren und eine höhere Zahl betroffener Betriebe.

Darüber hinaus regelt NIS2 auch nationale Cybersicherheitsbehörden, den Aufbau von Computernotfallteams (CSIRT), EU-weite Initiativen wie den Aufbau eines Schwachstellen-Registers und die Rolle von ENISA als zentrale Anlaufstelle regulierter Organisationen

NIS2 betrifft Betriebe in gesellschaftlich relevanten Sektoren. Die Richtlinie unterscheidet hierbei zwischen besonders wichtigen und wichtigen Einrichtungen, abhängig von der Größe des Unternehmens und dem Tätigkeitsbereich. Experten gehen durch NIS2 von rund 20.000 zusätzlichen regulierten Betrieben in Deutschland und 3.400 Betrieben in Österreich aus.

Um mehrfache Regulierung zu vermeiden, gibt es in NIS2 eine Ausnahme für Einrichtungen, die durch einen anderen EU-weiten Rechtsakt Anforderungen an die Cybersecurity erfüllen müssen, die den Anforderungen von NIS2 mindestens gleichwertig sind.

Beispielsweise müssen Finanzeinrichtungen, die DORA unterliegen, den Nachweis ihrer Informationssicherheit und die Meldung von Vorfällen nur im Rahmen von DORA erbringen. Sie sind also nicht von NIS2 betroffen.

Grundsätzlich stellt NIS2 die gleichen Sicherheitsanforderungen an wichtige und besonders wichtige (=essentielle) Einrichtungen. Allerdings sieht NIS2 auch eine Anpassung des Risikomanagements je nach der Größe einer Einrichtung, der Wahrscheinlichkeit eines Vorfalls und den erwartbaren Folgen für Wirtschaft und Gesellschaft vor.

Darüber hinaus gibt es Unterschiede zwischen wichtigen und besonders wichtigen Einrichtungen hinsichtlich der Durchsetzung von NIS2. Besonders wichtige Einrichtungen unterliegen strengerer Aufsicht und sollen durch regelmäßige Stichproben kontrolliert werden. Im Unterschied dazu gibt es für wichtige Einrichtungen nur Kontrollen bei begründetem Verdacht.

In Deutschland existiert zudem weiterhin die Kategorie der kritischen Anlagen, die sich aus den Sektoren und Schwellenwerten der KRITIS Verordnung bzw. aus dem KRITIS Dachgesetz ergeben. Kritische Anlagen müssen die Einhaltung der NIS2 Anforderungen durch einen Audit alle 3 Jahre nachweisen. Zudem gelten für kritische Anlagen höhere Ansprüche an die Verhältnismäßigkeit und der Einsatz von Systemen zur Angriffserkennung ist für sie explizit vorgeschrieben.

“Bankaufsichtliche Anforderungen an die IT (BAIT)” ist der Titel eines Rundschreibens der Bundesanstalt für Finanzdienstleistungsaufsicht (BaFin), das in seiner ersten Fassung im November 2017 versendet wurde. Hintergrund von BAIT ist der Paragraf 25a des Kreditwesengesetzes (KWG): Darin finden sich besondere organisatorische Pflichten für Finanzinstitute in Bezug auf das Risikomanagement und die Einrichtung interner Kontrollverfahren.

Eine der hier enthaltenen gesetzlichen Pflichten ist die “angemessene personelle und technisch-organisatorische Ausstattung des Instituts”. Da diese Passage jedoch viel Raum zur Interpretation offen lässt, hat die BaFin mit BAIT konkrete Anforderungen definiert, die Kreditinstitute und Finanzdienstleister in Deutschland in Bezug auf ihre Informationssicherheit umsetzen müssen.

Mit dem Digital Operations Resilience Act (DORA) definiert die EU IT-Sicherheitsanforderungen für die Finanzindustrie. Um eine Doppelregulierung zu vermeiden, hat die Finanzaufsicht BaFin die schrittweise Aufhebung von BAIT angekündigt.

Mit dem 17. Januar 2025 sind Organisationen, die ihr IKT-Risikomanagement gemäß DORA betreiben müssen, von BAIT ausgenommen. Mit dem 1. Januar 2027 wird BAIT vollständig aufgehoben, da eine Novelle des Finanzmarktdigitalisierungsgesetzes zeitgleich den Anwenderkreis von DORA erweitert.

Die Rundschreiben VAIT, ZAIT und KAIT (Anforderungen an Versicherungen, Zahlungsdienste und Kapitalverwaltung) werden mit dem 17. Januar 2025 ebenfalls aufgehoben.

Die BAIT-Richtlinie wird schrittweise durch DORA ersetzt. Adobe Stock, (c) Gorodenkoff

Bei MaRisk, den Mindestanforderungen an das Risikomanagement, handelt es sich ebenso um ein Rundschreiben der BaFin, welches das Kreditwesengesetz konkretisiert. MaRisk erfüllt somit eine ähnliche Rolle wie BAIT, wurde jedoch schon 2005 erstmals veröffentlicht und seitdem mehrmals adaptiert, zuletzt durch eine Novelle im Juni 2023.

MaRisk beschäftigt sich jedoch, wie der Name bereits sagt, vor allem mit dem Thema Risikomanagement. Das Dokument behandelt zwar auch technische Vorgaben, diese decken aber nur knapp zwei Seiten ab. Da MaRisk Anforderungen an die IT-Sicherheit nicht im Detail ausführt, entstand der Bedarf für ein spezifisches Dokument zu diesem Thema: das BAIT-Rundschreiben.

Seit der ursprünglichen Veröffentlichung wurde BAIT insgesamt zweimal aktualisiert. Das BAIT-Update aus dem September 2018 ergänzt die Anforderungen um den Abschnitt kritische Infrastrukturen. Darin enthalten sind Maßnahmen zur Erreichung der KRITIS-Schutzziele für den Finanzsektor, die bei vollständiger Umsetzung als Nachweis der Umsetzung der KRITIS-Verordnung und des IT-Sicherheitsgesetzes dienen.

Die aktuelle Version von BAIT wurde im Dezember 2024 veröffentlicht und bereitet das schrittweise Auslaufen der Regulierung vor. Neben dem reduzierten Anwenderkreis von BAIT wurde dazu auch Kapitel 11 aufgehoben. Dieses betrifft die Beziehungen zu Zahlungsdienstleistern, welche ebenfalls durch DORA reguliert werden.

Alle technischen Voraussetzungen zusammengefasst und erklärt. Adobe Stock, (c) onephoto

Als Orientierungshilfe finden Sie im Folgenden eine Zusammenfassung aller 12 Kapitel, die in BAIT enthalten sind. Naturgemäß handelt es sich dabei um eine verkürzte Wiedergabe, die dem Überblick dient, aber nicht alle Forderungen des Dokuments vollständig abdeckt. Bei weiteren Fragen empfiehlt sich der Blick in den vollständigen Text von BAIT, der von der BaFin als PDF-Download angeboten wird.

Dieser Abschnitt gibt der Geschäftsleitung die Verantwortung, eine nachhaltige IT-Strategie festzulegen, die sowohl Ziele als auch konkrete Maßnahmen zur Umsetzung enthält. Vorgesehene Inhalte der IT-Strategie sind unter anderem: die strategische Entwicklung der IT-Architektur und der IT-Abläufe, das Festlegen von Zuständigkeiten in der Organisation, eine Zuordnung, an welchen Standards das Unternehmen sich orientiert, sowie Aussagen zum IT-Notfallmanagement und im Betrieb verwendeten Komponenten (Hardware und Software).

Unter Governance lässt sich sinngemäß die Umsetzung und Einhaltung der zuvor beschriebenen Strategie innerhalb des Unternehmens verstehen. Auch hier liegt die Verantwortung bei der Geschäftsleitung, die dafür sorgen muss, dass Vorgaben zeitnah durchgesetzt bzw. angepasst werden, die betroffenen Fachbereiche mit den nötigen Ressourcen ausgestattet sind und es keine Interessenskonflikte durch unvereinbare Tätigkeiten gibt (etwa Durchführung und Kontrolle durch dieselbe Person). Siehe auch Segregation of Duties.

Teil des Informationsrisikomanagements ist die Einrichtung angemessener Überwachungs- und Steuerungsprozesse, um die Integrität, Verfügbarkeit, Authentizität und Vertraulichkeit von verarbeiteten Daten zu gewährleisten. Um den Schutzbedarf in Bezug auf diese Kategorien regelmäßig ermitteln zu können, müssen Institute stets einen Überblick über alle Bestandteile ihres Informationsverbunds haben (inklusive der Vernetzung mit Dritten). Ebenso ist die laufende Beobachtung, Prüfung und Bewertung von Schwachstellen vorgesehen.

Unter Informationssicherheitsmanagement versteht man Richtlinien und Prozesse, um IT-Sicherheit dauerhaft in einer Organisation zu etablieren. Der Aufbau eines Informationssicherheits-managementsystems steht im Zentrum der Norm ISO 27001 und zählt ebenso zu den Voraussetzungen des BSI-IT-Grundschutzes.

Konkret schreibt BAIT den Beschluss und die interne Kommunikation einer Informationssicherheitsleitlinie vor. Darauf aufbauend sind entsprechende Richtlinien und Prozesse zur Umsetzung zu definieren, sowie ein Informationssicherbeitsbeauftragter zu bestimmen. Dieser ist für die Kontrolle der Einhaltung von Regelungen zur Informationssicherheit zuständig und koordiniert regelmäßige Maßnahmen zur Sensibilisierung des Personals, neben vielen weiteren Aufgaben.

Die notwendigen technischen Schritte, um die Absicherung digitaler Arbeitsabläufe zu gewährleisten, fallen unter das Kapitel Operative Informationssicherheit. Dazu zählen etwa: Schwachstellenmanagement, Perimeterschutz, Netzwerk-Segmentierung und Verschlüsselung von Daten.

Um relevante Sicherheitsvorfälle zu erkennen sind entsprechende Kriterien zu definieren, etwa ein Anstieg nicht autorisierter Zugriffsversuche. Ebenso ist die operative Security regelmäßig durch Schritte wie Schwachstellenscans, Penetrationstests und simulierte Angriffe zu überprüfen.

Die Vorschriften der BaFin sollen die Sicherheit und Integrität von Finanzdaten gewährleisten. Adobe Stock, (c) Ivan

Das Identitäts- und Rechtemanagement (auch als Identity und Access Management bezeichnet) stellt sicher, dass nur berechtigte Benutzer auf IT-Systeme und sensible Daten zugreifen können. BAIT setzt hierbei ein Berechtigungskonzept voraus, welches die Einhaltung der Funktionstrennung sicherstellt und den Zugriff nach dem Sparsamkeitsgrundsatz auf ein Minimum beschränkt. Man spricht auch vom Need-to-Know bzw. Least-Privilege-Prinzip. Um die konsequente Einhaltung dieses Konzepts sicherzustellen, müssen:

Vor wesentlichen Veränderungen an Systemen oder der Inbetriebnahme neuer Komponenten und Anwendungen muss eine Auswirkungsanalyse durchgeführt werden. Bei der Entwicklung neuer Anwendungen sind Ziele hinsichtlich der Funktionalität klar zu dokumentieren und angemessene Vorkehrungen zu treffen, um verarbeitete Daten zu schützen.

Es muss eine Methodik für das Testen von Anwendungen vor ihrer ersten Inbetriebnahme definiert werden, aber auch nach der Aktivierung müssen eigene Projekte und Programme laufend überwacht werden (z.B. Überprüfung des Quellcodes).

Um im laufenden Betrieb den notwendigen Überblick über den Informationsverbund sicherzustellen, müssen Organisationen den Standort der Systeme und ihre Eigentümer (Verantwortlichen) dokumentieren. Systeme sind regelmäßig zu aktualisieren und die Risiken durch nicht mehr unterstützte Programme und Komponenten aktiv zu steuern.

Weitere Aspekte, die den IT-Betrieb von Finanzdienstleistern betreffen, sind etwa die Sicherung von Daten, die Planung des Leistungsbedarfs von Systemen, sowie die Dokumentation von Änderungen und Störungen.

Dieser Abschnitt definiert Anforderungen an den Umgang mit externer Software und Services wie Cloud-Diensten oder Backup-Lösungen. Bei der Auslagerung ist im Vorfeld eine Risikobewertung durchzuführen und auf die Einhaltung des Risikomanagements zu achten. Die Verantwortlichen für Informationssicherheit und Notfallmanagement müssen ebenso in die Auslagerung eingebunden werden, außerdem sind entsprechende Bewertungen regelmäßig zu überprüfen und erneuern.

Institute müssen ein Notfallkonzept definieren, das sowohl die Wiederherstellung der vollen Funktion als auch die Geschäftsfortführung während Notfällen abdeckt. Dazu muss vor allem erfasst werden, welche Abhängigkeiten es in den IT-Systemen und bezüglich externer Dienstleister gibt, sowie welche Ressourcen notwendig sind, um eine eingeschränkte Fortführung zeitkritischer Geschäftsprozesse sicherzustellen. Auch eine jährliche Überprüfung der Wirksamkeit des Notfallplans ist vorgesehen.

Vergangene Fassungen von BAIT haben sich auch mit der Verwaltung der Beziehung zu Zahlungsdienstnutzern befasst, um diese etwa über Sicherheitsrisiken zu informieren oder Kontrollfunktionen zu garantieren (z.B. das Sperren von Auslandsüberweisungen oder Anpassen von Limits).

Im Rahmen des schrittweisen Auslaufens von BAIT ist dieses Kapitel in der aktuellen Fassung aufgehoben.

Dieses Kapitel richtet sich nicht an alle Finanzinstitute, sondern an jene die gemäß der KRITIS-Verordnung als kritische Infrastrukturen eingestuft werden. Diesen Einrichtungen steht es frei, sich bei der Umsetzung angemessener Sicherheitsstandards an internationale Normen zu halten oder einen eigenen bzw. branchenspezifischen Ansatz zertifizieren zu lassen. Daher sind die hier enthaltenen Vorgaben nicht verpflichtend, sondern eine alternative Möglichkeit, um den Nachweis des Schutzes zu erbringen.

Im Wesentlichen handelt sich bei den hier definierten Anforderungen um das Beachten des KRITIS-Schutzziels im Informationsrisiko- und Informationssicherheitsmanagement, sowie den Notfallmaßnahmen. Das Schutzziel ist dabei die durchgehende Aufrechterhaltung des Zahlungsverkehrs und der Bargeldversorgung, die auch im Notfall gewährleistet sein müssen.

Der regulatorische Druck auf Finanzinstitute steigt stetig. Anforderungen an die IT-Sicherheit, die in BAIT ihren Anfang nahmen, werden durch neuere Gesetze wie DORA aufgegriffen und dabei zunehmend erweitert.

Für betroffene Unternehmen ist die Erfüllung dieser Anforderungen mit erheblichem Aufwand verbunden. Nur mit geeigneten Tools lassen sich die strengen Sicherheitsvorgaben erfolgreich umsetzen und der Aufwand für IT-Teams dabei in Grenzen halten.

Ein zentrales Thema: Identitäts- und Rechtemanagement, um sensible Finanzdaten vor unberechtigtem Zugriff zu schützen. Hier erlaubt die automatische Verwaltung mit einer Identity & Access Management Lösung sowohl den betrieblichen Aufwand als auch das Risiko für Fehler zu minimieren.

Mit tenfold lassen sich BAIT Anforderungen im Bereich Identitätsmanagement kinderleicht umsetzen. Adobe Stock, (c) jirsak

In tenfold werden Zugriffsrechte automatisch nach dem Least-Privilege-Prinzip vergeben, welches sowohl zu den Best Practices der Cybersicherheit als auch den BAIT Anforderungen zählt. Dazu setzt tenfold auf rollenbasierte Berechtigungsvergabe: Über Profile können Organisationen je nach Aufgabe und Abteilung Standardrechte für Mitarbeiter festlegen, die tenfold nun selbstständig zuweist. Somit werden Rechte nicht nur automatisch vergeben, sondern auch automatisch wieder entzogen, wenn ein Mitarbeiter die Abteilung wechselt oder das Institut verlässt.

In der Praxis sind neben Standardrechten häufig auch zusätzliche Berechtigungen notwendig. Um bei der Vergabe den Ansprüchen der BaFin zu genügen, erlaubt tenfold das Einrichten von eigenen Genehmigungsworkflows, über die der jeweilige Fachbereich in die Entscheidung eingebunden wird. Zudem können befristete Rechte vergeben werden, die nach Ablauf automatisch wieder erlöschen.

Um die im Finanzbereich essenzielle Trennung zwischen operativem Geschäft und Kontrollfunktionen zu gewährleisten, ermöglicht es tenfold, nicht vereinbare Rechte gegenseitig auszuschließen. Dadurch kann die Funktionstrennung auch über mehrere IT-Systeme hinweg problemlos umgesetzt werden.

Ein Tagging-System für Berechtigungen erlaubt es dabei, ganze Gruppen von Rechten schnell und einfach in Konflikt zueinander zu setzen. Anstatt jeden Einzelfall separat durchzuexerzieren lassen sich so problematische Konstellationen mit wenigen Klicks gegenseitig ausschließen.

Die von BAIT vorgesehene Rezertifizierung von Berechtigungen, also die regelmäßige Überprüfung, ob bestehende Rechte noch benötigt werden, lässt sich dank tenfold schnell und einfach abwickeln. Mithilfe von automatisierten Benachrichtigungen werden die jeweiligen Entscheidungsträger in regelmäßigen Intervallen dazu aufgefordert zu bestätigen, ob Berechtigungen auf Ressourcen in ihrer Verantwortung noch benötigt werden. Veraltete Zugriffsrechte können so mit nur einem Klick entfernt werden.

Sämtliche Änderungen an Berechtigungen, wie etwa die Bestätigung oder Löschung im Rahmen der Rezertifizierung, werden von tenfold vollständig dokumentiert, um die spätere Nachvollziehbarkeit zu gewährleisten. Somit hilft die IAM-Software dabei, BAIT Anforderungen hinsichtlich der Dokumentation (Kapitel 6.6) zu erfüllen und erleichtert den Nachweis der Compliance im Rahmen von Audits.