DORA, NIS2 oder beides? – So finden Unternehmen den richtigen Fokus

DORA, NIS2 oder beides? – So finden Unternehmen den richtigen Fokus

Man hört es inzwischen auf fast jeder Konferenz und liest es in beinahe jeder Vorstandsvorlage: NIS2 und DORA sind gekommen, um zu bleiben. Zwei europäische Regelwerke, zwei unterschiedliche juristische Instrumente, ein gemeinsames Ziel: Europas digitale Widerstandskraft deutlich erhöhen. Auf den ersten Blick wirken beide wie Geschwister – beide verlangen strukturiertes Risikomanagement, Meldeprozesse, technische und organisatorische Schutzmaßnahmen, Verantwortlichkeit des Managements sowie einen klaren Blick auf die Lieferkette. Wer aber tiefer einsteigt, merkt schnell: Es sind keine Zwillinge, sondern eher zwei präzise Werkzeuge mit unterschiedlicher Klinge. NIS2 spannt den großen Bogen über viele Sektoren und Kategorien kritischer und wichtiger Einrichtungen; DORA wählt den chirurgischen Schnitt in das Betriebssystem der Finanzbranche und ihrer ICT-Dienstleister – inklusive Aufsicht über kritische Drittanbieter. Wer beides gleichzeitig erfüllen muss, steht vor der Aufgabe, Überschneidungen klug zu nutzen und Unterschiede bewusst zu adressieren. Genau darum geht es in diesem Beitrag: Was unterscheidet NIS2 und DORA, wo überlappen sie, und wie setzt man sie mit möglichst wenig Reibungsverlusten um?

Warum jetzt? Das gemeinsame „Warum“ hinter NIS2 und DORA

Beide Regelwerke sind Antworten auf eine Realität, die niemand mehr wegdiskutieren kann: Cyberangriffe sind zum Betriebsrisiko Nummer eins geworden, Lieferketten sind verwundbar, kritische Dienste hängen an digitaler Infrastruktur, die teils über Jahre zu wenig priorisiert wurde. Dazu kommt eine europäische Zielsetzung, Abhängigkeiten zu reduzieren und Mindeststandards hochzuziehen, damit ein Ausfall nicht zum Dominoeffekt wird. NIS2 setzt dabei in der Breite an und will, dass jeder kritische oder wichtige Player in Europa ein Mindestniveau erreicht – von Energie bis Gesundheit, von Verkehr bis Digitalinfrastruktur. DORA nimmt die Finanzbranche in den Fokus, weil operationale Resilienz dort unmittelbar systemrelevant ist: Ein stundenlanger Ausfall von Zahlungsverkehr, Börsenhandel oder Marktinfrastruktur ist weit mehr als eine Unannehmlichkeit.

NIS2 in der Praxis: Breit, grundlegend, national verankert

Die Network and Information Security Directive 2 (Richtlinie (EU) 2022/2555) ist ein klassisches EU-Instrument: Sie verpflichtet Mitgliedstaaten, bestimmte Ziele zu erreichen, lässt ihnen aber Spielraum in der konkreten nationalen Ausgestaltung. Dadurch entstehen nationale Gesetze und Behördenprozesse, die im Detail voneinander abweichen können, auch wenn der inhaltliche Kern identisch bleibt. NIS2 unterscheidet zwischen „wesentlichen“ (essential) und „wichtigen“ (important) Einrichtungen und deckt zahlreiche Sektoren ab – Energie, Transport, Gesundheit, Trinkwasser, digitale Infrastruktur und öffentliche Verwaltung zählen zu den ganz zentralen. Darüber hinaus fallen u. a. Post- und Kurierdienste, Abfallwirtschaft, Herstellung bestimmter Güter, Lebensmittelproduktion oder digitale Dienste wie Cloud- und Rechenzentrumsbetreiber in den Anwendungsbereich.

