DORA · IKT-Risikomanagement
Die EZB verlangt von bedeutenden Instituten bis zum 31. Oktober 2026 einen Aktionsplan gegen KI-beschleunigte Cyberangriffe. Für alle übrigen Finanzunternehmen verschiebt sich damit der Maßstab, an dem die Aufsicht das DORA Schwachstellenmanagement misst.
Das EZB-Schreiben begründet keine zusätzlichen DORA-Pflichten, es verschiebt den aufsichtlichen Schwerpunkt. Der Maßstab steht längst fest: Art. 10 der Delegierten Verordnung (EU) 2024/1774 verlangt für IKT-Assets, die kritische oder wichtige Funktionen unterstützen, mindestens wöchentliche automatisierte Schwachstellenscans.
Einordnung im S+P Leistungsmodell: Die Bearbeitung von Schwachstellen-, Dienstleister- und Nachweisprozessen gehört zu den 1st Line Services im Cluster DORA, Auslagerung und Third-Party Operations. Es handelt sich um operative Bearbeitung nach den Vorgaben deines Instituts, getrennt von der Beauftragtenfunktion der zweiten Linie.
Die vier Karten fassen zusammen, wer adressiert ist, was für alle anderen gilt, woran der Maßstab messbar wird und welcher Teil der Arbeit sich übertragen lässt.
Adressat und Frist
Das Schreiben SSM-2026-0301 vom 7. Juli 2026 richtet sich an die Geschäftsleitungen bedeutender Institute. Sie sollen bis zum 31. Oktober 2026 einen Aktionsplan an ihr Joint Supervisory Team übermitteln. Die EZB stellt klar, dass kein neues Regelwerk entsteht: DORA bleibt der maßgebliche Rahmen.
Nicht nur bedeutende Institute
Für weniger bedeutende Institute, Versicherer, Wertpapier- und Zahlungsinstitute folgt aus dem EZB-Schreiben keine Einreichungspflicht. Orientierung geben die Warnung ESRB/2026/3 und die gemeinsame Erklärung von EBA, EIOPA und ESMA vom 31. Juli 2026. Verbindlicher Maßstab bleiben DORA und die Praxis der zuständigen Behörde.
Der Maßstab wird messbar
Die Erwartungen laufen auf bereits geltende Vorgaben zu. Art. 10 DelVO (EU) 2024/1774 verlangt wöchentliche automatisierte Scans für Assets kritischer oder wichtiger Funktionen und die Prüfung, ob IKT-Drittdienstleister kritische Schwachstellen zeitnah melden. Beides ist prüfbar.
Aufgabe und Verantwortung
Scan-Betrieb, Priorisierung, Dienstleisternachweise, Ausnahmeverwaltung und Nachweisdokumentation sind operative Arbeit und auslagerungsfähig. Risikotoleranz, Delegationsgrenzen und Eskalationswege festzulegen bleibt nach Art. 5 Abs. 2 DORA Sache des Leitungsorgans.
Am 7. Juli 2026 hat die EZB-Bankenaufsicht das Schreiben SSM-2026-0301 an die Geschäftsleitungen bedeutender Institute gerichtet. Ausgangspunkt ist die Beobachtung, dass fortgeschrittene KI-Modelle Softwareschwachstellen identifizieren und funktionsfähige Exploits erzeugen können und dadurch die Zeitspanne zwischen Entdeckung und Ausnutzung verkürzen. Die EZB bezeichnet das ausdrücklich als langfristige Verschiebung der Bedrohungslage, nicht als vorübergehendes Phänomen und nicht als Risiko eines einzelnen Werkzeugs.
Entscheidend für die Einordnung ist der zweite Teil dieser Aussage: Die Entwicklungen führen nach Auffassung der EZB keine völlig neuen Risiken ein, sie verstärken Geschwindigkeit und Ausmaß, in denen sich bekannte Risiken verwirklichen. Daraus folgt der Zuschnitt des geforderten Aktionsplans: Er soll auf der bestehenden Cyberrisikostrategie aufsetzen, nicht neben ihr stehen. Kurzfristig nennt die EZB drei Schwerpunkte – Schwachstellen- und Patch-Management in der Fläche beschleunigen, Monitoring und Detection stärken sowie prüfen, ob die Steuerung der IKT-Drittdienstleister der Lage noch angemessen ist. Vorrang haben dabei Perimeter-Technologien und aus dem Internet erreichbare Assets einschließlich Drittsoftware und Open-Source-Komponenten.
Am selben Tag hat der Europäische Ausschuss für Systemrisiken die Warnung ESRB/2026/3 veröffentlicht, angenommen am 25. Juni 2026 und im Amtsblatt der Europäischen Union vom 16. Juli 2026 bekannt gemacht. Der Ausschuss bezeichnet die Entwicklung darin als Paradigmenwechsel im Bereich der Cybersicherheit und sieht in ihr eine Quelle systemischer Risiken für das Finanzsystem der Union.
Am 31. Juli 2026 haben EBA, EIOPA und ESMA mit der gemeinsamen Erklärung JC 2026 25 nachgezogen und einen sektorübergreifenden, risikobasierten Aufsichtsansatz gefordert. Für Finanzunternehmen außerhalb der direkten EZB-Aufsicht ist sie ein sektorübergreifender Hinweis auf die erwartete Aufsichtspraxis; sie richtet sich an alle Finanzunternehmen und ihre zuständigen Behörden, nicht nur an bedeutende Institute. Verbindlicher Maßstab bleiben DORA, die technischen Regulierungsstandards und die Praxis der jeweils zuständigen Behörde.
Keines dieser Dokumente schafft neues Recht. Sie verweisen auf DORA und die zugehörigen technischen Regulierungsstandards, die seit dem 17. Januar 2025 anzuwenden sind. Für das DORA Schwachstellenmanagement heißt das: Der Pflichtenkatalog steht bereits fest, neu ist die Erwartung an Geschwindigkeit und Nachweistiefe. Wer heute prüfungsfest dokumentiert, welche Assets in welcher Frequenz gescannt werden, welche Ausnahmen mit welcher kompensierenden Kontrolle bestehen und wie schnell ein Notfallpatch tatsächlich ausgerollt wird, erfüllt damit zugleich die aufsichtliche Erwartung aus dem Sommer 2026.
Rot markierte Einträge stehen noch aus. Die Angaben zu laufenden Verfahren sind monatsgenau gehalten, geltende Rechtsakte tagesgenau.
Die Verordnung (EU) 2022/2554 und die Delegierte Verordnung (EU) 2024/1774 gelten unmittelbar. Die wöchentliche Scanfrequenz nach Art. 10 DelVO ist seitdem geltendes Recht.
Der Europäische Ausschuss für Systemrisiken nimmt die Warnung ESRB/2026/3 an. Sie wird am 16. Juli 2026 im Amtsblatt der Europäischen Union bekannt gemacht.
Das Schreiben SSM-2026-0301 geht an die Geschäftsleitungen bedeutender Institute. Der ESRB gibt seine Warnung am selben Tag bekannt.
EBA, EIOPA und ESMA veröffentlichen die Erklärung JC 2026 25 und fordern einen sektorübergreifenden, risikobasierten Aufsichtsansatz für IKT-Risiken aus Frontier-KI-Modellen.
Bedeutende Institute übermitteln ihren Aktionsplan an das zuständige Joint Supervisory Team. Die EZB kündigt eine horizontale Auswertung aller eingereichten Pläne an.
Die EZB verschiebt die Frist für die jährliche Erhebung des IT Risk Questionnaire von September 2026 auf Februar 2027, um Kapazitäten für die Schwerpunktthemen freizumachen.
Bevor du Maßnahmen planst, kläre, welches Regime für welchen Teil deines Hauses gilt. Für Finanzunternehmen im Anwendungsbereich von DORA ordnet § 28 Abs. 6 BSIG an, dass die zentralen Pflichten des BSIG nicht gelten. Das Bundesamt für Sicherheit in der Informationstechnik benennt in seinen Fragen und Antworten zu NIS-2 die betroffenen Vorschriften: §§ 30, 31, 32, 35, 36, 38 und 39 BSIG. IKT-Risikomanagement und Vorfallmeldungen laufen für dich also über DORA und die BaFin.
Nicht ausgenommen ist die Registrierungspflicht nach § 33 BSIG. Sie bleibt auch für DORA-regulierte Finanzunternehmen bestehen. Der zweite Pfad betrifft deine Dienstleister: Ein konzerninterner IT-Dienstleister ist nicht automatisch selbst Finanzunternehmen im Sinne der DORA. Erfüllt er die Voraussetzungen des BSIG, treffen ihn dessen Pflichten eigenständig – und als IKT-Drittdienstleister zugleich die vertraglichen Anforderungen aus DORA. Dieser Doppelstatus ist der Regelfall: Eine Konzern-IT-Gesellschaft kann außerhalb des unmittelbaren DORA-Anwendungsbereichs stehen, für dein Haus gleichwohl DORA-relevante Leistungen erbringen und daneben eigenständig dem BSIG unterliegen. Aus der Konzernzugehörigkeit allein folgt die Einordnung nicht.
Diese Weichenstellung hat unmittelbar praktische Folgen für das DORA Schwachstellenmanagement. Sie entscheidet, an welche Behörde ein Vorfall gemeldet wird, welche Nachweise du bei einer Prüfung vorlegen musst und ob ein Dienstleister in deiner Lieferkette doppelt reguliert ist. Kläre die Einordnung schriftlich je Rechtseinheit und je wesentlichem Dienstleister, bevor du Prozesse baust.
Die Zuordnung folgt den Normen, nicht der Aufbauorganisation. Wer in deinem Haus welche Rolle trägt, ist eine Frage der Geschäftsverteilung.
Art. 5 Abs. 2 DORA
Art. 8 DORA, Art. 10 DelVO 2024/1774
Art. 28, 30 DORA, Art. 10 DelVO 2024/1774
Art. 6 DORA
Die folgenden Muster begegnen uns unabhängig von Größe und Geschäftsmodell. Sie ersetzen keine Einzelfallprüfung in deinem Haus.
Art. 10 DelVO (EU) 2024/1774 knüpft die Frequenz an die Klassifizierung nach Art. 8 Abs. 1 DORA und verlangt für Assets kritischer oder wichtiger Funktionen mindestens wöchentliche Scans. Wer einen einheitlichen Rhythmus über alle Systeme fährt, erfüllt die Vorgabe entweder nicht oder verbrennt Kapazität. Ohne belastbare Klassifizierung lässt sich beides nicht auseinanderhalten.
Eine Gesamtquote von 97 Prozent sagt nichts darüber aus, ob die fehlenden drei Prozent ein aus dem Internet erreichbares Portal betreffen. Art. 10 DelVO verlangt die Priorisierung von Patches und die Überwachung der Behebung. Das Reporting muss deshalb nach Exponiertheit und Funktionskritikalität auswerten, nicht nach Stückzahl.
Nicht kurzfristig patchbare Legacy-Systeme sind zulässig, unbefristete Ausnahmen ohne Eigentümer und kompensierende Kontrolle sind es nicht. Die EZB nennt den Ersatz oder die Aktualisierung veralteter und nicht mehr unterstützter Technologien ausdrücklich als strukturelle Maßnahme. Eine Ausnahmeliste ohne Termin ist im Prüfungsgespräch das schwierigste Dokument.
Art. 10 DelVO verlangt die Prüfung, ob Drittdienstleister Schwachstellen angehen und kritische Fälle zeitnah melden. In der Praxis liegt dazu oft nur eine allgemeine Zusage im Vertrag vor, kein Nachweis über tatsächliche Meldungen. Ohne dokumentierte Meldehistorie kannst du die Pflicht nicht als erfüllt darstellen.
Dokumentiert wird häufig, dass ein Patch verteilt wurde, nicht, dass die Schwachstelle geschlossen ist. Art. 10 DelVO verlangt, die Behebung zu überwachen und zu prüfen. Der Unterschied fällt erst auf, wenn ein Folgescan dieselbe Schwachstelle erneut meldet – und dann in der Regel gegenüber der Revision.
Für eine aktiv ausgenutzte Schwachstelle ohne verfügbaren Herstellerpatch entscheidet, wer außerhalb regulärer Change-Fenster eine Einschränkung oder Abschaltung anordnen darf. Steht das nur auf dem Papier, verlierst du genau die Stunden, die die verkürzte Angriffszeitlinie kostet.
Fünf Fragen zur Selbsteinschätzung. Wähle je Frage die Antwort, die am ehesten zutrifft; die Empfehlung erscheint darunter. Die Auswertung bleibt in deinem Browser und wird nicht übertragen.
Die folgenden Schritte sind Empfehlungen aus der Praxis, keine eigenständigen Normpflichten; wo eine Norm dahintersteht, ist sie genannt. Sie wirken unabhängig davon, wie sich die Bedrohungslage und die aufsichtliche Schwerpunktsetzung weiterentwickeln.
Leite die Scanfrequenz aus der Klassifizierung nach Art. 8 Abs. 1 DORA ab und halte je Assetgruppe fest, welche Frequenz gilt und warum. Für Assets kritischer oder wichtiger Funktionen ist die wöchentliche Mindestfrequenz nicht verhandelbar. Diese Maßnahme wirkt unabhängig davon, wie sich die Bedrohungslage weiterentwickelt.
Erweitere das Schwachstellenreporting um die Dimensionen extern erreichbar, privilegiert und kritische oder wichtige Funktion. Damit wird sichtbar, ob offene Fälle dort liegen, wo die EZB den Schwerpunkt setzt. Der Aufwand liegt in der Datenverknüpfung, nicht in neuen Werkzeugen.
Jede Ausnahme bekommt Eigentümer, Begründung, kompensierende Kontrolle, Termin und Ablaufdatum. Verlängerungen werden als eigene Entscheidung dokumentiert. So entsteht die Grundlage, auf der das Leitungsorgan Restrisiken befristet akzeptieren kann.
Fordere für die wesentlichen IKT-Dienstleister die Meldehistorie zu kritischen Schwachstellen an und dokumentiere die Auswertung. Wo die vertragliche Grundlage fehlt, gehört sie in die nächste Vertragsrunde nach Art. 30 DORA. Welche Evidenz genügt, hängt von Kritikalität und Vertragslage ab; ein einheitliches Nachweisformat schreibt die Verordnung nicht vor.
Spiele eine aktiv ausgenutzte Schwachstelle ohne verfügbaren Patch an einem real exponierten System durch. Erzwinge Entscheidungen zu Einschränkung, Abschaltung, Beweissicherung und Kommunikation und protokolliere sie.
Belege die Behebung durch einen Folgescan, nicht durch das Verteilungsprotokoll. Diese Umstellung kostet wenig und schließt eine der häufigsten Feststellungen.
Die Auslagerung verlagert die Aufgabe, nicht die aufsichtsrechtliche Verantwortung. Die Tabelle hält für vier entscheidungsnahe Themen fest, welcher Teil operative Bearbeitung ist und welcher beim Institut bleibt.
Die Zuordnung folgt Art. 5 Abs. 2 DORA: Das Leitungsorgan definiert, genehmigt, überwacht und verantwortet die Umsetzung des IKT-Risikomanagementrahmens.
| Thema | Operative Bearbeitung, auslagerungsfähig | Entscheidung deines Instituts | Bezug |
|---|---|---|---|
| Scanbetrieb und Auswertung | Betrieb der Scans, Normalisierung der Befunde, Priorisierungsvorschlag, Nachverfolgung | Freigabe der Priorisierungslogik und der Risikotoleranz | Art. 10 DelVO 2024/1774 |
| Notfallmaßnahme am System | Sachverhaltsaufnahme, Optionen mit Wirkung und Nebenwirkung, Entscheidungsvorlage | Anordnung von Abschaltung, Einschränkung oder Weiterbetrieb | Art. 5 Abs. 2 DORA |
| Dienstleisterprüfung | Einholen und Auswerten der Nachweise, Lücken- und Vertragsanalyse, Maßnahmenvorschlag | Entscheidung über Fortführung, Nachverhandlung oder Ausstieg | Art. 28, 30 DORA |
| Restrisikoakzeptanz | Aufbereitung von Risiko, kompensierender Kontrolle, Termin und Alternativen | Festlegung der Delegationsgrenzen; Einzelfallentscheidung auf mandatierter Ebene | Art. 5 Abs. 2 DORA |
Auslagerungsfähig ist die Bearbeitung, nicht die Entscheidung. Diese Trennung gehört in den Auslagerungsvertrag und in den Nachweispfad, damit sie in einer Prüfung belegbar ist.
Die Auslagerung verlagert die Aufgabe, nicht die aufsichtsrechtliche Verantwortung; sie bleibt in deinem Institut.
Das EZB-Schreiben vom Juli 2026 schafft kein neues Regelwerk. Es macht sichtbar, welche bestehenden Pflichten die Aufsicht in den nächsten Prüfungen zuerst aufschlagen wird. Für das DORA Schwachstellenmanagement sind das die Klassifizierung der Assets, die daraus abgeleitete Scanfrequenz, die Priorisierung nach Exponiertheit, die Verwaltung von Ausnahmen und die Nachweise deiner Dienstleister.
Für weniger bedeutende Institute und für Unternehmen außerhalb der direkten EZB-Aufsicht besteht keine Pflicht, den Aktionsplan bedeutender Institute nachzubauen. Der Maßstab ergibt sich aus der gemeinsamen Erklärung der ESAs vom 31. Juli 2026 und damit aus denselben DORA-Vorgaben, die ohnehin gelten. Angemessen ist ein dokumentierter, risikobasierter Review der eigenen Lage, kein KI-Sonderprogramm ohne Bezug zum tatsächlichen Risikoprofil.
Die Arbeit daran ist zu einem großen Teil operativ: Daten zusammenführen, Nachweise einsammeln, Fristen überwachen, Dokumentation prüfungsfest halten. Genau dieser Teil lässt sich auslagern. Risikotoleranz, Delegationsgrenzen und Eskalationswege festzulegen bleibt nach Art. 5 Abs. 2 DORA Sache des Leitungsorgans deines Instituts.
Die Antworten geben den Stand von September 2026 wieder und ersetzen keine Rechtsberatung im Einzelfall.
Das hängt von der Aufsichtskategorie ab. Das Schreiben SSM-2026-0301 vom 7. Juli 2026 richtet sich an die Geschäftsleitungen bedeutender Institute unter direkter EZB-Aufsicht und fordert von ihnen einen Aktionsplan an das zuständige Joint Supervisory Team bis zum 31. Oktober 2026. Für weniger bedeutende Institute und für Unternehmen außerhalb der direkten EZB-Aufsicht folgt daraus keine Einreichungspflicht. Orientierung gibt die gemeinsame Erklärung von EBA, EIOPA und ESMA vom 31. Juli 2026; verbindlicher Maßstab bleiben DORA und die Praxis der zuständigen Behörde.
Art. 10 der Delegierten Verordnung (EU) 2024/1774 verlangt, dass Häufigkeit und Umfang der automatisierten Schwachstellenbewertungen der Klassifizierung nach Art. 8 Abs. 1 DORA und dem Gesamtrisikoprofil des Assets entsprechen. Für IKT-Assets, die kritische oder wichtige Funktionen unterstützen, ist mindestens einmal wöchentlich zu scannen. Diese Vorgabe gilt seit Anwendbarkeit der Verordnung und wurde durch das EZB-Schreiben nicht verändert.
Nein. Die EZB hält ausdrücklich fest, dass die Entwicklungen keine völlig neuen Risiken einführen, sondern Geschwindigkeit und Ausmaß verstärken, in denen sich bekannte Risiken verwirklichen. Der geforderte Aktionsplan soll auf der bestehenden Cyberrisikostrategie aufsetzen. Setzt dein Haus selbst KI-Systeme ein, können daneben Anforderungen aus Datenschutz, Informationssicherheit, Modellrisikomanagement und der KI-Verordnung relevant werden; das ist ein eigener Prüfstrang.
Für Finanzunternehmen im Anwendungsbereich von DORA ordnet § 28 Abs. 6 BSIG an, dass die zentralen BSIG-Pflichten nicht gelten; das Bundesamt für Sicherheit in der Informationstechnik nennt dazu die §§ 30, 31, 32, 35, 36, 38 und 39 BSIG. IKT-Risikomanagement und Vorfallmeldungen laufen über DORA und die BaFin. Die Registrierungspflicht nach § 33 BSIG bleibt bestehen. Konzerninterne IT-Dienstleister sind nicht automatisch erfasst, sofern sie nicht selbst Finanzunternehmen im Sinne der DORA sind.
Persönliche Haftung entsteht nicht automatisch durch einen Vorfall oder eine aufsichtliche Feststellung. Bei der Aktiengesellschaft setzt die Innenhaftung nach § 93 Abs. 2 AktG grundsätzlich eine schuldhafte Pflichtverletzung und einen daraus entstandenen Schaden der Gesellschaft voraus; für Geschäftsführer einer GmbH gilt nach § 43 Abs. 2 GmbHG ein entsprechender Maßstab. Eine Feststellung kann aber ein Indiz dafür sein, dass Organisations-, Informations- oder Überwachungspflichten nicht angemessen erfüllt wurden. Maßgeblich bleibt der Einzelfall. Die Organhaftung ist ein eigenständiger Themenblock; sie wird hier nur so weit behandelt, wie sie an die Governance-Pflicht des Art. 5 Abs. 2 DORA anschließt.
Auslagerungsfähig ist die operative Bearbeitung: Betrieb und Auswertung der Scans, Aufbereitung der Priorisierung, Einholen und Prüfen der Dienstleisternachweise, Pflege des Ausnahmeregisters, Fristenüberwachung und prüfungsfeste Dokumentation. Vorab definierte technische Reaktionsmaßnahmen darf ein Dienstleister nach einem freigegebenen Runbook auch selbst auslösen. Beim Institut bleiben müssen die Entscheidungsrechte: Risikotoleranz und Delegationsgrenzen, die Eskalationsschwellen, die Entscheidung über Fortführung oder Ausstieg bei einem Dienstleister und die Verantwortung für wesentliche Betriebs- und Risikoentscheidungen. Die Auslagerung verlagert die Aufgabe, nicht die aufsichtsrechtliche Verantwortung; sie bleibt in deinem Institut.
Primärquellen zuerst: europäische Rechtsakte und Aufsichtsdokumente, danach die nationale Aufsichtspraxis. Je Eintrag steht, wofür die Quelle einsteht.
Hinweis zum Rechtsstand: Dieser Beitrag gibt den Stand von September 2026 wieder und ersetzt keine Rechtsberatung im Einzelfall. Gleiche Angaben zu Normen, Fristen und Anwendungsbereichen vor internen Freigaben gegen die jeweils aktuelle amtliche Fassung ab. Die Paragrafen 93 AktG, 43 GmbHG sowie 28 und 33 BSIG werden ohne Verlinkung zitiert, weil sich für sie in dieser Recherche keine amtliche Volltextquelle abrufen ließ; zum BSIG ist die amtliche Auslegung des Bundesamtes verlinkt.
Die operative Bearbeitung greift in bestehende Prozesse ein. Diese Bausteine schließen an.
Aufbau und Pflege des Informationsregisters nach Art. 28 DORA, einschließlich der Verknüpfung zu Dienstleisternachweisen und Vertragsangaben.
Operative Bearbeitung datenintensiver und fristgebundener Fachprozesse – der Rahmen, in dem Scanauswertung, Ausnahmeregister und Nachweisführung als Service laufen.
Anbieterneutrale Unterstützung bei Datenhaushalt, Schnittstellen und Auswertbarkeit – relevant, wenn Scanner, Assetinventar und Reporting nicht zusammenspielen.
Einordnung von Bearbeitung, Überwachung und Prüfung, damit die Trennung zwischen Vorbereitung und Entscheidung auch organisatorisch trägt.
Risikobasierte Prüfung des IKT-Risikomanagementrahmens nach Art. 6 DORA durch eine unabhängige Funktion.
Governance-, Maßnahmen- und Evidenzregister an einem Ort – der Ablageort für Ausnahmeregister, Nachweise und Maßnahmenverfolgung.
Die Qualifizierungssicht auf dieselbe Frage: Wo endet DORA, wo beginnt NIS-2, und was bedeutet das für dein Team im Tagesgeschäft. Fachbeitrag von S+P Seminare.
Sammlung der Schulungs- und Lehrgangsangebote zu IKT-Risiko, Third Party Risk und digitaler Resilienz, wenn dein Haus die Umsetzung selbst trägt.
Achim Schulz kennt die Führungsebene aus eigener Verantwortung – langjährig als Vorstand bei Banken und Geschäftsführer sowie als Interim-Manager in Industrieunternehmen. Diese Doppelperspektive aus Finanzsektor und Realwirtschaft prägt seine Beiträge für CEO, COO und CFO. Er kennt das Zusammenspiel von Geschäftsleitung, Aufsichtsrat und Gesellschaftern aus der Praxis und übersetzt strategische wie aufsichtsrechtliche Anforderungen in umsetzbare, haftungssichere Führungsentscheidungen – praxisnah und auf Augenhöhe mit dem Management.
LinkedIn-Profil →Wir verwenden Cookies und ähnliche Technologien, um Ihre Erfahrung auf unserer Website zu verbessern. Weitere Informationen in unserer Datenschutzerklärung.