Control-Map · Verordnung (EU) 2022/2554

DORA

Audit-Pilot buchen Beispielbericht ansehen

2 von 6 Controls für DORA, die Code belegen kann, mit v1.4.0, plus 1 unterstützend

Code-Nachweis für Schutz und Prävention sowie Erkennung, gestärkt durch Nachweise zum Änderungsmanagement in v1.4.0.

Live2
Kommt in v1.4.00
Unterstützend1
Geplant4
Ihre Organisation20

2 mit Code-Nachweis heuteTeilnachweis, bei jedem Pull Request geprüft.
1 mit unterstützendem NachweisToevan erfasst verwandte Nachweise; die Pflicht bleibt organisatorisch.
20 bleiben bei Ihrer OrganisationUnten vollständig aufgelistet, damit nichts angedeutet wird.

DORA gilt seit dem 17. Januar 2025 für Finanzunternehmen in der EU. Es verlangt einen IKT-Risikomanagementrahmen, dessen Wirksamkeit Sie zeigen können, einschließlich dokumentiertem Änderungsmanagement.

Der DORA-Blueprint liefert bei jedem Pull Request Code-Nachweise für Artikel 9 (Schutz und Prävention) und Artikel 10 (Erkennung). Ab v1.4.0 stärken Nachweise zum Änderungsmanagement jeder gemergten Änderung den Artikel 9. Governance, Vorfallmeldung, Resilienztests und Drittparteirisiko bleiben bei Ihrem Prozess.

Auf der Roadmap: die RTS zum IKT-Risikomanagement (Delegierte Verordnung (EU) 2024/1774), mit Artikel 17 IKT-Änderungsmanagement aus Prozessnachweisen und Artikel 16 aus Code-Nachweisen. Ihre Katalogausgabe muss noch ergänzt werden.

Toevan liefert Nachweise für Controls; es zertifiziert sie nie und behauptet nie, ein Framework sei abgedeckt. Ob die Nachweise genügen, beurteilt Ihr Auditor.

Live2

Code-Nachweis heute, bei jedem Pull Request versiegelt. Immer nur teilweise: Das Control verlangt auch Dinge außerhalb des Codes. Code-Nachweis heute: Regeln im Blueprint DORA prüfen einen Teil davon bei jedem Pull Request.

Art.9
Schutz und Prävention
Kap. II IKT-Risikomanagement
Gestärkt in v1.4.0: Nachweis zum Änderungsmanagement pro gemergter Änderung.
Art.10
Erkennung
Kap. II IKT-Risikomanagement

Unterstützend1

Toevan erfasst verwandte Nachweise, heute oder in v1.4.0, doch die Pflicht liegt bei der Organisation und gilt deshalb nie als abgedeckt.

Art.28
Allgemeine Grundsätze
Kap. V Management des IKT-Drittparteirisikos
Unterstützender Nachweis heute: Eine Regel erfasst Nachweise zu dieser Pflicht. Die Pflicht selbst betrifft die Richtlinien der Organisation.

Geplant4

Lässt sich aus Code oder GitHub belegen. Die Regel oder die Zuordnung ist noch nicht gebaut.

Art.7
IKT-Systeme, Protokolle und Werkzeuge
Kap. II IKT-Risikomanagement
Art.8
Identifizierung
Kap. II IKT-Risikomanagement
Art.12
Backup-Richtlinien und -Verfahren, Wiederherstellungsverfahren und -methoden
Kap. II IKT-Risikomanagement
Art.25
Tests von IKT-Werkzeugen und -Systemen
Kap. IV Tests der digitalen operationalen Resilienz

Ihre Organisation20

Richtlinien, Personal, physische Sicherheit, Verträge, regulatorische Verfahren, Betrieb oder externe Prüfung. Diese belegt Ihre Organisation.

Alle 20 Controls anzeigen

Kap. II IKT-Risikomanagement

Art.5Governance und Organisationdie Richtlinien der Organisation
Art.6IKT-Risikomanagementrahmendie Richtlinien der Organisation
Art.11Reaktion und Wiederherstellungeinen betrieblichen Prozess
Art.13Lernen und Weiterentwicklungeinen betrieblichen Prozess
Art.14Kommunikationeinen betrieblichen Prozess
Art.15Weitere Harmonisierung von Werkzeugen, Methoden, Prozessen und Richtlinien des IKT-Risikomanagementsein regulatorisches Verfahren
Art.16Vereinfachter IKT-Risikomanagementrahmendie Richtlinien der Organisation

Kap. III IKT-Vorfallmanagement, Klassifizierung und Meldung