Im Zentrum von NIS2 stehen vier Stränge: Risikomanagement, Meldepflichten, Lieferkettensicherheit und Governance/Schulung. Praktisch heißt das: Ein Unternehmen muss seine wesentlichen Dienste identifizieren, Risiken für diese Dienste methodisch bewerten, geeignete technische und organisatorische Maßnahmen auswählen (Verschlüsselung, Patch- und Vulnerability-Management, Zugriffs- und Identitätskontrollen, Backup- und Wiederanlaufkonzepte, Monitoring), seine Lieferkette in diese Bewertung einbeziehen und seine Mitarbeitenden sensibilisieren. Dazu kommen verbindliche Meldefristen für signifikante Sicherheitsvorfälle: frühe Erstmeldung, Zwischenbericht, Abschlussbericht – häufig wird als Referenz 24 Stunden (Frühwarnung), 72 Stunden (Zwischenbericht) und ein Monat (Abschluss) genannt, die konkrete nationale Ausgestaltung kann einzelne Details, Schwellenwerte und Zuständigkeiten präzisieren. Wichtig: NIS2 verankert Verantwortung im Management. Geschäftsleitungen müssen sicherstellen, dass die Vorgaben umgesetzt werden – und haften bei groben Pflichtverletzungen.

DORA im Detail: Tiefgang, sektor-spezifisch, direkt geltend

Die Digital Operational Resilience Act (Verordnung (EU) 2022/2554) ist keine Richtlinie, sondern eine EU-Verordnung – sie gilt unmittelbar und einheitlich in allen Mitgliedstaaten. Zielgruppe sind Finanzunternehmen im weiten Sinn (Banken, Versicherer, Wertpapierfirmen, Zahlungs- und E-Geld-Institute, Krypto-Dienstleister, zentrale Marktinfrastrukturen) sowie ihre ICT-Drittanbieter. DORA geht dort tiefer als NIS2, wo die Finanzaufsicht schon traditionell detaillierter ist: ICT-Risikomanagement wird granular beschrieben, Meldungen über schwere ICT-Vorfälle werden harmonisiert, Szenariotests bis hin zu threat-led penetration testing (TLPT) sind verbindlich, und es entsteht eine europäische Aufsicht über kritische Drittanbieter (z. B. Cloud-Hyperscaler für den Finanzsektor). DORA „überschreibt“ vorhandene Leitlinien (z. B. der ESAs) nicht vollständig, sondern integriert sie in einen verbindlichen Rahmen und sorgt für gleiche Standards in der EU. Und auch hier gilt: Verantwortung der Geschäftsleitung ist ausdrücklich normiert.

In der täglichen Umsetzung zeigt sich DORA als Betriebssystem für Resilienz: Es verlangt Inventare wesentlicher Funktionen, Abhängigkeiten, klare Rollen und Verantwortlichkeiten, Metriken und Grenzwerte, durchgängige Change-/Release-Prozesse, Kontinuitäts- und Krisenübungen, eine Klassifikation von Vorfällen und abgestimmte Meldewege zu den zuständigen Behörden. In der Lieferkette setzt DORA bei den Verträgen an: Pflichtklauseln für Audit- und Zugangsrechte, Unterbeauftragte, Exit-Strategien, Datenlokation, Sicherheitsanforderungen, Incident- und Schwachstellenmeldungen – und im Fall kritischer Drittanbieter eine aufsichtliche Überwachung auf EU-Ebene.

Gemeinsames Fundament – ein integrierbarer Kern

NIS2 und DORA teilen einen großen gemeinsamen Nenner. Wer eines ernsthaft umsetzt, baut wertvolle Vorarbeit für das andere:

• Strukturiertes Risikomanagement mit Bezug zu Geschäftsprozessen und kritischen Diensten/Funktionen.
• Dokumentierte Incident-Prozesse inkl. Erkennung, Eindämmung, Beseitigung, Wiederanlauf und Lessons Learned.
• Maßnahmenkatalog (technisch/organisatorisch): IAM/PAM, Verschlüsselung, Netzwerksegmentierung, Patch-/Vulnerability-Management, Logging/SIEM, Backup/Restore, Härtung, Secure Development.
• Lieferkettensicherheit: Risikoanalyse, Mindestanforderungen, Vertragsbausteine, Nachweise, Auditrechte.
• Schulung und Awareness: rollenspezifische Trainings, Phishing-Simulationen, Notfallübungen.
• Wirksamkeitskontrollen: KPIs/KRIs, regelmäßige Reviews, interne Audits.

Der Unterschied liegt in der Detailtiefe und Aufsichtstiefe. NIS2 lässt Freiräume (die national gefüllt werden), DORA spezifiziert Prozesse, Formate und Zuständigkeiten viel genauer – und zwar einheitlich.

