Regulatorik-Update: CRA, DORA und die nächsten Fristen für 2027 im Blick behalten

Wenn IT-Führungskräfte auf das Jahr 2026 zurückblicken, wird es als das Jahr in die Geschichte eingehen, in dem die NIS-2-Richtlinie die Budgets und Roadmaps diktierte. Viele Organisationen haben massive Kraftanstrengungen unternommen, um ihre IT-Sicherheitsprozesse zu härten, Meldewege zu etablieren und Evidenzen für Auditoren zu generieren. Das kollektive Aufatmen nach dem erfolgreichen Abschluss dieser Projekte ist in der Branche deutlich spürbar.

Doch wer glaubt, dass nun eine Phase der regulatorischen Entspannung eintritt, irrt sich gewaltig. Der europäische Gesetzgeber hat in den letzten Jahren ein dichtes, ineinandergreifendes Netz an Cyber-Gesetzen gewebt. NIS-2 war lediglich das Fundament. Mit dem Cyber Resilience Act (CRA) und dem Digital Operational Resilience Act (DORA) stehen die nächsten, noch spezifischeren Regularien bereits in den Startlöchern für 2027.

In diesem Beitrag geben wir ein strategisches Regulatorik-Update. Wir erklären, worauf Sie sich jetzt vorbereiten müssen, wie sich DORA und CRA von NIS-2 unterscheiden und – am wichtigsten – warum Sie nicht für jedes Gesetz ein neues Tool kaufen dürfen, sondern eine zentrale Datenbasis benötigen.

DORA: Die digitale Belastungsprobe für den Finanzsektor

Beginnen wir mit DORA. Während NIS-2 einen sehr breiten Ansatz über 18 Schlüsselsektoren verfolgt, ist DORA ein hochspezifisches Regelwerk für den europäischen Finanzsektor (Banken, Versicherungen, Krypto-Dienstleister) – und für deren IT-Dienstleister (ICT Third-Party Providers).

Selbst wenn Sie keine Bank sind: Sobald Sie IT-Services für den Finanzsektor erbringen, fallen Sie mit extrem hoher Wahrscheinlichkeit in den Geltungsbereich von DORA. Das Ziel von DORA ist es sicherzustellen, dass das europäische Finanzsystem auch bei schweren operativen Störungen (wie einem massiven Cloud-Ausfall oder einem koordinierten Cyberangriff) funktionsfähig bleibt.

Die Kernanforderung von DORA: Das IKT-Risikomanagement

DORA verlangt von Unternehmen ein nahezu perfektes Informations- und Kommunikationstechnologie (IKT) Risikomanagement. Artikel 8 der DORA-Verordnung ist für IT-Leiter besonders brisant. Er fordert die "Identifizierung, Klassifizierung und angemessene Dokumentation aller IKT-gestützten Geschäftsfunktionen, Informationswerte und IKT-Assets".

Das bedeutet: Sie müssen nicht nur wissen, dass Sie einen Server betreiben. Sie müssen lückenlos dokumentieren, welcher Server welchen Finanzprozess stützt, wie kritisch dieser Prozess ist und welche externen Cloud-Provider (Third-Party Risk) daran beteiligt sind. Ohne ein automatisiertes Dependency Mapping (Abhängigkeitsanalyse) in einer modernen CMDB ist diese DORA-Forderung in hybriden Umgebungen praktisch unerfüllbar.

CRA: Das Ende der unsicheren Lieferketten

Der Cyber Resilience Act (CRA) zielt in eine andere Richtung: auf die Hersteller von Hard- und Software. Wie wir bereits in früheren Beiträgen (Stichwort: SBOMs) analysiert haben, müssen Produkte mit "digitalen Elementen" künftig strenge Sicherheitsvorgaben erfüllen, um ein CE-Kennzeichen zu erhalten.

Für Sie als Betreiber und Anwender bedeutet das Jahr 2027 den Übergang in eine neue Ära des Patch-Managements und des End-of-Life-Trackings (EOL). Hersteller werden gezwungen, Schwachstellen zu publizieren und Patches bereitzustellen.

Ihre Pflicht: Sie müssen in Echtzeit wissen, ob eine frisch vom Hersteller gemeldete Schwachstelle (CVE) in Ihrem Netzwerk existiert. Die Zeiten, in denen eine veraltete Software monatelang unentdeckt auf einem Test-Server laufen konnte, sind vorbei. Wenn Sie die vom CRA forcierten Patches nicht zeitnah installieren und dadurch gehackt werden, haften Sie als Betreiber vollumfänglich.

Eine einzige Wahrheit für alle Gesetze

NIS-2, DORA, CRA, DSGVO, BSI IT-Grundschutz, ISO 27001 – die Liste der Kürzel wird immer länger. Wenn Sie versuchen, jede dieser Regulierungen mit einem eigenen Projekt, einem eigenen Compliance-Manager und einer eigenen Excel-Tabelle zu befriedigen, treiben Sie Ihr Unternehmen in den administrativen Ruin (Compliance Fatigue).

Das Geheimnis erfolgreicher Organisationen ist die Erkenntnis, dass sich die Forderungen all dieser Gesetze in einem einzigen, zentralen Punkt überschneiden: Der Forderung nach lückenloser Transparenz und historischer Nachweisbarkeit der IT-Assets.

• DORA braucht die Assets für die Auswirkungsanalyse im Finanzbereich.
• Der CRA braucht die Assets für das SBOM- und Patch-Tracking.
• NIS-2 braucht die Assets für das generelle Risikomanagement und das Incident Reporting.

Die Lösung: Eine Unified Asset Data Plattform wie Qbilon. Indem Sie Ihre Cloud-Umgebungen, Virtualisierungsserver, Netzwerke und Security-Tools einmalig über APIs anbinden, erschaffen Sie die universelle "Single Source of Truth". Wenn der DORA-Prüfer kommt, filtern Sie die Ansicht auf Ihre Finanzprozesse und zeigen die Abhängigkeiten (Dependency Mapping). Wenn der ISO-Auditor kommt, zeigen Sie die historische Patch-Compliance (Time Machine). Sie befriedigen ein Dutzend Regulatoren aus einer einzigen, automatisierten Datenquelle.

Fazit: Bauen Sie ein Fundament, das Skalierung zulässt

Regulierung ist der neue Normalzustand in der IT. Wer sich vor jedem neuen Gesetz fürchtet, hat sein Fundament noch nicht im Griff.

Hören Sie auf, Compliance rückwärtsgewandt für das letzte Audit zu betreiben. Richten Sie Ihren Blick auf 2027. Mit einer datengetriebenen, automatisierten CMDB etablieren Sie ein IT-Gedächtnis, das so agil und vollständig ist, dass Sie dem nächsten Gesetzesentwurf aus Brüssel vollkommen entspannt entgegensehen können. Transparenz ist das einzige universelle Heilmittel gegen regulatorischen Stress.