DORA (Digital Operational Resilience Act) ist die Verordnung (EU) 2022/2554 über die digitale operationale Resilienz im Finanzsektor. DORA verpflichtet Finanzunternehmen und ihre IKT-Dienstleister, Risiken der Informations- und Kommunikationstechnologie systematisch zu steuern, schwerwiegende Vorfälle fristgebunden zu melden, ihre Widerstandsfähigkeit regelmäßig zu testen und Drittanbieterrisiken vertraglich abzusichern. Die Verordnung gilt unmittelbar in allen EU-Mitgliedstaaten seit dem 17. Januar 2025.

Was ist DORA?

DORA schafft erstmals einen einheitlichen europäischen Rechtsrahmen dafür, dass der Finanzsektor auch bei schwerwiegenden IT-Störungen handlungsfähig bleibt. Der Ausgangspunkt der Verordnung ist eine Verschiebung in der Aufsichtslogik: Finanzregulierung war jahrzehntelang vor allem auf Kapitalausstattung ausgerichtet, also auf die Fähigkeit, finanzielle Verluste zu tragen. DORA ergänzt diese Perspektive um die operative Dimension – ein Institut kann hervorragend kapitalisiert und dennoch handlungsunfähig sein, wenn seine Kernsysteme über Tage ausfallen.

Der englische Begriff digital operational resilience ist in Art. 3 Nr. 1 DORA rechtlich definiert als die Fähigkeit eines Finanzunternehmens, seine operative Widerstandsfähigkeit gegenüber IKT-bezogenen Störungen aufzubauen, zu gewährleisten und zu überprüfen. Bemerkenswert ist der dreiteilige Zuschnitt dieser Definition: Sie verlangt nicht nur Aufbau und Aufrechterhaltung, sondern ausdrücklich auch die Überprüfung. Ein dokumentierter, aber nie getesteter Resilienzrahmen erfüllt die Anforderung nicht.

DORA ist eine EU-Verordnung und gilt damit unmittelbar, ohne dass ein nationales Umsetzungsgesetz erforderlich wäre. Flankiert wird sie von der Richtlinie (EU) 2022/2556, die bestehende Finanzmarktrichtlinien an DORA anpasst, sowie von zahlreichen technischen Regulierungs- und Durchführungsstandards (RTS und ITS), die die europäischen Aufsichtsbehörden EBA, EIOPA und ESMA erarbeitet haben. Ein erheblicher Teil der praktisch relevanten Detailanforderungen – etwa zu Meldeinhalten, zum Informationsregister oder zur Klassifizierung von Vorfällen – steht nicht im Verordnungstext selbst, sondern in diesen nachgelagerten Rechtsakten.

Seit wann gilt DORA?

DORA gilt seit dem 17. Januar 2025. Die Verordnung wurde am 14. Dezember 2022 verabschiedet, trat Anfang 2023 in Kraft und sah eine Übergangsfrist von 24 Monaten vor, in der Finanzunternehmen ihre Prozesse, Verträge und Testprogramme anpassen sollten.

Wichtig für die Praxis ist, dass mit dem Geltungsbeginn keine weitere Schonfrist verbunden war: Die Anforderungen an IKT-Risikomanagement, Vorfallsmeldung und Vertragsgestaltung sind seither vollständig anwendbar. Aufsichtlich gestaffelt sind lediglich einzelne Prozesse, etwa die Vorlagetermine für das Informationsregister und die Benennung kritischer IKT-Drittdienstleister durch die europäischen Aufsichtsbehörden. Der aktuelle Stand dieser Termine sollte vor der Anwendung geprüft werden, da die Aufsicht die Fristen fortlaufend konkretisiert.

Für wen gilt DORA?

DORA gilt für rund 20 Kategorien von Finanzunternehmen sowie für IKT-Drittdienstleister, die diese Unternehmen bedienen. Erfasst sind unter anderem Kreditinstitute, Zahlungs- und E-Geld-Institute, Wertpapierfirmen, Anbieter von Krypto-Dienstleistungen, Zentralverwahrer, zentrale Gegenparteien, Handelsplätze, Verwaltungsgesellschaften und Verwalter alternativer Investmentfonds, Versicherungs- und Rückversicherungsunternehmen samt Vermittlern, Einrichtungen der betrieblichen Altersversorgung, Ratingagenturen sowie Schwarmfinanzierungsdienstleister.