Wo es auseinanderläuft – und was das praktisch bedeutet

Geltungsbereich: NIS2 ist branchenübergreifend, DORA exklusiv für den Finanzsektor (einschließlich seiner kritischen ICT-Drittanbieter).
Rechtsnatur: NIS2 ist Richtlinie (braucht nationale Umsetzung), DORA Verordnung (gilt direkt).
Detailtiefe: DORA ist präskriptiver (z. B. TLPT-Pflichten, harmonisierte Meldeformate), NIS2 prinzipienbasiert.
Aufsicht: DORA schafft EU-weite Aufsichtsmechanismen (insb. über kritische Drittanbieter), NIS2 setzt primär auf nationale Behörden.
Tests/Übungen: DORA schreibt explizite Resilienztests vor (inkl. Bedrohungs-emulierten Tests), NIS2 belässt die Tiefe eher bei den Mitgliedstaaten bzw. dem Stand der Technik.

Praktische Konsequenz für Finanzunternehmen, die zugleich NIS2-„essential/important“ sind: DORA erfüllt große Teile von NIS2 mit, aber eben nicht alles. Es bleiben Lücken zu schließen, etwa bei nationalen Meldewegen nach NIS2, Sektorbesonderheiten außerhalb des Finanzkerns oder bei behördenspezifischen Nachweiserwartungen.

Doppel-Compliance ohne doppelten Aufwand – ein integrierter Ansatz

Wer beides braucht, baut am besten ein gemeinsames Cyber-Resilience-Framework. Der Trick ist, einmal zentral zu denken und zweimal sauber zu belegen.

1) Gemeinsame Gap-Analyse: Anforderungen aus DORA und NIS2 in einer Matrix nebeneinanderlegen. Markieren, was identisch ist (z. B. Patch-Prozess, IAM-Grundsätze), was ähnlich (z. B. Meldeschwellen, aber unterschiedliche Formate/Empfänger) und was exklusiv (z. B. TLPT nach DORA). Ergebnis: Abdeckungsgrad und Restlücken.

2) Harmonisiertes Rahmenwerk: Bauen Sie ein integriertes GRC-Gerüst (Governance, Risk, Compliance), das beides trägt: Risikoprozess, Policies/Standards, Kontrollkatalog, Rollen-/RACI, Metriken, Auditpfad. Nutzen Sie Referenzen wie ISO/IEC 27001/27002, NIST CSF 2.0, CIS Controls als „Spine“. DORA-Spezifika (TLPT, harmonisierte Meldungen) docken dort an, NIS2-Spezifika (nationale Meldewege, Kategorien/Benennungen) ebenso.

3) Zentrale Steuerung: Setzen Sie ein interdisziplinäres Programmteam aus IT, Security, Risk, Recht/Compliance, Einkauf/Vendor-Management, Fachbereichen. Das Team verantwortet Priorisierung, Architektur der Dokumentation, Behördenkommunikation und Roadmap.

4) Einheitliche Dokumentation: Erstellen Sie Artefakte, die zweifelsfrei zu beiden Prüfungen passen:
– Policy-Set (z. B. Information Security Policy, Vulnerability/Patch Policy, Cryptography, Access Control, Secure Development, Incident Management, Backup/BCM).
– Standard- und Prozessdokumente (Change, Release, Monitoring, Logging, Forensik, Crisis Management, Third-Party Risk).
– Kontrollnachweise (Protokolle, Ticket-IDs, Reports, Testbelege, Drill-Ergebnisse).
– Vorlagen für Meldungen (NIS2-Fristen 24/72/30, DORA-harmonisierte Formate), Playbooks mit adressatengerechten Kommunikationsflüssen.

5) Contract-Playbook für Drittanbieter: Ein Bausteinkatalog für ICT-Verträge mit Pflichtklauseln: Audit-/Inspektionsrechte, Sicherheitsanforderungen, Meldepflichten, Sub-Outsourcing-Regeln, Datenstandorte, Exit/Portabilität, BIA-/Resilienzanforderungen, Mitwirkung gegenüber Aufsicht. Für DORA-kritische Anbieter ergänzen Sie aufsichtliche Kooperationspflichten.

