NIS2, DORA und EU AI Act: Drei Rahmenwerke, eine Infrastruktur-Ebene.
Unternehmen in regulierten Branchen arbeiten selten unter einem einzigen Anforderungsrahmen. NIS2, DORA und EU AI Act adressieren auf unterschiedlichen Wegen dieselbe technische Grundlage: die Infrastruktur-Ebene, auf der digitale Systeme Daten aufnehmen, verarbeiten und schützen. Diese Seite erklärt die Anforderungen der drei Rahmenwerke, ihre Überschneidungen und die technischen Signale, die als Baustein in ein Audit in diesen Kontexten einfließen können.
Diese Seite dient der technischen Orientierung und stellt keine Rechtsberatung dar. Die Einschätzung regulatorischer Pflichten im Einzelfall obliegt qualifizierten Rechts- und Compliance-Beratern.
Die Network and Information Security Directive: Anforderungen an kritische Infrastruktur
Die NIS2-Richtlinie ist in Deutschland umgesetzt: Das NIS2-Umsetzungsgesetz (NIS2UmsuCG) wurde am 5./6. Dezember 2025 im Bundesgesetzblatt verkündet und ist am 6. Dezember 2025 ohne Übergangsfrist in Kraft getreten. Die BSI-Registrierungsfrist lief am 6. März 2026 ab; betroffen sind rund 29.500 Einrichtungen. Die Richtlinie erweitert den Anwendungsbereich der ursprünglichen NIS-Richtlinie erheblich und verschärft die Anforderungen an Cybersicherheit und Meldepflichten.
Wer unter NIS2 fällt
NIS2 unterscheidet zwischen wesentlichen und wichtigen Einrichtungen. Wesentliche Einrichtungen umfassen Betreiber in den Bereichen Energie, Verkehr, Bankwesen, Finanzmarktinfrastruktur, Gesundheit, Trinkwasser, Abwasser, digitale Infrastruktur, öffentliche Verwaltung und Weltraum. Wichtige Einrichtungen umfassen Post- und Kurierdienste, Abfallwirtschaft, Chemie, Lebensmittel, verarbeitendes Gewerbe, digitale Anbieter und Forschungseinrichtungen.
Die Klassifikation richtet sich nach Unternehmensgröße und Sektor. Unternehmen mit mehr als 50 Mitarbeitenden oder einem Jahresumsatz von mehr als 10 Millionen Euro in einem der genannten Sektoren fallen in den Anwendungsbereich.
Was NIS2 technisch voraussetzt
NIS2 verlangt geeignete und verhältnismäßige technische, operative und organisatorische Maßnahmen zur Beherrschung von Risiken für die Sicherheit der Netz- und Informationssysteme. Die technischen Anforderungen umfassen Konzepte für Risikoanalyse und Informationssicherheit, Maßnahmen zur Bewältigung von Sicherheitsvorfällen, Business-Continuity-Maßnahmen, Sicherheit in der Lieferkette, Maßnahmen zur Sicherheit beim Erwerb, Entwicklung und Wartung von Netz- und Informationssystemen sowie Verschlüsselung und kryptografische Verfahren.
Kryptografische Verfahren, DNS-Konfiguration, Zugangskonfiguration und Infrastruktur-Integrität sind technische Parameter, die als Baustein in ein NIS2-Audit einfließen können — sie decken jedoch nur einen Ausschnitt des organisationsweiten Risikomanagements nach § 30 NIS2UmsuCG ab.
Der Digital Operational Resilience Act: Anforderungen für Finanzunternehmen
DORA — die Verordnung (EU) 2022/2554 — gilt seit dem 17. Januar 2025 verbindlich für Finanzunternehmen in der EU. Sie definiert einheitliche Anforderungen an die digitale operationale Resilienz des Finanzsektors: IKT-Risikomanagement, Incident Reporting, Resilienztests, Drittparteienrisiko und das Register of Information.
Wer unter DORA fällt
DORA gilt für ein breites Spektrum von Finanzunternehmen: Kreditinstitute, Zahlungsinstitute, E-Geld-Institute, Wertpapierfirmen, Anbieter von Krypto-Asset-Dienstleistungen, Zentralverwahrer, zentrale Gegenparteien, Handelsplätze, Transaktionsregister, Verwalter alternativer Investmentfonds, Verwaltungsgesellschaften, Datenbereitstellungsdienstleister, Versicherungs- und Rückversicherungsunternehmen, Versicherungsvermittler sowie IKT-Drittdienstleister, die Finanzunternehmen beliefern.
Der letzte Punkt ist für viele Technologieunternehmen relevant: Wer als Softwareanbieter oder Infrastrukturdienstleister Finanzunternehmen beliefert, fällt als IKT-Drittdienstleister in den DORA-Scope.
Was DORA technisch voraussetzt
DORA definiert Anforderungen in fünf Bereichen: IKT-Risikomanagement, Management von IKT-bezogenen Vorfällen, Testen der digitalen operationalen Resilienz, Management des IKT-Drittparteienrisikos und Informationsaustausch. Die technischen Anforderungen an IKT-Systeme und ihre Infrastruktur umfassen Maßnahmen zur Erkennung anomaler Aktivitäten, Schutz- und Präventionsmaßnahmen auf Infrastruktur-Ebene, kontinuierliche Überwachung und Dokumentation sowie Anforderungen an Drittanbieter in der Lieferkette.
Die öffentliche Infrastruktur-Posture eines IKT-Drittdienstleisters kann als ein Input in die Drittanbieter-Risikobewertung nach DORA Art. 28 dienen — sie ersetzt weder IKT-Risikomanagement, Incident Reporting, Resilienztests noch das Register of Information.
Wo NIS2, DORA und EU AI Act dieselbe Infrastruktur-Ebene adressieren
Die drei Anforderungsrahmen entstammen unterschiedlichen regulatorischen Kontexten. Auf der technischen Infrastruktur-Ebene adressieren sie jedoch überschneidende Parameter.
Kryptografische Integrität
NIS2 verlangt den Einsatz kryptografischer Verfahren. DORA verlangt Schutzmaßnahmen für IKT-Systeme. Art. 50 EU AI Act verlangt maschinenlesbare Transparenz und verifizierbare Provenienz für KI-Systeme. Alle drei Anforderungen sind auf derselben Infrastruktur-Ebene verankert: DNS-Konfiguration, TLS-Zertifikatskette, DNSSEC und HTTP-Sicherheitsheader.
Datenquellen-Integrität
NIS2 stellt Anforderungen an die Sicherheit in der Lieferkette. DORA stellt Anforderungen an das IKT-Drittparteienrisiko. Art. 50 EU AI Act stellt Anforderungen an die Transparenz und Provenienz der KI-Ausgaben und Datenquellen. Alle drei Anforderungen berühren dieselbe technische Frage: Sind externe Datenquellen verifizierbar integer?
Dokumentationspflicht
Alle drei Rahmenwerke setzen eine strukturierte, auditfähige Dokumentation voraus. Ein Nachweis, der die technische Infrastruktur-Integrität kryptografisch signiert und jederzeit abrufbar dokumentiert, bildet die gemeinsame Dokumentationsgrundlage für alle drei Anforderungsrahmen.
Kontinuierliche Überwachung
NIS2 und DORA verlangen kontinuierliche Überwachung und Meldepflichten bei Vorfällen. Art. 50 EU AI Act verlangt die fortlaufende Sicherstellung maschinenlesbarer Transparenz. Quartalsweise Re-Scans und Änderungsbenachrichtigungen bilden die technische Grundlage für diese Kontinuitätsanforderung.
Was ein Audit in allen drei Kontexten prüft
Ein Auditor, der eine Infrastruktur unter NIS2-, DORA- oder EU-AI-Act-Gesichtspunkten prüft, stellt in allen drei Kontexten überschneidende technische Fragen.
DNS und kryptografische Grundkonfiguration
DNSSEC-Konfiguration, CAA-Records, TLS-Zertifikatskette und Zertifikats-Transparenz sind in allen drei Anforderungsrahmen prüfrelevant. Lücken auf dieser Ebene sind in einem Audit direkt sichtbar und dokumentiert.
HTTP-Sicherheitsheader
HSTS, CSP, X-Frame-Options, X-Content-Type-Options und Referrer-Policy sind standardisierte Schutzmaßnahmen auf Infrastruktur-Ebene. Ihre korrekte Konfiguration ist ein Prüfparameter im CERTavia-Scan und kann als technischer Baustein in NIS2- und DORA-Prüfungen einfließen.
Zugangskonfiguration für automatisierte Systeme
Die Konsistenz zwischen deklarierter Crawler-Konfiguration und tatsächlicher Infrastruktur-Antwort ist unter DORA und NIS2 als Teil des Drittparteienrisikos relevant. Unter EU AI Act ist sie Bestandteil der Consent Declaration Integrity.
Maschinenlesbare Governance-Deklaration
AI Policy URL, Datenschutz-KI-Abschnitt, Deepfake-Disclaimer und benannte Kontaktstelle für KI-Anfragen sind unter Art. 50 EU AI Act Transparenzanforderungen. Ihre maschinenlesbare Umsetzung stärkt gleichzeitig die Dokumentationsgrundlage für NIS2 und DORA.
Lieferketten-Integrität
NIS2 und DORA stellen explizit Anforderungen an die Integrität der Lieferkette. Softwareanbieter und IKT-Drittdienstleister, die Unternehmen in regulierten Bereichen beliefern, stehen unter zunehmendem Druck, einen belegbaren Infrastruktur-Status nachzuweisen.
Welche Branchen unter allen drei Rahmenwerken stehen
Finanzsektor
Banken, Versicherungen und Finanzdienstleister unterliegen DORA vollständig und fallen in den NIS2-Bereich wesentlicher Einrichtungen. KI-Systeme im Kreditscoring, der Bonitätsbewertung und der Risikoklassifikation fallen zusätzlich unter Annex III Nr. 5 des EU AI Act. Die Infrastruktur-Ebene dieser Systeme ist Gegenstand aller drei Anforderungsrahmen gleichzeitig.
Healthcare
Krankenhäuser und Gesundheitseinrichtungen sind wesentliche Einrichtungen unter NIS2. KI-Systeme in der Diagnostik und im Patientenmanagement fallen unter Annex III Nr. 2 des EU AI Act. Die technische Infrastruktur-Ebene dieser Systeme steht unter den kombinierten Anforderungen beider Rahmenwerke.
Kritische Infrastruktur
Betreiber in den Bereichen Energie, Wasser und Verkehr sind wesentliche Einrichtungen unter NIS2. KI-Systeme in der Steuerung und Überwachung dieser Infrastruktur fallen unter Annex III Nr. 2 des EU AI Act. Die Überschneidung der Anforderungen ist in diesem Bereich am stärksten ausgeprägt.
IKT-Drittdienstleister
Softwareanbieter und Infrastrukturdienstleister, die Finanzunternehmen beliefern, fallen als IKT-Drittdienstleister unter DORA. Beliefern sie gleichzeitig Betreiber kritischer Infrastruktur, greift zusätzlich NIS2. Ein belegbarer Infrastruktur-Status ist in Ausschreibungsprozessen und Lieferantenqualifikationen dieser Branchen ein zunehmend gefragtes Dokument.
Eine Infrastruktur-Ebene, die mehrere Rahmenwerke technisch berühren
CERTavia erzeugt maschinell verifizierbare Layer-0-Evidenz der öffentlichen Infrastruktur einer Domain. Diese Evidenz ist primär ein EU-AI-Act-Art.-50-Artefakt; dieselben öffentlichen Infrastruktur-Signale werden von NIS2 (Lieferkette, § 30) und DORA (Drittparteienrisiko, Art. 28) mit betrachtet.
Das Ergebnis ist ein kryptografisch signiertes, DNS-verankertes Nachweisdokument. Im Enterprise-Paket bündelt CERTavia diese Layer-0-Evidenz als konsolidierte Infrastruktur-Evidenz mit Art.-50-Bezug und Zuordnung zu NIS2- und DORA-relevanten Signalen — kein DORA-Reporting im Sinne von Incident Reports oder Register of Information.
Der Sovereign Vault Link ist an externe Auditoren, Notified Bodies und Behörden weiterleitbar. Die maschinenlesbare Verifikations-URL ermöglicht die automatisierte Statusabfrage durch externe Prüfsysteme.
Weiterführende Seiten
Risikoklassen, Enforcement-Phasen und technische Infrastruktur-Implikationen im Überblick.
Annex III — Hochrisiko-KI im Detail →Die Hochrisiko-Kategorien und technischen Anforderungen für Unternehmen unter Annex III.
EU AI Act Schnelltest: Annex-III-Risiko in zwei Minuten evaluieren →Fragen und Antworten zur Einschätzung der eigenen Risikoklasse.
CERTavia für Compliance-Teams →Strukturierte Dokumentation für Audits unter EU AI Act, NIS2 und DORA.
CERTavia für Vorstände und Entscheider →Auditfähiger Nachweis für Prüfer, Investoren und den Aufsichtsrat.
CERTavia für CISOs →Externe Evidenz für Risikoregister, Drittanbieter-Risiko und NIS2 Art. 21 Risikomanagementmaßnahmen.
NIS2 und Hochrisiko-KI: Wer ist betroffen? (Blog) →Welche Unternehmen unter NIS2 fallen, was die Richtlinie verlangt und warum Infrastruktur-Nachweis entscheidend ist.
NIS2 Pflichten und Umsetzung: Handlungsempfehlungen (Blog) →Konkrete Schritte für NIS2-Compliance mit Hochrisiko-KI – von Scope-Klärung bis technischer Evidenz.
Eine Infrastruktur-Ebene, die EU AI Act, DORA und NIS2 technisch berühren.
CERTavia liefert maschinell verifizierbare Layer-0-Evidenz — primär ein Art.-50-Artefakt. Als ein Input in die Drittanbieter-Risikobewertung nach DORA Art. 28 steht zusätzlich der Vendor-Scan zur Verfügung.
Domain prüfen DORA Drittanbieter-Nachweis →Fragen zu NIS2, DORA und Infrastruktur-Nachweis
Ist das eine offizielle Zertifizierung?
Nein. CERTavia stellt keinen behördlich anerkannten Zertifikat aus. Der SOVP-Nachweis ist ein technisches Beweismittel — kryptografisch signiert, DNS-verankert, direkt durch Auditoren verifizierbar. Mehr dazu im Glossar →
Kann ich einen Vendor scannen, ohne seine Zustimmung einzuholen?
SOVP prüft ausschließlich öffentlich erreichbare Infrastrukturkonfigurationen — DNS, TLS, HTTP-Header. Es werden keine Systeme aktiv angegriffen. Die rechtliche Verantwortung liegt beim Auftraggeber. Wir empfehlen Vendor-Scans im Rahmen vertraglich geregelter Due-Diligence-Prozesse, z. B. als Teil der DORA-Drittanbieter-Risikobewertung nach Art. 28. Mehr zum Vendor-Scan →
Wo sind meine Daten gespeichert? (DSGVO)
SOVP-Scans prüfen ausschließlich öffentlich zugängliche Infrastrukturparameter der angegebenen Domain. Scan-Ergebnisse und der Sovereign Vault werden auf europäischer Infrastruktur gespeichert. Kundendaten werden ausschließlich für die Vertragsabwicklung verarbeitet. Details in der Datenschutzerklärung →
Den Infrastruktur-Status unter allen drei Anforderungsrahmen kennen
Quick Scan – kostenfrei
Der kostenfreie Quick Scan liefert das Layer-0-Ergebnis Ihrer Domain in 90 bis 120 Sekunden. Kein Formular, keine Registrierung.
Domain jetzt scannen – kostenlosEnterprise & individuelle Anforderungen
Für komplexe Anforderungsrahmen oder individuelle Organisationsstrukturen steht das Kontaktformular zur Verfügung.
Kontakt aufnehmenCERTavia analysiert technische Infrastruktursignale. Das Ergebnis ist ein maschinenlesbarer Befund, kein Rechtsgutachten und keine Zertifizierung im Sinne der EU AI Act Konformitätsbewertung nach Artikel 43. Für rechtsverbindliche Compliance-Bewertungen wenden Sie sich an eine zugelassene Konformitätsbewertungsstelle.
Diese Seite dient der technischen Orientierung und stellt keine Rechtsberatung dar. Die Darstellung von NIS2, DORA und EU AI Act gibt den Kenntnisstand zum Zeitpunkt der Veröffentlichung wieder. Regulatorische Anforderungen entwickeln sich weiter. Die Einschätzung konkreter Pflichten im Einzelfall und die Umsetzung eines vollständigen Compliance-Programms obliegen qualifizierten Rechts- und Compliance-Beratern. CERTavia liefert technische Infrastruktur-Validierung auf Basis des Sovereign Validation Protocol (SOVP, Patent Pending Nr. 64/005,737).