DORA ist seit über einem Jahr anwendbar, und die Gespräche, die wir mit CySEC-regulierten Kunden führen, haben sich entsprechend verschoben. Die erste Welle war “Was ist das überhaupt?” und “Müssen wir das überhaupt einhalten?”. Die zweite Welle, in der wir uns gerade größtenteils befinden, ist “Wir erfüllen das technisch, aber eine Aufsichtsbehörde mit der richtigen Frage würde uns in fünf Minuten entlarven.” Dieser Beitrag ist die Version, die wir mit solchen Kunden in einem Meeting besprechen.
Er ist für ein spezifisches Publikum geschrieben: Tech-Leads und CTOs CySEC-regulierter Wertpapierfirmen in Zypern, deren Backoffice oder Middleware auf PHP oder Symfony läuft. Die konzeptionellen Teile gelten breiter, aber die ausgearbeiteten Beispiele und die regulatorischen Anker sind auf dieses Setup zugeschnitten.
Was DORA ist, kurz
Der Digital Operational Resilience Act ist die EU-Verordnung 2022/2554, ergänzt durch eine begleitende Richtlinie, die mehrere sektorale Richtlinien ändert. Sie ist seit dem 17. Januar 2025 EU-weit anwendbar. Es handelt sich um eine Verordnung, nicht um eine Richtlinie, daher gilt sie in den Mitgliedstaaten unmittelbar, ohne nationales Umsetzungsgesetz. Zypern ist als EU-Mitgliedstaat im selben Zeitrahmen erfasst wie alle anderen.
DORA existiert, weil Finanzaufseher es satt hatten, IKT-Vorfälle als operative Fußnote behandelt zu sehen. Die Verordnung bündelt, was zuvor verstreut in Leitlinien, aufsichtlichen Erwartungen und informeller guter Praxis lag, in einem einzigen verbindlichen Regime mit fünf konkreten Säulen: IKT-Risikomanagement, IKT-bezogene Vorfallsberichterstattung, Tests der digitalen operationalen Resilienz, IKT-Drittparteienrisikomanagement und Vereinbarungen zum Informationsaustausch.
Die zuständigen Europäischen Aufsichtsbehörden (EBA, ESMA und EIOPA, gemeinsam die ESAs) haben Regulatory Technical Standards und Implementing Technical Standards veröffentlicht, die den abstrakten Gesetzestext mit konkreten Werten und Vorlagen unterlegen. CySEC, die nationale zuständige Behörde für Wertpapierfirmen in Zypern, beaufsichtigt die Einhaltung durch CIFs und hat eigene Rundschreiben und Hinweise veröffentlicht, die auf die relevanten ESA-Outputs verweisen.
Für CTOs in PHP-geprägten Teams lautet die praktische Botschaft: DORA ist keine Checkliste, die der Compliance Officer abhakt. Fast jede Säule landet bei Engineering-Entscheidungen. Das Compliance-Team kann den Papierkram bearbeiten, kann aber die technischen Fragen einer Aufsichtsbehörde nicht beantworten, wenn man jemals vor ihr sitzt.
Wer in Zypern erfasst ist
Die kurze Version: Die meisten CIFs sind erfasst, mit Verhältnismäßigkeit.
Die lange Version: DORA gilt für eine in Artikel 2 definierte Liste von Finanzunternehmen, darunter Kreditinstitute, Zahlungsinstitute, E-Geld-Institute, Wertpapierfirmen, Krypto-Dienstleister, zentrale Gegenparteien, Transaktionsregister, Fondsverwalter und weitere. Für Zypern bedeutet das: Erfasst sind die CySEC-regulierten Kategorien, die zur DORA-Liste der Finanzunternehmen passen, darunter CIFs, Zentralverwahrer, Handelsplätze, CASPs, AIFMs und UCITS-Verwaltungsgesellschaften. Dazu kommen Banken und einschlägige Zahlungs- oder E-Geld-Institute unter Aufsicht der Zentralbank Zyperns sowie zyprische Niederlassungen von EU-Kreditinstituten, soweit die DORA-Kriterien erfüllt sind.
Verhältnismäßigkeit ist eingebaut. Kleinere und weniger komplexe Unternehmen unterliegen einem leichteren Regime im Rahmen des vereinfachten IKT-Risikomanagement-Frameworks. Die Schwellen und Definitionen, wer als “Kleinstunternehmen” gilt oder unter den vereinfachten Weg fällt, stehen im Text und in den ESA-RTS, nicht in unseren Köpfen. Wir schätzen das für Kunden nicht aus dem Bauch heraus. Wir bestätigen es schriftlich anhand der aktuellen Kriterien.
Für die meisten Leser dieses Beitrags ist der realistische Fall: “Eine kleine oder mittelgroße CIF, deren PHP-Backoffice in der EU läuft, mit einer Handvoll kritischer IKT-Drittanbieter, ohne internes Trading-Modell, und mit einem Compliance Officer, der ohnehin schon zu viel zu tun hat.” Dieses Setup ist klar erfasst, mit deutlicher Verhältnismäßigkeit auf der Testing-Säule, aber minimaler Verhältnismäßigkeit bei Vorfallsberichterstattung und Drittparteienrisiko.
Die fünf Säulen und was sie für ein PHP-Backoffice bedeuten
IKT-Risikomanagement
DORA erwartet ein dokumentiertes, durch die Geschäftsleitung genehmigtes IKT-Risikomanagement-Framework, das den gesamten Lebenszyklus der vom Unternehmen genutzten IKT-Assets abdeckt. Für ein Symfony-Backoffice muss das Framework spezifisch genug sein, um die tatsächliche Umgebung zu beschreiben, statt generisches Copy-and-paste zu liefern.
Die Fragen, die Aufseher zunehmend stellen und die ein Tech-Lead beantworten können sollte, sehen so aus:
- Welche IKT-Assets stützen welche kritischen oder wichtigen Funktionen, und wo wird diese Zuordnung aktuell gehalten?
- Wer genehmigt wesentliche Änderungen an der Produktivumgebung des Backoffices, und ist diese Genehmigung auditierbar?
- Wie hoch sind RTO und RPO für die Systeme, die Kundengelder oder -positionen berühren, und wie wird das getestet?
- Wie ist der Zugriff auf Produktivsysteme von der Entwicklung getrennt, und wie wird privilegierter Zugriff protokolliert?
Für ein PHP-Team bedeutet “das Framework” üblicherweise: ein aktuelles System-Inventar (oft eine Tabelle, manchmal eine CMDB), dokumentierte Deployment- und Change-Prozesse (üblicherweise in einem Wiki und in der CI-Pipeline), explizite RTOs und RPOs pro kritischem Service und eine Zugriffsverwaltung, die einer externen Prüfung standhält. Die Symfony-Teile selbst sind einfach. Die Disziplin, die Dokumentation ehrlich zu halten, ist der schwere Teil, und das ist auch der Teil, den Aufseher zuerst hinterfragen.
IKT-bezogene Vorfallsberichterstattung
Das ist die Säule, die Engineering-Teams am häufigsten überrascht, weil sie Klassifikations- und Berichtsarbeit unter Zeitdruck setzt.
Unter DORA müssen IKT-bezogene Vorfälle anhand von Kriterien klassifiziert werden, die von den ESAs definiert sind, darunter Auswirkungen auf Kunden, geografische Verbreitung, Dauer, wirtschaftliche Auswirkungen, Datenverluste und Kritikalität der betroffenen Dienste. “Schwerwiegende IKT-bezogene Vorfälle” lösen einen formalen Berichtsfluss an die zuständige Behörde aus, mit definiertem Zeitrahmen für eine erste Meldung, einen Zwischenbericht und einen Abschlussbericht.
Für Engineering-Teams heißt das drei Dinge:
- Logs und Observability müssen gut genug sein, um Vorfallszeitleisten und -auswirkungen im Nachhinein rekonstruieren zu können. Symfony-Monolog-Konfiguration und APM-Stack sind dafür nicht optional. Zentralisiert, durchsuchbar, zeitsynchronisiert, mit Aufbewahrung mindestens für die Zeitspanne, die der Berichtszyklus impliziert.
- Ein Klassifikationsprozess, den ein Nicht-Ingenieur mit Engineering-Input ausführen kann, ist nötig. Die meisten Teams bauen das zu klein und merken beim ersten Vorfall, dass der Compliance Officer ohne drei Stunden Engineering-Zeit, die er nicht hat, nicht entscheiden kann, ob etwas “schwerwiegend” ist.
- Eine getestete Kommunikationskette ist nötig, damit beim Vorliegen eines schwerwiegenden Vorfalls die Fristen nicht verstreichen, während diskutiert wird, wer wem schreibt.
Erhebliche Cyber-Bedrohungen sind unter DORA freiwillig meldbar. Die meisten Firmen ignorieren das. Manche setzen es strategisch ein, besonders rund um Lieferketten-Vorfälle, die sie aktenkundig haben wollen.
Tests der digitalen operationalen Resilienz
Jedes erfasste Unternehmen muss ein grundlegendes Programm für Tests der digitalen operationalen Resilienz fahren, verhältnismäßig zu Größe und Risikoprofil. Dazu gehören Schwachstellenanalysen, Netzwerksicherheitstests, gegebenenfalls Quellcode-Reviews, Lasttests und szenariobasierte Tests.
Für ein PHP-Backoffice heißt das praktisch: Ein echtes Testprogramm ist nötig, kein “Wir lassen PHPStan in CI laufen.” PHPStan und ähnliche statische Analyse sind als Teil des Gesamtbilds nützlich, aber der Regulierer fragt nach einem dokumentierten, geplanten Programm, das Nachweise erzeugt und mehr abdeckt als nur Code-Linting.
Eine Teilmenge höher riskanter Unternehmen, die von der zuständigen Behörde identifiziert wird, unterliegt zusätzlich bedrohungsgeleiteten Penetrationstests, mindestens alle drei Jahre, unter einem Rahmenwerk mit klarer Linie aus TIBER-EU. Ob man in dieser Teilmenge ist, sollte schriftlich anhand der aktuellen Kriterien beantwortet werden, nicht geraten. Die meisten kleinen CIFs sind nicht erfasst. Die meisten Firmen, deren PHP-Backoffices wir betreut haben, waren es nicht. Die, die es waren, wussten es.
IKT-Drittparteienrisikomanagement
Das ist die Säule, die einen typischen PHP-Stack am härtesten trifft.
DORA erwartet einen strukturierten Umgang mit IKT-Drittanbietern, einschließlich eines Informationsregisters, das gepflegt und jährlich an die zuständige Behörde übermittelt werden muss. Für CySEC-regulierte Unternehmen nennt die CySEC-Leitlinie von 2026 den 28. Februar als jährliche Einreichungsfrist, mit dem 31. Dezember als Stichtag. Das Register listet die genutzten IKT-Dienste, Kritikalität jedes Dienstes, vertragliche Vereinbarungen, Ort der Datenverarbeitung und mehrere weitere Felder, die in den ESA-ITS definiert sind.
Für eine Symfony-Codebase ist die tatsächliche Zahl der Drittanbieter größer, als viele Teams zunächst vermuten. Sie umfasst:
- Den Hosting-Anbieter und jede gemanagte Kubernetes- oder PaaS-Schicht.
- Das Datenbank-Hosting (managed PostgreSQL, MySQL).
- E-Mail- und Transactional-Message-Anbieter.
- Error-Tracking-, APM- und Observability-Plattformen.
- Die CI/CD-Plattform.
- Authentifizierungsanbieter, falls genutzt.
- Kritische Drittbibliotheken, von denen man in regulierten Workflows abhängt (Hinweis: Paket-Abhängigkeiten sind nicht immer “IKT-Drittdienste” im Sinne der DORA-Definition, aber die aufsichtliche Erwartung ist, sie beschreiben und ihre Risiken einordnen zu können).
Der Vertragsinhalt für Vereinbarungen, die kritische oder wichtige Funktionen stützen, ist nicht trivial. DORA definiert spezifische verpflichtende Vertragsbestandteile, darunter Service-Level-Beschreibungen, Ort der Datenverarbeitung, Auditrechte, Exit-Strategien und Zusammenarbeit mit Aufsichtsbehörden. Wer vor zwei Jahren Standard-SaaS-Bedingungen unterschrieben hat, erfüllt mit hoher Wahrscheinlichkeit nicht die DORA-Pflichtinhalte für Anbieter kritischer Funktionen. Es muss nachverhandelt, der Anbieter gewechselt oder ein dokumentiertes Restrisiko akzeptiert werden.
Kritische IKT-Drittanbieter können von den ESAs benannt und direkt beaufsichtigt werden. Die erste EU-weite CTPP-Liste wurde im November 2025 veröffentlicht und umfasst große Cloud-Anbieter. Die meisten Anbieter in einem typischen PHP-Backoffice sind nicht benannt, aber die, die es sind, bringen Pflichten mit, die das Verhältnis verändern.
Vereinbarungen zum Informationsaustausch
DORA ermutigt, verlangt aber nicht, dass Finanzunternehmen an Informationsaustausch-Vereinbarungen zu Cyber-Bedrohungen und Indicators of Compromise teilnehmen. Für eine kleine CIF mit einem PHP-Backoffice ist diese Säule meist prozessual: Entscheiden, ob teilgenommen wird, Entscheidung dokumentieren, regelmäßig prüfen.
Verhältnismäßigkeit: Was kleinere CIFs realistisch tun müssen
Die Versuchung, DORA als “Wir müssen das alles tun” zu lesen, führt zu Über-Engineering und verpassten Fristen. Der Text und die ESA-RTS bauen Verhältnismäßigkeit an mehreren Stellen ein.
Eine wirklich kleine CIF, die ein Symfony-Backoffice in einer einzigen EU-Region mit einer Handvoll Anbietern und ohne interne Tradingmodelle betreibt, muss realistisch:
- Ein echtes, aktuelles IKT-Risikomanagement-Framework pflegen, durch die Geschäftsleitung genehmigt, mit den Dokumenten und Inventaren, die belegen, dass das Framework in der Praxis und nicht nur auf Papier existiert.
- Einen Klassifikations- und Berichtsprozess für Vorfälle führen, der die DORA-Fristen einhalten kann, einschließlich mindestens jährlich getesteter Kommunikationsketten.
- Ein dokumentiertes Resilienz-Testprogramm fahren, verhältnismäßig zur Firmengröße, üblicherweise Schwachstellenscans, Konfigurationsreviews, szenariobasierte Übungen und Quellcode-Review, wenn intern entwickelt wird. TLPT ist meist nicht im Scope.
- Ein Informationsregister für IKT-Drittanbieter pflegen, mit Vertragsbestandteilen für Anbieter kritischer Funktionen, die auf DORA-Pflichtinhalte gebracht wurden.
- Die Position der Firma zum Informationsaustausch entscheiden und dokumentieren.
Das ist für ein kleines Team machbar. Es ist nicht nebenbei in einem Sprint machbar. Die meisten Firmen, mit denen wir arbeiten, haben dafür über mehrere Quartale dedizierte Engineering-Zeit eingeplant, und wir würden nicht raten, das in eine normale Produkt-Roadmap zu drücken.
Wie das in einer Symfony-Codebase tatsächlich aussieht
Ein paar Muster, die sich bewährt haben.
Strukturiertes Logging ist nicht verhandelbar. Monolog mit JSON-Formatter, Kanaltrennung zwischen Application-, Audit- und Security-Events, zentralisierte Sammlung (wir haben in unterschiedlichen Stacks Elastic, Loki und CloudWatch genutzt) und Aufbewahrung passend zur erwarteten Dauer des Berichtszyklus. Wenn das Audit-Log in var/log/prod.log auf einer einzelnen VM lebt, ist das ein absehbarer Prüfungsbefund.
Audit-Logging gehört in den Domain-Code, nicht in die Middleware. Ein echtes Audit-Log deckt Geschäftsereignisse ab (“Nutzer X öffnete Position Y zu Zeit Z unter Rolle R”) und verknüpft sie mit System-Events (HTTP-Request-ID, Deployment-Hash, Quell-IP). Doctrine-Listener fangen Entity-Änderungen gratis ab, der schwierigere Teil ist die Korrelation zu Geschäftsaktionen. Wir veröffentlichen Audit-Events üblicherweise per Symfony Messenger an einen dedizierten Audit-Consumer, getrennt von der Hauptdatenbank, mit unabhängig kontrollierter Aufbewahrung.
Configuration Management ist Teil des Frameworks. DORA erwartet dokumentierte Kontrolle über wesentliche Änderungen. Die CI-Pipeline, das Infrastructure-as-Code-Repository und der Deployment-Freigabeprozess sind Teil der Beweislage. Wenn sie in drei Systemen ohne gemeinsame Audit-Spur leben, passt das Framework auf Papier nicht zum Framework in der Praxis.
Backups und Disaster Recovery müssen getestet werden, nicht nur konfiguriert. Symfony, PostgreSQL und ein gemanagtes Backup sind der einfache Teil. In eine saubere Umgebung zurückzuspielen, Datenintegrität zu validieren und die Dauer der Wiederherstellung zu messen, ist der schwere Teil. Wir planen für betroffene Kunden mindestens eine vollständige Disaster-Recovery-Übung pro Jahr und halten die Artefakte (Run-Logs, Zeiten, getroffene Entscheidungen) für die Aufsicht bereit.
Drittpartei-Inventar lebt neben dem Dependency-Graph. Wir haben mehrere Kunden weg von “Das Compliance-Team pflegt das Register” hin zu “Das Engineering-Team besitzt das Register, Compliance prüft” verschoben. Das Register muss die Produktivrealität widerspiegeln, und Engineering ist die einzige Funktion, die diese Realität kennt.
Häufige Fehler, die wir sehen
Eine kurze Liste, geschrieben aus Kunden, die wir aufräumen geholfen haben:
- DORA als Dokumentations-Übung behandeln. Dokumente, die nicht zum System passen, sind schlimmer als gar keine.
- Annehmen, SaaS-AGB aus der Zeit vor 2023 seien DORA-konform. Für Anbieter kritischer Funktionen sind sie es so gut wie sicher nicht.
- “Kritische oder wichtige Funktion” zu eng definieren. Trading, Verwahrung und Onboarding sind offensichtlich. Reporting-Pipelines, die Aufseher versorgen, werden manchmal vergessen und qualifizieren oft.
- Die Zeit unterschätzen, die nötig ist, einen Vorfall nach DORA-Kriterien zu klassifizieren. Das Runbook vor dem Vorfall bauen, nicht währenddessen.
- Das Informationsregister mit einer generischen Lieferantenliste verwechseln. Das Register hat eine spezifische Struktur, die in den ESA-ITS definiert ist. Vorlage nutzen, nicht freie Tabelle.
Die ehrliche Zusammenfassung
DORA ist keine technische Regulierung in dem Sinne, dass sie vorschreibt, welchen Code man schreibt. Es ist eine Governance-Regulierung, die im Engineering landet, weil fast alles, was sie verlangt, im Stack und in den Prozessen umgesetzt wird, nicht in Policies. Für eine CySEC-regulierte Firma, die in Zypern ein PHP- oder Symfony-Backoffice betreibt, ist Compliance machbar, aber sie ist Engineering-Arbeit, kein Papierkram.
Wer das liest und dessen Firma DORA noch nicht als Engineering-Verantwortung behandelt, fragt am einfachsten zuerst: “Wer auf der Engineering-Seite kann die Fragen einer Aufsichtsbehörde zu unserem IKT-Risiko-Framework, unserem Klassifikationsprozess für Vorfälle, unserem Resilienz-Testprogramm und unserem Drittparteien-Register beantworten?” Wenn die Antwort “Wir müssten zurückkommen” lautet, ist das der Startpunkt.
Wir helfen Firmen in genau dieser Lage, und wir hätten lieber ein frühes ehrliches Gespräch als eine teure Sanierung später.
Referenzen
- DORA, Verordnung (EU) 2022/2554: https://eur-lex.europa.eu/eli/reg/2022/2554/oj
- Begleitrichtlinie (EU) 2022/2556: https://eur-lex.europa.eu/eli/dir/2022/2556/oj
- Gemeinsame Leitlinien der ESAs zu DORA-RTS und -ITS: https://www.esma.europa.eu, https://www.eba.europa.eu, https://www.eiopa.europa.eu
- CySEC, Rundschreiben und Hinweise zur DORA-Umsetzung: https://www.cysec.gov.cy
- TIBER-EU-Rahmen, EZB: https://www.ecb.europa.eu/paym/cyber-resilience/tiber-eu