Der Anwendungsbereich reicht damit deutlich über Banken hinaus – ein Punkt, der in der Umsetzungspraxis regelmäßig unterschätzt wird. Betroffen sind auch mittelständische Versicherungsvermittler, kleinere Kapitalverwaltungsgesellschaften und Zahlungsdienstleister, die bislang wenig Berührung mit expliziter IT-Aufsicht hatten.

DORA arbeitet allerdings mit dem Grundsatz der Verhältnismäßigkeit. Art. 4 verlangt, dass die Umsetzung Größe, Risikoprofil sowie Art und Komplexität der Dienstleistungen berücksichtigt. Für bestimmte kleinere Unternehmen – etwa kleine und nicht verflochtene Wertpapierfirmen, Kleinstunternehmen unter den Versicherungsvermittlern und kleine Einrichtungen der betrieblichen Altersversorgung – sieht Art. 16 einen vereinfachten IKT-Risikomanagementrahmen vor. Vereinfacht bedeutet dabei nicht befreit: Governance, Schutzmaßnahmen, Vorfallsbehandlung und Kontinuitätsplanung bleiben erforderlich, lediglich der Detaillierungsgrad sinkt.

Welche fünf Säulen umfasst DORA?

DORA ist inhaltlich in fünf Säulen gegliedert, die aufeinander aufbauen: Wer Risiken steuert, muss Vorfälle erkennen und melden; wer meldet, muss vorher getestet haben; und alles zusammen gilt auch für ausgelagerte Leistungen.

Säule	Fundstelle	Kerninhalt
IKT-Risikomanagement	Art. 5–16	Governance durch das Leitungsorgan, IKT-Risikomanagementrahmen, Schutz, Erkennung, Reaktion, Wiederherstellung, Backup und Lernprozesse
Behandlung und Meldung IKT-bezogener Vorfälle	Art. 17–23	Einheitlicher Prozess zur Erfassung, Klassifizierung und fristgebundenen Meldung schwerwiegender Vorfälle
Testen der digitalen operationalen Resilienz	Art. 24–27	Jährliches Basistestprogramm sowie bedrohungsgeleitete Penetrationstests (TLPT) für bedeutende Unternehmen
Management des IKT-Drittparteienrisikos	Art. 28–44	Informationsregister, vertragliche Mindestinhalte, Ausstiegsstrategien, Überwachungsrahmen für kritische Anbieter
Informationsaustausch	Art. 45	Freiwilliger Austausch von Informationen über Cyberbedrohungen zwischen Finanzunternehmen

Praktisch relevant ist, dass die vierte Säule den größten Umsetzungsaufwand erzeugt. IKT-Risikomanagement und Vorfallsbehandlung lassen sich weitgehend intern gestalten; die Anforderungen an Verträge, Register und Ausstiegsfähigkeit verlangen dagegen Verhandlungen mit Dienstleistern, deren Standardverträge häufig nicht DORA-konform sind.

Was verlangt DORA beim IKT-Risikomanagement?

DORA verlangt einen dokumentierten, regelmäßig überprüften IKT-Risikomanagementrahmen, der Strategien, Leitlinien, Verfahren und Werkzeuge zum Schutz aller Informations- und IKT-Assets umfasst. Der Rahmen muss den gesamten Zyklus abdecken: Identifikation kritischer Funktionen und Abhängigkeiten, Schutz und Prävention, Erkennung anomaler Aktivitäten, Reaktion und Wiederherstellung sowie Lern- und Weiterentwicklungsprozesse aus realen Vorfällen und Tests.

Zentral sind dabei die Kontinuitätsanforderungen. Nach Art. 11 und 12 benötigen Finanzunternehmen eine IKT-Geschäftsfortführungsleitlinie mit Reaktions- und Wiederherstellungsplänen, redundante Kapazitäten sowie Backup- und Wiederherstellungsverfahren. Für jede Funktion sind Wiederherstellungszeitziele (RTO) und Wiederherstellungspunktziele (RPO) festzulegen – dieselben Kennzahlen, die auch das Business Continuity Management nach ISO 22301 verwendet. Backup-Systeme müssen dabei physisch und logisch vom Produktivsystem getrennt sein, damit ein Angriff nicht Primär- und Sicherungsdaten zugleich erfasst.

