Wenn Sie Software in einer Bank, Versicherung, Investmentfirma, Zahlungsinstitution oder einem anderen Finanzinstitut entwickeln, das unter DORA (Digital Operational Resilience Act, Verordnung (EU) 2022/2554) fällt, gilt die Verordnung bereits für Ihre Organisation. Wenn Sie ICT-Dienstleistungen anbieten, die von solchen Instituten genutzt werden, ist die Situation präziser: DORA überwacht direkt bestimmte kritische ICT-Drittanbieter, während andere Anbieter die DORA-Anforderungen hauptsächlich über die Verträge und Due-Diligence-Prüfungen ihrer Finanzinstituts-Kunden erfüllen. Ein Großteil der öffentlichen Diskussion behandelt DORA als Thema für Vorstand und Risikomanagement: ICT-Risikorahmen, Resilienztests, Vorfallmeldungen an Aufsichtsbehörden, wichtige vertragliche Bestimmungen. Diese Interpretation ist für den Großteil der Verordnung korrekt. Sie ist jedoch unvollständig für den Teil, den ein Entwickler tatsächlich in den Code einbringt.
Der unvollständige Teil betrifft die Resilienzentscheidungen, die im Repository leben: ein entfernte Circuit Breaker als "toter Code", eine verkürzte Backup-Aufbewahrungsfrist zur Speicherersparnis, eine neue Betrugs-API, die in den Zahlungspfad eingebunden wird, ohne Eintrag im Register, oder eine Gesundheitsprüfung oder Alert-Regel, die gelöscht wird, weil sie zu viele Fehlalarme auslöste. Jede dieser Änderungen sieht wie normale Entwicklungsarbeit aus. Jede schwächt jedoch eine Verpflichtung, die DORA auf Artikel-Ebene benennt. Dieser Leitfaden richtet sich an Entwickler, die wissen müssen, welche Artikel in einem Pull Request auftauchen, welche Form diese Änderungen annehmen und wie sie erkannt werden können, ohne jede Review in ein juristisches Gutachten zu verwandeln.
Für wen dieser Leitfaden ist (und für wen nicht)
Sie gehören zur Zielgruppe, wenn Ihr Code ein Finanzinstitut unterstützt, das unter DORA fällt, oder wenn Ihr Produkt eine ICT-Dienstleistung ist, die von solchen Instituten in der Produktion genutzt wird (unabhängig davon, ob Sie ein bestimmter kritischer ICT-Drittanbieter unter direkter Aufsicht sind oder ein Anbieter, der hauptsächlich über Kundenverträge gebunden ist). Geltungsbereich und Bezeichnung nach der Verordnung sind rechtliche und klassifizierungsbezogene Fragen, die nicht durch eine Code-Review entschieden werden. Wenn Ihr Compliance- oder Rechtsteam Ihnen bereits mitgeteilt hat, dass DORA (direkt oder vertraglich) auf Sie zutrifft, behandelt dieser Leitfaden den technischen Teil dieser Pflicht. Wenn Sie unsicher sind, ob Sie betroffen sind, brechen Sie hier ab und fragen Sie Ihr Team: Die falsche Antwort führt entweder zu einer Unterinvestition in eine echte Verpflichtung oder zu einer Überanpassung an eine Verordnung, die nicht gilt.
Dies ist kein Ersatz für einen ICT-Risikomanagement-Rahmen, ein Resilienztest-Programm, einen Vorfallmeldungsprozess, ein Drittanbieter-Register oder wichtige vertragliche Bestimmungen mit ICT-Anbietern. heygrc betreibt keine dieser Prozesse. Es ist darauf ausgelegt, den Moment zu erkennen, in dem eine Änderung in einem Pull Request eine Resilienz-relevante Kontrolle schwächt oder einfügt, von der diese Programme ausgehen, dass sie weiterhin besteht.
Die Artikel, die tatsächlich in einem Diff auftauchen
Der Großteil von DORA wird nie als Zeile Anwendungs-Code erscheinen. Was tatsächlich in einem Pull Request landet, konzentriert sich auf eine kurze Liste von Artikeln. Art. 9 (Schutz und Prävention): Eine Änderung schwächt die Zugriffskontrolle, Verschlüsselung, Netzwerksegmentierung oder eine andere Maßnahme, die eine kritische ICT-Funktion isoliert hält. Art. 10 (Erkennung): Protokollierung, Warnmeldungen oder Anomalieerkennung, auf die sich eine Organisation verlässt, um ICT-Probleme umgehend zu erkennen, werden entfernt oder deaktiviert. Art. 11 (Reaktion und Wiederherstellung): Ein Retry, Circuit Breaker, Failover, Timeout oder Wiederherstellungspfad, der eine kritische Funktion während einer Unterbrechung am Laufen hielt, wird als Bereinigung gelöscht. Art. 12 (Backup und Wiederherstellung): Backup-Umfang, -Häufigkeit oder -Tools zur Wiederherstellung werden reduziert, oder ein neuer kritischer Speicher wird ohne Backup-Pfad bereitgestellt. Art. 17 bis 19 (ICT-bezogenes Vorfallmanagement, Klassifizierung und Meldung): Eine Änderung entfernt die Identifizierung, Nachverfolgung, Protokollierung oder Aufzeichnung von ICT-bezogenen Vorfällen (Art. 17) oder entfernt Felder und Signale, von denen der Klassifizierungsprozess (Art. 18) und der Meldungsweg für schwerwiegende Vorfälle (Art. 19) abhängen. Art. 28 (allgemeine Grundsätze für ICT-Drittrisiken), einschließlich des Registers der Informationen nach Art. 28(3): Eine neue vertragliche Vereinbarung für einen ICT-Dienst wird in die Produktion eingebunden, ohne im Register erfasst zu werden, das alle solchen Vereinbarungen abdecken soll. Art. 30 (wichtige vertragliche Bestimmungen): Die Vereinbarung wird als "nur ein weiterer SaaS-Kunde" behandelt, ohne Verweis auf das Kapitel zu vertraglichen Bestimmungen für ICT-Dienste, was eine separate Pflicht von der Register- und Governance-Arbeit nach Art. 28 darstellt.
Diese Erläuterungen sind einfache Zusammenfassungen für Entwickler und kein wörtlicher Auszug aus der Verordnung. Die detaillierte Analyse der Resilienz-Artikel mit den Änderungen, die sie auslösen, finden Sie unter /frameworks/dora. Die Seiten zu Kontrollen im Code für Art. 9 (Schutz und Prävention) und Art. 11 (Reaktion und Wiederherstellung) zeigen durchgearbeitete Diffs für entfernte Segmentierung und einen gelöschten Circuit Breaker. Dieser Leitfaden konzentriert sich auf den Artikel-Cluster, der Produktentwickler am häufigsten überrascht: Art. 28 und Art. 30, wenn ein bequemer SaaS-Aufruf zu einer Produktions-ICT-Abhängigkeit wird.
Durchgearbeitetes Beispiel: Ein sauberer Client, der zu einem nicht erfassten ICT-Drittanbieter wird
Ein Zahlungsteam möchte schnellere Betrugsentscheidungen. Ein Entwickler öffnet einen Pull Request, der einen langsamen internen Regelpfad durch einen typisierten HTTP-Client für eine neue externe "FraudScore"-API ersetzt. Der Client hat Timeouts, Retries mit Backoff, strukturierte Fehlermapping und ein Feature-Flag. Tests decken den Happy Path und 5xx-Fehler ab. Die Review-Kommentare drehen sich um Latenzbudgets und ob das Flag standardmäßig aktiviert oder deaktiviert ist. Nichts am Diff sieht aus wie ein Software-Fehler: Es handelt sich um eine gut umgesetzte Integration.
Was der PR nicht enthält, ist eine Aktualisierung des Registers der Informationen über vertragliche Vereinbarungen für ICT-Dienste (Art. 28(3)) oder ein Verweis auf die wichtigsten vertraglichen Bestimmungen nach Art. 30, die allgemein für ICT-Dienstvereinbarungen gelten (Art. 30(1) und (2)). Keine dieser Punkte wartet darauf, dass jemand entscheidet, ob der Aufruf "kritisch" ist. Unabhängig davon: Wenn diese Betrugsprüfung auf dem Pfad liegt, der Zahlungen autorisiert, kann die Vereinbarung eine kritische oder wichtige Funktion unterstützen, was zusätzliche Pflichten auslösen kann, einschließlich der Art. 28-Anforderungen an Exit-Strategien und Art. 29-Konzentrationsrisikobewertung sowie der erweiterten vertraglichen Bestimmungen in Art. 30(3). Wenn der Client zuerst bereitgestellt und der Registereintrag "später" hinzugefügt wird, wird eine Produktionsabhängigkeit für das Programm unsichtbar, das jede ICT-Dienstvereinbarung erfassen soll.
Genau das soll eine compliance-bewusste Review erkennen: nicht "Ist der HTTP-Client korrekt?", sondern "Hat diese Änderung einen ICT-Drittanbieter-Dienst eingeführt oder ausgetauscht, dessen vertragliche Vereinbarung Art. 28(3) im Register erwartet?" Ein Befund, der Art. 28 / Art. 28(3) (und Art. 30, falls vertragliche Bestimmungen die Lücke darstellen) zitiert, genehmigt den Anbieter nicht, entwirft keinen Vertrag, klassifiziert keine Kritikalität und entscheidet nicht über das Konzentrationsrisiko. Er macht die Drittanbieter-Pflicht sichtbar, während der Autor den PR noch offen hat, sodass die Register-, Klassifizierungs- und Vertragsschritte parallel zum Code und nicht erst Wochen später, wenn der neue Anbieter bereits im Produktionsverkehr genutzt wird, erfolgen können.
Worauf man in der Review achten sollte, ohne zum DORA-Juristen zu werden
Wenn eine Änderung eine ausgehende Abhängigkeit hinzufügt oder austauscht, die in der Produktion für eine Finanzfunktion ausgeführt wird, stellen Sie drei technische Fragen: Ist die vertragliche Vereinbarung für diesen ICT-Dienst bereits in unserem Register der Informationen (Art. 28(3)) erfasst, einschließlich der Klassifizierung des Dienstes und ob er eine kritische oder wichtige Funktion unterstützt; führt ein Ausfall dieses Aufrufs zu einer so starken Beeinträchtigung eines Finanzdienstes, dass Kritikalität und Exit-Plan-Arbeiten anwendbar sein könnten; und aktualisiert derselbe PR (oder eine verknüpfte Änderung) die interne Checkliste oder das Ticket, das Ihr Risikoteam verwendet, wenn eine neue ICT-Vereinbarung hinzugefügt wird, einschließlich der Art. 30-Arbeiten zu vertraglichen Bestimmungen, falls Ihr Unternehmen dies so nachverfolgt. Wenn die Antwort auf die Registerfrage "nein" oder "unbekannt" lautet, ist das Feature aus DORA-Drittanbieter-Sicht unvollständig, selbst wenn es als Code vollständig ist. Die Kritikalität bestimmt, wie viel zusätzliche Arbeit folgt; sie entscheidet nicht darüber, ob die Vereinbarung in das Register gehört.
Bei Resilienz-Sicherungsmaßnahmen, die Sie bereits besitzen, sieht das anders aus: Ein PR mit der Zusammenfassung "Bereinigung", "toten Code entfernen" oder "Kosten reduzieren", der Retries, Failovers, Backups, Isolationsregeln oder Erkennungs-Hooks auf einem kritischen Pfad löscht. Fragen Sie, ob das System die Resilienz-Eigenschaft, die diese Sicherungsmaßnahme bereitstellte, weiterhin erfüllt. Art. 9, 10, 11, 12 und der Vorfallmanagement-Cluster in Art. 17 bis 19 sind die üblichen Zitate, wenn die Antwort "nein" lautet. Sie müssen die Verordnung nicht zitieren. Sie müssen die Eigenschaft benennen und die Zusammenführung verweigern, bis jemand entweder die Sicherungsmaßnahme wiederherstellt oder eine akzeptierte Änderung über Ihren echten Änderungsprozess dokumentiert.
Wo heygrc ins Spiel kommt und die Ehrlichkeitsgrenze
heygrc ist darauf ausgelegt, jeden Pull Request gegen die von Ihnen ausgewählten Frameworks zu prüfen, einschließlich DORA, wenn es aktiviert ist, und den Artikel zu benennen, den eine Änderung scheinbar betrifft (z. B. Art. 28(3) bei einer neuen ICT-Dienstvereinbarung, die im Register fehlt, oder Art. 11 bei einem entfernten Wiederherstellungspfad). Der Befund ist ein Review-Kommentar mit dem angehängten Artikel, damit Autor und Reviewer mit vollständigen Informationen entscheiden können. Es zertifiziert keine DORA-Compliance, ersetzt nicht Ihr ICT-Risikoframework, führt keine Resilienztests durch, erstellt keine Vorfallmeldungen, verwaltet nicht Ihr Drittanbieter-Register und entwirft keine vertraglichen Bestimmungen nach Art. 30. Diese bleiben menschliche und organisatorische Pflichten. Eine grüne heygrc-Review ist keine behördliche Freigabe; sie ist ein früheres, artikelbasiertes Signal, dass eine Änderung etwas bewegt hat, das diese Programme betrifft.
Wenn Ihr Team bereits einen Bug- oder Qualitäts-Reviewer für denselben Pull Request verwendet, behalten Sie ihn bei. Diese Tools prüfen, ob der Code korrekt und sicher ist. DORA-Fragen betreffen die operative Resilienz und ICT-Drittanbieter-Pflichten. Der oben beschriebene FraudScore-Client kann sauber, typisiert und gut getestet sein und trotzdem Art. 28(3) unvollständig lassen. Führen Sie beide Ebenen aus; keine ersetzt die andere.