DORA in der Praxis: Wie Crowd-sourced Security digitale Resilienz belegbar macht

Die EU-Verordnung DORA (Digital Operational Resilience Act) legt fest, was Finanzunternehmen organisatorisch und technisch beherrschen müssen, damit Cyberangriffe und Systemausfälle im eigenen Betrieb oder bei Drittparteien den Betrieb nicht lahmlegen. Auch Schweizer Unternehmen können von DORA betroffen sein. Entscheidend ist nicht nur der Firmensitz, sondern auch die Rolle innerhalb der Gruppe und der Lieferkette.

Bin ich betroffen?

DORA gilt seit 17. Januar 2025. Es gibt drei typische Konstellationen, in denen DORA für Schweizer Unternehmen relevant wird:

Schweizer Unternehmenseinheiten in EU-Gruppen (inkl. gruppeninterner IT/Shared Services)
Schweizer Dienstleister, die IKT-Services für EU-Finanzunternehmen erbringen
Schweizer Anbieter in Lieferketten, wenn EU-Kunden DORA-Anforderungen vertraglich weitergeben

Wenn Ihre Organisation in eine dieser drei Kategorien fällt, müssen Sie Resilienz nicht nur leben, sondern belegen können.

Was DORA faktisch verändert: Betriebs- und Nachweisdisziplin

DORA ist vor allem ein Programm für operative Resilienz: klare Verantwortlichkeiten, wiederkehrende Zyklen und belastbare Evidenz. Das verlangt Governance und Verantwortung auf VR- und GL-Ebene (inkl. Risikoakzeptanz und Priorisierung).

In der Umsetzung zeigt sich DORA als Kombination aus klarer Organisation (Rollen, Prozesse, Verantwortlichkeiten) und wiederkehrenden Zyklen (testen, priorisieren, beheben, verifizieren), gestütz auf belastbare Nachweise.

Die fünf Säulen von DORA, kurz eingeordnet

DORA umfasst fünf Themenfelder, die zusammen ein Gesamtbild ergeben:

IKT-Risikomanagement Ein durchgängiger Rahmen: Policies, Prozesse, Kontrollen, Betrieb und Überwachung.
Meldewesen für IKT-Vorfälle Klare Vorfallkriterien, Abläufe, Fristen, Verantwortlichkeiten und die Fähigkeit, Informationen konsistent zu liefern.
Digitale operationelle Resilienztests Ein risikobasiertes Testprogramm für kritische Services inklusive Schwachstellen-Management, Nachtests und Dokumentation. Je nach Betroffenheit kann auch Threat-led Penetration Testing (TLPT) relevant sein.
Risiko durch Drittparteien (IKT-Dienstleister) Transparenz über Abhängigkeiten, Mindestanforderungen in Verträgen (u. a. Auditrechte, Incident-Pflichten, SLAs) sowie Exit- und Portabilitätsfähigkeit.
Informationsaustausch Strukturierter Austausch zu Cyber-Bedrohungen und Schwachstellen kann Resilienz stärken. Wichtig zur Einordnung: Der Informationsaustausch ist grundsätzlich freiwillig. Andere DORA-Nachweise, z. B. rund um Drittparteien-Transparenz, verpflichtend sind.

Welche konkreten Nachweise und Artefakte sich daraus in der Praxis typischerweise ergeben, bündeln viele Organisationen in einem «Evidence Pack».

Was Sie am Ende wirklich brauchen: ein «Evidence Pack»

In Audits und gegenüber Auftraggebern zählen nicht Aussagen oder Folien, sondern Nachweise. Ein pragmatischer Zielzustand ist ein strukturierter Nachweisordner, der Entscheidungen, Tests, Ergebnisse und Verbesserungen nachvollziehbar zusammenführt.

Typische Bausteine daraus sind zum Beispiel:

Inventar kritischer Services inkl. Abhängigkeiten und Recovery-Zielen
Übungs- und Vorfallnachweise (Runbooks, Eskalation, Tabletop-Protokolle, Lessons Learned)
Testberichte (z. B. Pentests / Red Team / Bug-Bounty-Programme / Vulnerability Assessment / Scan) inkl. Status und Nachtests
Schwachstellenmanagement (Priorisierung, Remediation-Zyklus, Auswertung der Offenzeit)
Drittparteien-Unterlagen (Verträge, Sicherheitsanhang, Auditrechte, Subdienstleister-Regeln, Exit/Portabilität)

Das Whitepaper beschreibt eine umfassendere Auditstruktur sowie eine kompakte Checkliste.

Wo Crowd-basierte Sicherheit helfen kann

Periodische Tests liefern naturgemäss eine Momentaufnahme. Crowd-basierte Sicherheitsansätze, wie Bug-Bounty-Programme oder Vulnerability-Disclosure-Programme, können die Zeit zwischen Testzyklen überbrücken und Veränderungen in Cloud-Umgebungen, Releases und Konfigurationen früher sichtbar machen.

Bei Crowd-basierten Testansätzen melden externe Security-Researcher gefundene Schwachstellen innerhalb klarer Regeln und eines definierten Scopes. Triage und Einordnung, Berichte sowie Nachtests schaffen belastbare Evidenz und unterstützen den wiederkehrenden Verbesserungszyklus (testen, priorisieren, beheben, verifizieren).

Richtig eingebettet kann das insbesondere helfen, Veränderungen zwischen Testzyklen früher zu erkennen und den Test- und Behebungszyklus mit Evidenz zu untermauern.

Kurzcheck: Wie audit-ready sind Sie für DORA?

Dieser Kurzcheck ist bewusst als Orientierung formuliert. Die Einordnung, was «gut» bedeutet und welche Nachweise typischerweise erwartet werden, ist im Whitepaper inklusive Checkliste beschrieben.

Gibt es klar definierte Verantwortlichkeiten (inkl. Eskalation) und geregelte Entscheidungen zur Risikoakzeptanz?
Sind kritische Services inkl. Abhängigkeiten dokumentiert (RTO/RPO, Recovery-Tests)?
Existiert ein wiederkehrender Test- und Verbesserungszyklus (Test, Behebung, Nachtest, Dokumentation)?
Können Sie den Status von Schwachstellen (Priorisierung, Bearbeitung, Offenzeit) nachweisen?
Sind IKT-Drittparteien inkl. relevanter Subdienstleister transparent erfasst und vertraglich sauber geregelt (Audit, Incident, SLAs, Exit)?
Gibt es Incident-Runbooks und Übungsnachweise (Tabletop, Auswertung, Massnahmen)?