6) Test-Strategie: Bauen Sie ein dreistufiges Testregime:
– Kontrollen testen (regelmäßige Wirksamkeitschecks).
– Notfall-/BCM-Übungen (Tabletop bis Vollübung mit IT-Wiederanlauf).
– Technische Red-Team/TLPT-Tests nach DORA-Leitplanken (an TIBER-EU angelehnt), risikobasiert alle x Jahre, inklusive Remediation-Nachweisen.

7) Reporting & KPIs/KRIs: Einheitliche Kennzahlen, die Management und Aufsicht verstehen: MTTD/MTTR, Patch-SLA-Erfüllung, Schwachstellen-Backlog, MFA-/PAM-Abdeckung, Backup-Restore-Erfolg, Vendor-Risk-Scores, Übungs-Coverage, Vorfall-Klassifikationen. DORA verlangt harte Sichtbarkeit; NIS2 erwartet Wirksamkeitskontrolle – dieselbe Datenbasis trägt beide.

Meldepflichten synchronisieren – ohne zwei Uhren zu tragen

Die größte Stolperfalle ist oft Reporting. NIS2 gibt ein zeitliches Raster (Frühwarnung, Zwischen-, Abschlussbericht) und adressiert nationale Stellen. DORA wiederum verlangt harmonisierte Meldungen bei schweren ICT-Vorfällen an die zuständigen Finanzaufsichten, inklusive einheitlicher Formate und Klassifizierung. Die Lösung ist ein Vorfall-„Router“: ein zentrales Incident Desk, das anhand von Schwellenwerten und Taxonomien (Auswirkungen auf Verfügbarkeit, Integrität, Vertraulichkeit, Dienstunterbrechung, Kundeneffekt, geografische Streuung, rechtliche Implikationen) automatisiert feststellt, wer wann wie zu informieren ist – intern (Management, Datenschutz, Kommunikation) und extern (Aufsichten, CSIRTs, ggf. Kunden/Partner). Hinterlegen Sie Vorlagen mit Pflichtfeldern, trainieren Sie Sprecher und definieren Sie Fallback-Wege (z. B. wenn ein Meldeportal ausfällt).

Lieferkette ganz praktisch – vom Fragebogen zur messbaren Kontrolle

Sowohl NIS2 als auch DORA verlangen mehr als wohlmeinende Lieferantenfragebögen. Drittpartei-Risiko muss quantifizierbar und steuerbar werden. Ein praxistauglicher Ansatz:

• Segmentieren Sie Lieferanten nach Kritikalität für wesentliche Dienste/Funktionen (BIA-Bezug).
• Definieren Sie Minimum Controls je Kritikalitätsklasse (MFA, Logging, Verschlüsselung, EDR, Patch-SLAs, Incident-Meldung ≤ x Stunden, BCM-Nachweise, Sub-Outsourcing-Approval, Exit-Plan).
• Vertraglich fixieren und prüfen: Onboarding-Due-Diligence, laufende Assurance (z. B. SOC 2/ISO 27001-Berichte, Pentest-Summaries, Zertifikate), Stichproben-Audits und technische Kontrollen (z. B. CASB/Cloud Security Posture Management, Attack Surface Management für externe Assets).
• Messbar machen: Vendor-Scorecards mit Trends, Eskalationskaskaden, Remediation-Fristen.

Technik ist nicht alles – aber ohne Technik ist alles nichts

Regelwerke schreiben selten konkrete Produkte vor, aber sie implizieren eine Mindestarchitektur. Was in beiden Welten wirkt:

• Identity & Access Management mit MFA, rollenbasierten Rechten, PAM für privilegierte Konten, regelmäßigen Rezertifizierungen.
• Endpoint Detection & Response (EDR) und SIEM/SOAR für Korrelation, Alarme, Playbooks und forensische Nachvollziehbarkeit.
• Netzwerksegmentierung/Zero-Trust-Prinzipien, TLS überall, starke Kryptografie mit Schlüsselmanagement, Härtung von Systemen.
• Patch- und Vulnerability-Management mit klaren SLAs (z. B. „kritisch“ ≤ 7 Tage) und Nachverfolgung.
• Backup-/Restore-Strategie nach 3-2-1-Prinzip, immutable Kopien, regelmäßige Restore-Tests mit Messwerten.
• Secure-SDLC: SAST/DAST, Dependency-Scanning, SBOM-Pflege, Secrets-Management, Code-Reviews, Branch-Policies.
• BCM/DR-Automatisierung: Runbooks, Infrastrukturas-Code-Wiederanlaufpfade, Übungs-Telemetry.