Die Verantwortung ist eindeutig zugewiesen. Art. 5 Abs. 2 legt fest, dass das Leitungsorgan die Letztverantwortung für das IKT-Risikomanagement trägt, den Rahmen genehmigt, dessen Umsetzung überwacht und ausreichende Ressourcen bereitstellt. Zusätzlich verlangt die Verordnung, dass die Mitglieder des Leitungsorgans ihre Kenntnisse im Bereich IKT-Risiken durch regelmäßige Schulungen aktuell halten. In der Praxis ist dies der Punkt, an dem DORA sich am deutlichsten von rein technischen Regelwerken unterscheidet: Die Verordnung adressiert nicht die IT-Abteilung, sondern die Geschäftsleitung.

Wie müssen IKT-Vorfälle nach DORA gemeldet werden?

DORA verlangt einen einheitlichen Prozess, mit dem IKT-bezogene Vorfälle erfasst, klassifiziert und – sofern sie als schwerwiegend eingestuft werden – in drei Stufen an die zuständige Behörde gemeldet werden. Maßgeblich sind die Art. 17 bis 19 sowie die ergänzenden technischen Standards.

Die Klassifizierung erfolgt nach den Kriterien des Art. 18: Zahl der betroffenen Kunden und Gegenparteien, Dauer und Ausfallzeit, geografische Ausbreitung, Auswirkungen auf Verfügbarkeit, Authentizität, Integrität und Vertraulichkeit von Daten, Kritikalität der betroffenen Dienste sowie die wirtschaftlichen Auswirkungen. Erst wenn definierte Schwellenwerte überschritten sind, gilt ein Vorfall als schwerwiegend und löst die Meldekette aus.

Meldestufe	Frist	Inhalt
Erstmeldung	innerhalb von 4 Stunden nach Klassifizierung als schwerwiegend, spätestens 24 Stunden nach Kenntnisnahme	Grundinformationen zum Vorfall und zur ersten Einschätzung
Zwischenmeldung	innerhalb von 72 Stunden nach der Erstmeldung	Aktualisierter Status, Auswirkungen, ergriffene Maßnahmen
Abschlussmeldung	spätestens einen Monat nach der letzten Zwischenmeldung	Ursachenanalyse, Gesamtauswirkung, dauerhafte Abhilfemaßnahmen

Diese Fristen haben eine organisatorische Konsequenz, die über die IT hinausreicht. Vier Stunden reichen nicht, um Zuständigkeiten erst im Ereignisfall zu klären. Meldepflichtige Rollen, Entscheidungswege, Vorlagen und Zugänge zu den Meldeportalen müssen vorbereitet und geübt sein – und sie müssen auch dann funktionieren, wenn der Vorfall die eigene IT-Infrastruktur betrifft. Erschwerend kommt hinzu, dass parallel weitere Meldepflichten greifen können, etwa nach Art. 33 DSGVO bei einer Verletzung des Schutzes personenbezogener Daten.

Zusätzlich sieht DORA vor, dass erhebliche Cyberbedrohungen auf freiwilliger Basis gemeldet werden können, und verpflichtet Finanzunternehmen, betroffene Kunden zu informieren, wenn ein schwerwiegender Vorfall deren finanzielle Interessen berührt.

Welche Tests der digitalen operationalen Resilienz verlangt DORA?

DORA verlangt zwei Teststufen. Alle erfassten Finanzunternehmen müssen ein Programm zum Testen der digitalen operationalen Resilienz unterhalten und kritische IKT-Systeme mindestens jährlich prüfen. Das Spektrum umfasst nach Art. 25 unter anderem Schwachstellenbewertungen und -scans, Open-Source-Analysen, Netzwerksicherheitsbewertungen, Lückenanalysen, Überprüfungen der physischen Sicherheit, Kompatibilitäts-, Leistungs- und End-to-End-Tests sowie Penetrationstests.

Die zweite Stufe sind bedrohungsgeleitete Penetrationstests, im Verordnungstext als Threat-Led Penetration Testing (TLPT) bezeichnet. Sie sind mindestens alle drei Jahre durchzuführen und betreffen nur diejenigen Unternehmen, die von den zuständigen Behörden anhand von Risiko- und Systemrelevanzkriterien dafür benannt werden. TLPT orientiert sich am europäischen Rahmenwerk TIBER-EU: Getestet werden produktive Systeme unter realistischen Angriffsszenarien, abgeleitet aus aktueller Bedrohungsaufklärung, wobei die operativen Teams des Instituts in der Regel nicht vorab informiert sind.