Art.17Prozess für das Management IKT-bezogener Vorfälleeinen betrieblichen Prozess
Art.18Klassifizierung IKT-bezogener Vorfälle und Cyberbedrohungeneinen betrieblichen Prozess
Art.19Meldung schwerwiegender IKT-bezogener Vorfälle und freiwillige Meldung erheblicher Cyberbedrohungenein regulatorisches Verfahren
Art.20Harmonisierung von Meldeinhalten und Vorlagenein regulatorisches Verfahren
Art.21Zentralisierung der Meldung schwerwiegender IKT-bezogener Vorfälleein regulatorisches Verfahren
Art.22Rückmeldung der Aufsichtein regulatorisches Verfahren
Art.23Operative oder sicherheitsbezogene zahlungsbezogene Vorfälle bei Kreditinstituten, Zahlungsinstituten, Kontoinformationsdiensten und E-Geld-Institutenein regulatorisches Verfahren

Kap. IV Tests der digitalen operationalen Resilienz

Art.24Allgemeine Anforderungen an Tests der digitalen operationalen Resilienzdie Richtlinien der Organisation
Art.26Erweiterte Tests von IKT-Werkzeugen, -Systemen und -Prozessen auf Basis von TLPTeine externe Prüfung
Art.27Anforderungen an Tester für die Durchführung von TLPTeine externe Prüfung

Kap. V Management des IKT-Drittparteirisikos

Art.29Vorabbewertung des IKT-Konzentrationsrisikos auf Unternehmensebenedie Richtlinien der Organisation
Art.30Wesentliche VertragsbestimmungenVerträge und Lieferanten

Kap. VI Vereinbarungen zum Informationsaustausch

Art.45Vereinbarungen zum Austausch von Informationen über Cyberbedrohungenein regulatorisches Verfahren

Im Audit nutzen

Grundgesamtheit aus den Änderungseinträgen entnehmen (ab v1.4.0)
Jeder Merge in einen geschützten Branch und jeder direkte Push im Zeitraum, beim Eintreten aus GitHub erfasst, ist ein versiegelter Eintrag, den Sie für die Stichprobe exportieren können. Die Grundgesamtheit des Standard-Branches können Sie aus der Git-Historie nachvollziehen; festgelegte Produktions-Branches sind für v1.4.1 geplant.
Code-Nachweise des Zeitraums lesen
Jeder Pull Request trägt versiegelte Code-Ergebnisse zu den Regeln des Blueprints, festgemacht am Commit und an der geltenden Regelsatz-Version.
Stichprobe testen
Prüfen Sie für jeden gezogenen Eintrag das Ergebnis, dann Signatur und Platz in der Kette offline.
$ toevan audit verify --path evidence-clone --pub-key toevan.pub

Wie jeder Fakt erhoben wurde

Jeder Fakt in einem Eintrag und einem Bericht trägt eines von sechs Labels, damit Ihr Auditor weiß, wie weit er sich darauf stützen kann.

Neu berechnet: Toevan hat es selbst aus Code oder Git-Historie berechnet.; Mit denselben Eingaben nachvollziehen und dasselbe Ergebnis erhalten.
Gemeldet + versiegelt: GitHub hat es gemeldet; Toevan hat es beim Ereignis erfasst und signiert.; Verlassen Sie sich darauf, soweit Sie GitHub vertrauen. Jede spätere Änderung ist erkennbar.
Erklärt + versiegelt: Die Organisation hat es erklärt, etwa eine Änderung dessen, was geprüft wird; Toevan hat die Erklärung und ihre Historie signiert.; Sehen Sie, wer was wann erklärt hat, und jede spätere Änderung.
Toevan-Eintrag, nicht versiegelt: In der Datenbank von Toevan gespeichert, aber nicht im Ledger versiegelt, etwa eine Ausnahmegenehmigung heute. Keine Signatur schützt ihn.; Behandeln Sie ihn als Aussage von Toevan und fragen Sie die Organisation nach der Freigabe dahinter.
Übernommen: Aus dem signierten Eintrag eines anderen Systems übernommen, etwa einer Build-Provenienz, und per Commit oder Digest verknüpft. Geplant.; Den Originaleintrag unabhängig prüfen.
Nicht erfasst: Es gab keine verlässliche Quelle. Toevan schließt nichts daraus.; Auf anderem Weg bei der Organisation einholen.

Im Bericht ansehen

Der Beispielbericht zeigt den Nachweis so, wie Ihr Auditor ihn erhält, jeder Fakt mit Label.

Beispielbericht öffnen

Testen Sie die Zuordnung an einem echten Audit.

Bringen Sie ein Repository und ein anstehendes Audit mit. Wir richten den Blueprint ein und führen Ihren Auditor durch die Prüfung.