People & Governance – die Orchestrierung macht den Unterschied

Nichts davon funktioniert ohne klare Rollen. Organisieren Sie entlang der Three Lines:
1. Linie (IT/Business): betreibt, setzt um, verantwortet Controls im Alltag.
2. Linie (Risk/Compliance/Security): gibt Rahmen, misst Wirksamkeit, fordert nach.
3. Linie (Interne Revision): prüft unabhängig, bewertet Reife und Einhaltung.

Verankern Sie Vorstand/GL-Verantwortung: regelmäßige Resilienz-Reports, Risikodialog, Budgetentscheidungen, Priorisierung von Remediation-Projekten. DORA wie NIS2 zielen ausdrücklich auf Management-Accountability – gelebte Governance reduziert nicht nur Sanktionen, sondern macht das Programm tragfähig.

Übungen, die wirklich Resilienz bauen – nicht nur Häkchen setzen

Üben ist Pflicht. Aber bitte realitätsnah. Kleine Tabletop-Szenarien (Ransomware in der Außenstelle, gestohlene Admin-Credentials, Cloud-Region-Ausfall, Zero-Day in Kern-Komponente) trainieren Entscheidung und Kommunikation. Technische Drills testen Wiederanlaufzeiten und Monitoring-Wirksamkeit. TLPT (DORA) bringt die Feuerprobe: Ein bedrohungs-geleitetes Team versucht, das zu tun, was echte Gegner tun. Der echte Wert entsteht nachher: Remediation mit Terminen, Verantwortlichen und Verifikation.

Zeitplan mit Augenmaß – 12 Monate, die sich lohnen

Ein möglicher, praxiserprobter Fahrplan für Unternehmen, die NIS2 und DORA parallel adressieren:

Monat 1–2: Scoping, Regulatorik-Mapping, Stakeholder-Setup, Gap-Analyse (High-Level), Quick-Wins identifizieren.
Monat 3–4: Policy-Refresh, Rollen/RACI, Incident-Router entwerfen, Melde-Vorlagen, erste Vendor-Segmentation.
Monat 5–6: Kontrollen schärfen (IAM/PAM, Patch-SLA, Backup-Tests), SIEM-Use-Cases, Schulungen ausrollen, Dokumentation standardisieren.
Monat 7–8: DORA-Spezifika: TLPT-Planung, wichtige Funktionen inventarisieren, Contract-Playbook finalisieren. NIS2-Spezifika: nationale Meldewege, Behördenkontakte klären.
Monat 9–10: Erste integrierte Übungen (BCM/Incident), Vorfall-Router testen, Vendor-Audits piloten, Metriken konsolidieren.
Monat 11–12: Interne Vorprüfung (Mock-Audit), Nacharbeiten, Management-Bestätigung, Plan für kontinuierliche Verbesserung.

Dokumentation, die Prüfungen standhält – ohne Papierlawinen

Erstellen Sie eine „Audit Readiness Box“:
– Policy-Set (freigegeben, versionsgeführt),
– Prozesslandkarte mit Verantwortlichen,
– Kontroll-Nachweise (Monats-/Quartalsreports, Ticket-IDs, Log-Ausschnitte, Restore-Protokolle),
– Risikoregister mit Bezügen zu Controls,
– Vendor-Dossiers (Vertrag, Due-Diligence, Nachweise),
– Übungs-/Testberichte inkl. Maßnahmenplänen,
– Melde-Historie (falls vorhanden),
– Board-Minutes zu Resilienzthemen.

Wichtig ist Rote-Faden-Lesbarkeit: Ein Prüfer muss vom Risiko zur Maßnahme, zum Nachweis und zur Governance in wenigen Klicks gelangen.

Häufige Stolpersteine – und wie man sie umgeht

