> For the complete documentation index, see [llms.txt](https://docs.stoik.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.stoik.io/help/help-de/onboarding/compliance/dora.md). # DORA Seit dem 17. Januar 2025 ist der **Digital Operational Resilience Act (DORA, Verordnung (EU) 2022/2554)** verlangt von EU-Finanzunternehmen nachzuweisen, dass sie ICT-Vorfälle verkraften, darauf reagieren und sich davon erholen können. DORA verlangt nicht, dass Sie ein bestimmtes Tool kaufen. Es verlangt, dass Sie Maßnahmen eingerichtet haben **und dass Sie dies nachweisen**. Stoïk Protect hilft bei beidem: Seine Tools decken mehrere technische Anforderungen ab, und sie erzeugen die Nachweise (Berichte, Historie, Abschlussquoten), die Prüfer und Aufsichtsbehörden erwarten. Dieser Artikel zeigt, bei welchen DORA-Anforderungen jedes Stoïk-Protect-Tool hilft und was weiterhin in Ihrer Verantwortung liegt. {% hint style="info" %} Stoïk Protect verfügt über eine spezielle **NIS2** Bewertung in der **Compliance** Registerkarte. Im Produkt gibt es bislang noch keine DORA-Bewertung. DORA und NIS2 überschneiden sich bei technischen Maßnahmen stark, und für Finanzunternehmen ersetzt DORA die entsprechenden NIS2-Anforderungen (NIS2, Art. 4). Daher ist die NIS2-Bewertung immer noch ein nützlicher Ausgangspunkt für eine Gap-Analyse. {% endhint %} ## Wen betrifft DORA? DORA gilt für die meisten regulierten Finanzunternehmen: Banken, Zahlungs- und E-Geld-Institute, Wertpapierfirmen, Vermögensverwalter, Versicherer und Rückversicherer, Anbieter von Krypto-Asset-Dienstleistungen und andere. Einige Unternehmen sind **ausgenommen**. Die wichtigste Ausnahme gilt für Versicherungs- und Rückversicherungsvermittler, die Kleinstunternehmen, kleine oder mittlere Unternehmen sind (Art. 2 Abs. 3). Kleinere Unternehmen im Anwendungsbereich können außerdem einen **vereinfachten Rahmen für das IKT-Risikomanagement** anwenden (Art. 16). Wenn Sie nicht sicher sind, ob DORA für Sie gilt, fragen Sie Ihre Compliance-Verantwortlichen oder Ihre Aufsichtsbehörde (in Frankreich die ACPR oder die AMF). ## Wie Stoïk Protect zu DORA passt DORA hat fünf Säulen. Stoïk Protect trägt zu vier davon bei. ### 1. IKT-Risikomanagement (Kapitel II, Artikel 5 bis 16) Diese Säule verlangt, dass Sie Ihre Vermögenswerte kennen, Schwachstellen finden, Ihre Systeme schützen, Anomalien erkennen und Ihre Mitarbeitenden schulen. | Stoïk-Protect-Tool | DORA-Anforderung, bei der es hilft | Nachweis, den Sie vorlegen können | | -------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | | **External Scan** | Inventar der dem Internet ausgesetzten ICT-Assets (Art. 8 Abs. 1, 8 Abs. 4). Laufende Identifizierung von Schwachstellen und Cyberbedrohungen (Art. 8 Abs. 2). Überwachung von ICT-Systemen (Art. 9 Abs. 1). | Datierte Scan-Berichte und eine Historie der Schwachstellen und ihrer Behebungen | | **Active-Directory-Scan** | Zugriff nur auf das, was jede Rolle benötigt (Art. 9 Abs. 4 Buchst. c). Starke Authentifizierung (Art. 9 Abs. 4 Buchst. d). Erkennung privilegierter, inaktiver oder fehlerhaft konfigurierter Konten. | AD-Konfigurationsbericht und eine priorisierte Liste der Findings mit Nachverfolgung der Behebung | | **Cloud-Scan** (AWS, Azure, GCP) | Sicherheit und Resilienz von Systemen sowie Verhinderung unbefugten Zugriffs und von Datenlecks (Art. 9 Abs. 2, 9 Abs. 3). Erkennung von Fehlkonfigurationen auf Ihrer Seite der Cloud, für die Sie weiterhin voll verantwortlich sind (Art. 28 Abs. 1). | Cloud-Posture-Bericht je Umgebung | | **Überwachung von Zugangsdaten** | Schutz vor unbefugtem Zugriff (Art. 9 Abs. 3 Buchst. b). Erkennung kompromittierter Konten, bevor sie genutzt werden (Art. 10 Abs. 1). | Liste erkannter geleakter Zugangsdaten und zurückgesetzter Passwörter | | **Email Security** | Sicherheit der Datenübertragungskanäle (Art. 9 Abs. 3 Buchst. a). Geringeres Risiko unbefugten Zugriffs und von Betrug (Art. 9 Abs. 3 Buchst. b). | Statistiken zu blockierten Bedrohungen | | **MDR** | 24/7-Erkennung anomaler Aktivität auf Endpunkten (Art. 10 Abs. 1). Ausreichende Ressourcen, um Anomalien und Cyberangriffe zu überwachen (Art. 10 Abs. 3). Schnelle Eindämmung (Art. 11 Abs. 2). | Aktivitätsberichte, bearbeitete Warnmeldungen, Reaktionszeiten | | **XDR** | Mehrere Kontrollschichten, Warnschwellen und automatische Alarmierung (Art. 10 Abs. 2) über VPN-, Firewall- und Clouddaten hinweg. | Erkennungsregeln und Alarmhistorie | | **Schulung** | Verpflichtende ICT-Sicherheitsawareness für alle Mitarbeitenden (Art. 13 Abs. 6). Regelmäßige Schulung des Leitungsorgans (Art. 5 Abs. 4). | Abschlussquoten und Kurszertifikate | | **Phishing-Simulation** | Awareness-Programme (Art. 13 Abs. 6). Lernen aus beobachteten Bedrohungen (Art. 13 Abs. 1). | Klick-, Einreichungs- und Melderaten je Kampagne, mit Trends im Zeitverlauf | ### 2. Management und Meldung von ICT-Vorfällen (Kapitel III, Artikel 17 bis 23) | Stoïk-Service | DORA-Anforderung, bei der es hilft | Nachweis, den Sie vorlegen können | | -------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ | | **MDR / XDR** | Erkennung und Protokollierung von Vorfällen (Art. 17 Abs. 2, 17 Abs. 3). Früherkennung ist wichtig, weil die Meldefristen von DORA ab der Einstufung des Vorfalls laufen. | Alarm- und Vorfallhistorie | | **Schaltfläche „Phishing melden“** | Eine einfache Möglichkeit für Mitarbeitende, verdächtige E-Mails zu melden, die Ihren Prozess zur Erkennung von Vorfällen unterstützt (Art. 17 Abs. 3). | Gemeldete E-Mails und wie sie behandelt wurden | | **Stoïk CERT** (24/7-Vorfallreaktion, in der Stoïk-Versicherung enthalten) | Reaktion und Wiederherstellung (Art. 11). Nachbearbeitung des Vorfalls und Ursachenanalyse (Art. 13 Abs. 2). Technische Zuarbeit für Berichte über schwerwiegende Vorfälle (Art. 19 Abs. 4): Erstmeldung, Zwischenbericht und Abschlussbericht. | Vorfallbericht mit Zeitachse, Indikatoren für eine Kompromittierung, Ursache und ergriffenen Maßnahmen | ### 3. Tests der digitalen operationellen Resilienz (Kapitel IV, Artikel 24 bis 27) DORA verlangt ein Prüfprogramm, das mindestens einmal jährlich überprüft wird und ausdrücklich Folgendes umfasst **Schwachstellenbewertungen und Scans** (Art. 25 Abs. 1). * **External Scan, Active Directory Scan und Cloud Scan** geben Ihnen wiederkehrende Schwachstellenbewertungen, die in dieses Programm einfließen (Art. 24 Abs. 6, 25 Abs. 1). * **Phishing-Simulationen** sind eine Form von szenariobasiertem Social-Engineering-Testing (Art. 25 Abs. 1). > Threat-led Penetration Testing (TLPT, Art. 26 und 27) ist nur für Finanzunternehmen verpflichtend, die von ihrer Aufsichtsbehörde benannt wurden. Stoïk Protect bietet dies nicht an. ### 4. ICT-Drittrisiko (Kapitel V, Artikel 28 bis 44) Wenn Sie einen Cloud-Anbieter nutzen, bleiben Sie für Ihre DORA-Verpflichtungen voll verantwortlich (Art. 28 Abs. 1). **Cloud-Scan** hilft Ihnen, den Teil dieses Risikos zu kontrollieren, der davon abhängt, wie *Sie* Ihre Umgebung konfiguriert haben. Es **ersetzt** weder das Informationsregister noch die verpflichtenden Vertragsklauseln mit Ihren ICT-Anbietern (Art. 28 Abs. 3, Art. 30). ### 5. Informationsaustausch (Artikel 45) Diese Säule ist nach DORA optional. Stoïk Protect deckt sie nicht direkt ab. ## Was weiterhin in Ihrer Verantwortung liegt Stoïk Protect gibt Ihnen Tools und Nachweise. Ihre Organisation bleibt für Folgendes verantwortlich: * **Governance.** Ihr Leitungsorgan trägt die letztendliche Verantwortung für das ICT-Risiko und muss den Rahmen genehmigen (Art. 5 Abs. 2). * **Offizielle Meldungen.** Sie melden Ihrer Aufsichtsbehörde schwerwiegende Vorfälle (Art. 19). Das Stoïk CERT hilft Ihnen bei der Vorbereitung der technischen Inhalte. * **Backups und Geschäftskontinuität.** Ihre Richtlinien für Backup, Wiederherstellung sowie Geschäftskontinuität oder Notfallwiederherstellung und deren Tests (Art. 11, 12). * **Verzeichnis und Verträge der ICT-Anbieter** (Art. 28 Abs. 3, 30). * **Verschlüsselungsrichtlinie** (Art. 9 Abs. 4). * **TLPT**, falls Ihre Aufsichtsbehörde Sie benannt hat (Art. 26, 27). ## Erste Schritte 1. Öffnen Sie **Stoïk Protect** und prüfen Sie, welche Tools für Ihre Organisation bereits aktiv sind. 2. Aktivieren Sie die Tools, die zu Ihren Lücken passen. External Scan, Active Directory Scan, Training und Phishing-Simulation sind die schnellsten Erfolge für DORA-Nachweise. 3. Vervollständigen Sie die **NIS2-Bewertung** in der **Compliance** Registerkarte für eine strukturierte Sicht auf Ihre technischen Maßnahmen. 4. Exportieren Sie die Berichte aus jedem Tool und fügen Sie sie Ihrer DORA-Dokumentation hinzu. {% hint style="warning" %} Dieser Artikel ist eine allgemeine Orientierungshilfe, keine Rechtsberatung. Die Verweise beziehen sich auf die EU-Texte: Verordnung (EU) 2022/2554 (DORA) und ihre delegierten Verordnungen (EU) 2024/1774 und (EU) 2025/301. Der genaue Umfang jeder Dienstleistung hängt von Ihrem Vertrag ab. Für Ihre konkreten Verpflichtungen fragen Sie bitte Ihre Compliance-Verantwortlichen oder Ihre Aufsichtsbehörde. {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.stoik.io/help/help-de/onboarding/compliance/dora.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.