Der methodische Unterschied zu klassischen Penetrationstests ist wesentlich. Ein herkömmlicher Test prüft, ob eine Schwachstelle existiert. TLPT prüft, ob die Organisation einen realistischen Angriff bemerkt, richtig einordnet und beherrscht – geprüft wird also die Erkennungs- und Reaktionsfähigkeit, nicht nur die technische Härtung. Kritische IKT-Drittdienstleister müssen an solchen Tests mitwirken, sofern sie Systeme betreiben, die in den Testbereich fallen.

Was verlangt DORA beim Management des IKT-Drittparteienrisikos?

DORA verlangt, dass Finanzunternehmen ihre IKT-Dienstleisterbeziehungen vollständig erfassen, vertraglich absichern und für den Fall eines Anbieterausfalls handlungsfähig bleiben. Grundlage ist ein Informationsregister aller vertraglichen Vereinbarungen über die Nutzung von IKT-Dienstleistungen, das laufend aktuell zu halten und der Aufsicht vorzulegen ist. Das Register unterscheidet dabei zwischen Dienstleistungen, die kritische oder wichtige Funktionen unterstützen, und dem übrigen Bezug.

Art. 30 legt die vertraglichen Mindestinhalte fest. Für alle IKT-Verträge gehören dazu unter anderem eine vollständige Leistungsbeschreibung, die Angabe der Orte der Datenverarbeitung und Datenspeicherung, Bestimmungen zu Verfügbarkeit, Integrität und Vertraulichkeit von Daten, Unterstützungsleistungen bei IKT-Vorfällen sowie Kündigungsrechte und Kündigungsfristen. Bei kritischen oder wichtigen Funktionen kommen weitergehende Anforderungen hinzu: quantitative Leistungsziele, uneingeschränkte Zugangs-, Inspektions- und Auditrechte, Bedingungen für die Unterauftragsvergabe, die Mitwirkung an Sicherheitsschulungen und Tests sowie dokumentierte Ausstiegsstrategien, die einen Anbieterwechsel ohne Unterbrechung der Geschäftstätigkeit ermöglichen.

Neu ist die europäische Aufsicht über die Anbieter selbst. Die europäischen Aufsichtsbehörden benennen besonders bedeutende Anbieter als kritische IKT-Drittdienstleister und unterstellen sie einem Überwachungsrahmen mit einer federführenden Überwachungsbehörde. Diese kann Informationen anfordern, Untersuchungen und Vor-Ort-Prüfungen durchführen und Empfehlungen aussprechen; bei anhaltender Nichtbefolgung sind Zwangsgelder von bis zu einem Prozent des durchschnittlichen weltweiten Tagesumsatzes vorgesehen, die über einen Zeitraum von bis zu sechs Monaten täglich verhängt werden können.

Erfahrungsgemäß liegt die größte Hürde nicht im Register, sondern in der Ausstiegsstrategie. Konzentrationsrisiken bei wenigen großen Cloud- und Kernbankenanbietern lassen sich nicht durch Vertragsklauseln auflösen, sondern nur durch Architekturentscheidungen – Datenportabilität, dokumentierte Schnittstellen und getestete Migrationspfade.

Welche Anforderungen stellt DORA an die Krisenkommunikation?

DORA behandelt Kommunikation als eigenständige regulatorische Anforderung und nicht als Nebenaspekt der Vorfallsbehandlung. Art. 14 verpflichtet Finanzunternehmen, Krisenkommunikationspläne zu erstellen, die eine verantwortungsvolle Offenlegung schwerwiegender IKT-Vorfälle oder erheblicher Schwachstellen gegenüber Kunden, Gegenparteien und der Öffentlichkeit ermöglichen. Zusätzlich ist mindestens eine Person zu benennen, die die Kommunikationsstrategie umsetzt und als Ansprechpartner gegenüber Öffentlichkeit und Medien fungiert.

Ergänzend verlangen die Reaktions- und Wiederherstellungspläne nach Art. 11 Kommunikationsverfahren für das interne Personal, für externe Interessenträger und für die Aufsicht. Damit ergibt sich eine Struktur mit drei Adressatenkreisen, die im Ereignisfall gleichzeitig und mit unterschiedlichen Inhalten bedient werden müssen: die interne Krisenorganisation, die Aufsichtsbehörden innerhalb der Meldefristen und die betroffenen Kunden.