• Zu spät an Reporting gedacht: Erst Vorfall, dann Frage „Wer meldet wohin?“ – vermeiden durch Incident-Router und Vorlagen.
• Vertragliche Lücken: Kritische Dienstleister ohne Audit-/Exit-Rechte – vermeiden durch Contract-Playbook und Nachverhandlung priorisierter Verträge.
• Technik ohne Menschen: SIEM ohne Use-Cases, EDR ohne Playbooks – vermeiden durch Use-Case-Katalog und Runbooks.
• Silo-Programme: NIS2-Team und DORA-Team bauen Parallelwelten – vermeiden durch integriertes Programm mit gemeinsamem Kontroll-Katalog.
• Schulungen als Pflichtübung: Einmal im Jahr E-Learning reicht nicht – besser rollenspezifisch, phasenweise, mit Simulationsanteil.
• Unklare Verantwortlichkeiten: Niemand „own’t“ den Patch-Backlog – lösen durch RACI, Deadlines, Transparenz im Management-Reporting.

Beispiel aus der Praxis – Integration zahlt auf Effizienz ein

Ein europaweit tätiger Versicherer verband seine NIS2-Umsetzung mit DORA, indem er ein gemeinsames Cyber-Resilience-Framework definierte. Technische Basiskontrollen (Monitoring, Patch-Management, Zugriff) wurden einheitlich ausgerollt, Vendor-Management auf DORA-Klauseln umgebaut und für NIS2-Zwecke erweitert (weite Lieferkette). Die DORA-spezifischen Teile (TLPT, harmonisierte Meldungen) legte man als Module obenauf. Entscheidend war die Dokumentationsarchitektur: ein zentrales Confluence/Share-System mit klaren Artefakt-IDs, sodass jede Prüfung – ob nach NIS2 (national) oder DORA (aufsichtlich) – aus denselben Nachweisen bedient werden konnte. Ergebnis: konsistente Compliance, geringere Projektkosten und eine Resilienz, die nicht auf Papier, sondern im Betrieb sichtbar war.

Rechtssicherheit vs. Beweglichkeit – so bleibt man aktuell

NIS2 lebt von nationaler Umsetzung; Details wie Zuständigkeiten, Schwellenwerte oder Formulare können variieren. DORA tritt einheitlich an, wird aber durch technische Standards (RTS/ITS) konkretisiert. In der Praxis helfen drei Dinge:

1. Ein Regulatory Watch (intern oder über Partner), der Änderungen früh erkennt.
2. Versionierte Policies/Standards, die Anpassungen nachvollziehbar machen.
3. Schulungen und Drills, die neue Anforderungen kurzfristig in den Alltag überführen.

Ethik und Kultur – der unterschätzte Hebel

Resilienz ist nicht nur Technik und Papier. Sie ist Kultur: Wie offen sprechen Teams über Fehler? Wird ein Fast-Incident als „gerade nochmal gut gegangen“ abgehakt oder als Lernmoment dokumentiert? DORA wie NIS2 fordern Wirksamkeit – die erreicht man nur, wenn Security nicht als „Compliance-Korsett“ erlebt wird, sondern als Enabler. Ein CISO, der in die Produkt-/IT-Teams geht, frühe Design-Reviews anbietet und Metriken in den Business-Kontext übersetzt, baut genau diese Brücke.

Fazit: Kein Entweder-oder – die Kunst des Sowohl-als-auch

DORA und NIS2 verfolgen dasselbe Ziel: weniger Ausfälle, schnellere Erholung, robustere Lieferketten, höhere Vertrauenswürdigkeit. Sie unterscheiden sich in Zielgruppe, Detailtiefe und Aufsicht, aber sie sind komplementär. Für viele Unternehmen – insbesondere Finanzinstitute und deren IT-Dienstleister – bedeutet das nicht „eines auswählen“, sondern beides integrieren. Wer klug vorgeht, spart Aufwand, vermeidet Doppelarbeit und erhöht zugleich die tatsächliche Betriebsresilienz.

Der Weg dahin ist weder mystisch noch übermäßig bürokratisch, wenn man ihn architektonisch denkt: ein Rahmen, ein Kontroll-Katalog, eine Datenbasis für KPIs, ein Vorfall-Router, ein Vertrags-Baukasten, ein Übungsplan – und darüber die spezifischen Module von NIS2 (national) und DORA (sektorspezifisch). So wird aus zwei Regelwerken eine Strategie: weniger Feuerwehr, mehr Brandschutz; weniger Häkchen, mehr Wirkung. Und das ist am Ende genau das, was beide Regulierungen wollen: Resilienz, die man nicht nur nachweisen, sondern auch spüren kann – im täglichen Betrieb, in der Krise und im Vertrauen der Kundinnen und Kunden.