Control-Map · Verordnung (EU) 2022/2554

DORA

Code-Nachweis für Schutz und Prävention sowie Prozessnachweis aus Deployments und Releases für Artikel 9.

Audit-Pilot buchen Beispielbericht ansehen

DORA · Verordnung (EU) 2022/25546 Artikel im Umfang · Stand v1.4.1

Code 1
Prozess Art.9
Geplant 5

Code-Nachweis

1Artikel, bei jedem Pull Request geprüft

Live (Prozess)

Art.9aus Deployments und Releases

Geplant

5lässt sich aus Code oder GitHub belegen; noch nicht gebaut

Artikel auf Organisationsebene

Richtlinien, Personal, Lieferanten, physische Sicherheit und Ähnliches, unten aufgelistet.Für 1 davon liefert Toevan unterstützende Nachweise.Von den Abläufen Ihrer Organisation verantwortet

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); die Erkennung nach Artikel 10 ist geplant. Für Artikel 9 gibt es außerdem Prozessnachweise aus Deployments und Releases: ein erfolgreiches Deployment eines Commits in die Produktion, eine freigegebene Deployment-Prüfung mit berechneter Aufgabentrennung sowie den Tag eines Releases und den Commit, den er benennt. 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.

Code-Nachweis1

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

Art.9Schutz und PräventionKap. II IKT-RisikomanagementProzessnachweis aus Deployments und Releases: Ein erfolgreiches Deployment eines Commits in die Produktion, nach dem Flag von GitHub oder der Festlegung der Organisation. Eine freigegebene Deployment-Prüfung mit berechneter Aufgabentrennung. Der Tag eines Releases und der Commit, den er benennt.

Unterstützend1

Toevan erfasst verwandte Nachweise, doch die Pflicht liegt bei der Organisation und gilt deshalb nie als abgedeckt.

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

Geplant5

Lässt sich aus Code oder GitHub belegen. Noch keine Regel prüft diese; jedes ist geplant, und keines zählt heute als Nachweis.

Art.7IKT-Systeme, Protokolle und WerkzeugeKap. II IKT-Risikomanagement
Art.8IdentifizierungKap. II IKT-Risikomanagement
Art.10ErkennungKap. II IKT-Risikomanagement
Art.12Backup-Richtlinien und -Verfahren, Wiederherstellungsverfahren und -methodenKap. II IKT-Risikomanagement
Art.25Tests von IKT-Werkzeugen und -SystemenKap. IV Tests der digitalen operationalen Resilienz

Artikel auf Organisationsebene

Controls auf Organisationsebene (Richtlinien, Personal, Lieferanten, physische Sicherheit und Ähnliches) bleiben beim eigenen Prozess Ihrer Organisation; Toevan übernimmt sie nicht.

Liste 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 verwenden

Grundgesamtheit aus den Änderungseinträgen entnehmen
Jeder in den Standard-Branch gemergte Pull Request und jeder Push auf einen geschützten Branch, den kein gemergter Pull Request erklärt, 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 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 zuerst die Ergebnisse und dann offline gegen den veröffentlichten Schlüssel mit openssl und der Shell: Nachweis holen, Schlüssel bestätigen, Eintrag prüfen. Um die ganze Kette nachzuvollziehen, stellt Toevan den toevan-Befehl auf Anfrage bereit; er ist noch nicht öffentlich.
Die drei Schritte, mit den genauen Befehlen

Wie jeder Fakt gewonnen wurde6 Labels

Neu berechnet: Toevan hat es selbst aus Code oder Git-Historie berechnet.
Gemeldet + versiegelt: GitHub hat es gemeldet; Toevan hat es beim Ereignis erfasst und signiert.
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.
Toevan-Eintrag, nicht versiegelt: In der Datenbank von Toevan gespeichert, aber nicht im Ledger versiegelt, etwa eine Ausnahmegenehmigung heute. Keine Signatur schützt ihn.
Übernommen: Aus den Deployment- und Release-Einträgen von GitHub übernommen und per Commit oder Digest verknüpft.
Nicht erfasst: Es gab keine verlässliche Quelle. Toevan schließt nichts daraus.

Der Beispielbericht zu Änderungsnachweisen zeigt die Nachweise so, wie Ihr Prüfer sie erhält, jeden Fakt mit Herkunft.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 Prüfer durch die Verifikation.

Audit-Pilot buchen Beispielbericht ansehen

Ein Repository, ein Framework
Nachweise ab dem ersten Pull Request
Prüfbar ohne Toevan-Konto