Die praktische Schwierigkeit liegt in der Abhängigkeit dieser Kommunikation von genau der Infrastruktur, die der Vorfall betrifft. Wird ein kompromittiertes Netzwerk isoliert oder das Mailsystem vorsorglich abgeschaltet, entfallen Verzeichnisdienst, E-Mail und Kollaborationsplattform als Koordinationswege – und mit ihnen die Kontaktdaten und Eskalationslisten, die dort abgelegt sind. Organisationen halten deshalb vorab freigegebene Kommunikationskanäle bereit, die unabhängig von der potenziell betroffenen IKT-Infrastruktur funktionieren, revisionssicher dokumentieren und in den Tests nach Art. 24 ff. mitgeprüft werden. Fehlt ein solcher Kanal, weichen Beteiligte erfahrungsgemäß auf private Consumer-Messenger aus – mit Folgen für Vertraulichkeit, DSGVO-Konformität und die Nachweisfähigkeit gegenüber der Aufsicht.

Wie sich ein von der regulären IT unabhängiger Kanal für Alarmierung, Krisenstabsarbeit und Meldeprozesse abbilden lässt, zeigt Teamwire in einer Demo oder im kostenlosen Test.

Wie unterscheidet sich DORA von NIS-2, BAIT und ISO-Normen?

DORA unterscheidet sich von benachbarten Regelwerken durch Sektor, Rechtsnatur und Detailtiefe – und verdrängt einen Teil von ihnen. Gegenüber der NIS-2-Richtlinie ist DORA die speziellere Regelung: Für Finanzunternehmen gehen die Anforderungen der Verordnung den allgemeinen NIS-2-Vorgaben vor, sodass in den von DORA abgedeckten Bereichen kein paralleles Regime gilt.

Regelwerk	Geltungsbereich	Verhältnis zu DORA
NIS-2-Richtlinie (EU) 2022/2555	Wesentliche und wichtige Einrichtungen in 18 Sektoren, national umzusetzen	DORA ist für den Finanzsektor die speziellere Regelung und geht vor
BAIT, VAIT, KAIT, ZAIT	Nationale aufsichtliche Anforderungen der BaFin an die IT	Weitgehend durch DORA abgelöst; nationaler Anwendungsstand ist zu prüfen
ISO/IEC 27001	Zertifizierbares Informationssicherheits-Managementsystem	Freiwilliger Standard; gute Grundlage, ersetzt DORA-Pflichten aber nicht
ISO 22301 / BSI-Standard 200-4	Business-Continuity-Managementsystem	Liefert Methodik für die Kontinuitätsanforderungen der Art. 11 und 12
DSGVO	Schutz personenbezogener Daten	Eigenständige Meldepflicht nach Art. 33; läuft parallel zu DORA
KRITIS-Regulierung	Betreiber kritischer Infrastrukturen	Sektorübergreifende Versorgungssicherheit statt Finanzmarktstabilität

Für die Umsetzung folgt daraus ein pragmatischer Ansatz: Wer bereits ein zertifiziertes Informationssicherheits-Managementsystem und ein funktionierendes Business Continuity Management betreibt, erfüllt einen erheblichen Teil der DORA-Anforderungen bereits methodisch. Die Lücken liegen typischerweise in drei Bereichen – dem Informationsregister, den vertraglichen Anpassungen mit Dienstleistern und der Fähigkeit, die Meldefristen tatsächlich einzuhalten.

Welche Sanktionen drohen bei Verstößen gegen DORA?

DORA überlässt die Sanktionierung von Finanzunternehmen den Mitgliedstaaten, verlangt aber wirksame, verhältnismäßige und abschreckende Maßnahmen. Das Instrumentarium der zuständigen Behörden reicht nach Art. 50 von Anordnungen zur Abstellung eines Verstoßes über die Aufforderung, Praktiken zu unterlassen, bis hin zu öffentlichen Bekanntmachungen und finanziellen Sanktionen. In Deutschland liegt die Zuständigkeit bei der BaFin.

Eigenständig geregelt sind dagegen die Zwangsgelder gegenüber kritischen IKT-Drittdienstleistern, die den Empfehlungen der federführenden Überwachungsbehörde nicht folgen. Sie können täglich für bis zu sechs Monate verhängt werden und betragen bis zu einem Prozent des durchschnittlichen weltweiten Tagesumsatzes des Anbieters.

Praktisch relevanter als der Bußgeldrahmen ist jedoch die aufsichtliche Konsequenz. Da DORA Nachweise über Tests, Register und Meldeprozesse verlangt, wird die Umsetzung Bestandteil der laufenden Aufsicht und der Prüfungen – Feststellungen wirken sich damit unmittelbar auf das Verhältnis zur Aufsicht aus, unabhängig davon, ob eine Sanktion verhängt wird.

Was sind typische Fehler bei der DORA-Umsetzung?

Der häufigste Fehler bei der DORA-Umsetzung ist die Behandlung als IT-Projekt mit Enddatum. DORA verlangt einen Regelbetrieb aus Analyse, Test, Meldung und Nachweis; ein einmalig aufgesetzter Rahmen veraltet mit jeder Vertragsänderung und jeder neuen Anwendung. Weitere Schwachstellen aus der Umsetzungspraxis:

unvollständiges Informationsregister, weil Fachbereiche IKT-Dienstleistungen direkt beziehen und diese nie zentral erfasst wurden
Altverträge mit Dienstleistern, die die Mindestinhalte des Art. 30 nicht enthalten und deren Nachverhandlung Monate beansprucht
Ausstiegsstrategien, die als Dokument existieren, aber nie auf technische Machbarkeit geprüft wurden
Meldeprozesse ohne benannte Rollen und Vertretungsregelungen, die die Vier-Stunden-Frist im Ereignisfall nicht halten
Verengung auf die Cloud, während Kernbankensysteme, Rechenzentrumsdienstleister und spezialisierte Fachanwendungen unbeachtet bleiben
Krisenkommunikation, die vollständig auf E-Mail und Kollaborationsplattform aufsetzt und im IKT-Vorfall selbst betroffen ist
fehlende Verzahnung mit bestehenden Managementsystemen, sodass ISMS, BCM und DORA-Rahmen dieselben Sachverhalte dreifach dokumentieren

Zusammenfassung: Wichtige Punkte zu DORA

DORA (Digital Operational Resilience Act) ist die Verordnung (EU) 2022/2554 über die digitale operationale Resilienz im Finanzsektor und gilt unmittelbar in allen EU-Mitgliedstaaten seit dem 17. Januar 2025.
DORA erfasst rund 20 Kategorien von Finanzunternehmen – von Kreditinstituten über Versicherungen und Kapitalverwaltungsgesellschaften bis zu Krypto-Dienstleistern – sowie deren IKT-Drittdienstleister.
Die Verordnung ruht auf fünf Säulen: IKT-Risikomanagement, Vorfallsmeldung, Resilienztests, Management des IKT-Drittparteienrisikos und freiwilliger Informationsaustausch.
Das Leitungsorgan trägt nach Art. 5 die Letztverantwortung für das IKT-Risikomanagement und muss seine Kenntnisse zu IKT-Risiken regelmäßig schulen lassen.
Schwerwiegende IKT-Vorfälle sind dreistufig zu melden: Erstmeldung binnen vier Stunden nach Klassifizierung, Zwischenmeldung binnen 72 Stunden, Abschlussmeldung binnen eines Monats.
Bedrohungsgeleitete Penetrationstests (TLPT) nach dem TIBER-EU-Rahmenwerk sind mindestens alle drei Jahre durchzuführen, betreffen aber nur behördlich benannte Unternehmen.
Für IKT-Dienstleister verlangt DORA ein Informationsregister, vertragliche Mindestinhalte nach Art. 30 und dokumentierte, technisch belastbare Ausstiegsstrategien.
Kritische IKT-Drittdienstleister unterliegen einem europäischen Überwachungsrahmen mit Zwangsgeldern von bis zu einem Prozent des durchschnittlichen weltweiten Tagesumsatzes.
Gegenüber NIS-2 ist DORA die speziellere Regelung; nationale IT-Anforderungen der Aufsicht wie BAIT und VAIT wurden für erfasste Unternehmen weitgehend abgelöst.
Krisenkommunikationspläne sind nach Art. 14 verpflichtend, einschließlich einer benannten verantwortlichen Person und geregelter Kommunikationswege gegenüber Personal, Aufsicht und Kunden.