NIS2, DORA und EU AI Act: Wo sich die Anforderungen technisch überschneiden.
Unternehmen in regulierten Branchen arbeiten selten unter einem einzigen Anforderungsrahmen. Die gemeinsame Schnittmenge von NIS2, DORA und EU AI Act ist die Cybersicherheit: NIS2 Art. 21, das IKT-Risikomanagement nach DORA und Art. 15 EU AI Act für Hochrisiko-Systeme. Die Transparenzpflichten aus Art. 50 gehören nicht dazu. 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. Anhang I listet Sektoren mit hoher Kritikalität: Energie, Verkehr, Bankwesen, Finanzmarktinfrastruktur, Gesundheit, Trinkwasser, Abwasser, digitale Infrastruktur, IKT-Dienstleistungsmanagement (B2B), öffentliche Verwaltung und Weltraum. Anhang II listet sonstige kritische Sektoren: Post- und Kurierdienste, Abfallwirtschaft, Chemie, Lebensmittel, verarbeitendes Gewerbe, digitale Anbieter und Forschung. Ob eine Einrichtung wesentlich oder wichtig ist, hängt von Sektor und Größe ab: Große Unternehmen in Anhang-I-Sektoren sind in der Regel wesentlich, mittlere und Anhang-II-Unternehmen wichtig.
Die Klassifikation richtet sich nach Unternehmensgröße und Sektor. Erfasst sind grundsätzlich mittlere und große Unternehmen in diesen Sektoren, also ab 50 Beschäftigten oder ab mehr als 10 Millionen Euro Jahresumsatz und Jahresbilanzsumme; für einige Einrichtungen (z. B. DNS-Diensteanbieter, TLD-Registries) gilt NIS2 unabhängig von der Größe.
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 BSIG in der Fassung des 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 — über die Aufsicht nach Art. 31 ff. — als kritisch eingestufte IKT-Drittdienstleister.
Für Technologieunternehmen relevant: Wer Software oder Infrastruktur an Finanzunternehmen liefert, ist meist nicht selbst DORA-pflichtig, wird aber über die Vertragsanforderungen nach Art. 30 DORA und die Drittanbieter-Risikobewertung der Kunden (Art. 28) mittelbar erfasst.
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 sich NIS2, DORA und EU AI Act tatsächlich überschneiden
Die drei Rahmenwerke entstammen unterschiedlichen regulatorischen Kontexten. Überschneidungen gibt es bei Cybersicherheit, Lieferkette und Dokumentation — beim EU AI Act fast ausschließlich über die Hochrisiko-Anforderungen, die ab dem 2. Dezember 2027 gelten.
Kryptografische Integrität
NIS2 verlangt Konzepte für Kryptografie und Verschlüsselung. DORA verlangt Schutz- und Präventionsmaßnahmen für IKT-Systeme. Der EU AI Act verlangt Cybersicherheit nur für Hochrisiko-Systeme (Art. 15). TLS-Konfiguration, DNSSEC und HTTP-Sicherheitsheader sind dafür extern prüfbare Teilaspekte. Art. 50 verlangt keine davon.
Lieferkette und Zulieferer
NIS2 verlangt Sicherheit in der Lieferkette, DORA ein Management des IKT-Drittparteienrisikos. Der EU AI Act verpflichtet Zulieferer von Hochrisiko-Komponenten, dem Anbieter Informationen bereitzustellen (Art. 25 Abs. 4), und verlangt Daten-Governance für Trainingsdaten (Art. 10). Eine Pflicht zur Offenlegung von Datenquellen nach Art. 50 gibt es nicht.
Dokumentationspflicht
Alle drei Rahmenwerke verlangen Dokumentation, aber jeweils eigene: Risikomanagement-Konzepte (NIS2), IKT-Risikomanagement-Rahmen und Informationsregister (DORA), technische Dokumentation nach Anhang IV (EU AI Act). Ein signierter Scan-Report kann in jede davon als Anlage zur extern sichtbaren Infrastruktur eingehen, keine davon ersetzen.
Kontinuierliche Überwachung
NIS2 und DORA verlangen kontinuierliche Überwachung und Meldungen bei erheblichen Vorfällen; der EU AI Act verlangt für Hochrisiko-Systeme Post-Market-Monitoring (Art. 72). Quartalsweise Re-Scans zeigen, ob sich die extern sichtbare Konfiguration verändert hat, etwa nach einem Zertifikatswechsel.
Was der CERTavia-Scan von außen prüft
Die folgenden Parameter sind öffentlich sichtbar und deshalb ohne Zugang zum System prüfbar. Sie decken einen kleinen, aber leicht verifizierbaren Ausschnitt dessen ab, was NIS2- oder DORA-Prüfungen betrachten.
DNS und kryptografische Grundkonfiguration
DNSSEC-Konfiguration, CAA-Records, TLS-Konfiguration und Zertifikats-Transparenz (Cluster A). Eigene Beobachtung: Bei 38 Scans von certavia.org zwischen dem 06.08. und 12.10.2026 schwankte Cluster A zwischen 95 und 100, teils von Tag zu Tag. Die Prüfregeln sind fest, die Messwerte externer Prüfungen wie der TLS-Bewertung nicht; ein Scan dokumentiert einen datierten Zustand.
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
Der Scan prüft, ob robots.txt eigene Regelgruppen für KI-Bots enthält und ob ein Opt-out-Hinweis vorhanden ist. Widersprüche zwischen robots.txt und anderen Deklarationen erkennt er nicht. Rechtlich betrifft das vor allem den Text-and-Data-Mining-Vorbehalt im Urheberrecht, weder NIS2 noch DORA noch Art. 50 direkt.
Maschinenlesbare Governance-Deklaration
AI Policy URL, Datenschutz-KI-Abschnitt, Deepfake-Disclaimer und benannte Kontaktstelle für KI-Anfragen (Cluster F) sind freiwillige öffentliche Deklarationen. Sie können die Art.-50-Dokumentation stützen, sind aber selbst keine Art.-50-Pflicht und für NIS2 und DORA ohne direkten Bezug.
Lieferketten-Integrität
NIS2 und DORA stellen explizit Anforderungen an die Integrität der Lieferkette. Ein externer Scan kann die öffentlich sichtbare Konfiguration eines Lieferanten dokumentieren (Vendor-Scan). Vertragliche Prüfrechte, Fragebögen und das DORA-Informationsregister ersetzt er nicht.
Welche Branchen unter allen drei Rahmenwerken stehen
Finanzsektor
Banken, Versicherungen und Finanzdienstleister unterliegen DORA; für sie geht DORA den NIS2-Risikomanagement- und Meldepflichten als Spezialregelung vor. KI-Systeme zur Kreditwürdigkeitsprüfung und zur Risikobewertung in Lebens- und Krankenversicherung fallen zusätzlich unter Annex III Nr. 5. Benchmark-Befund: Die BaFin-Liste (50 Domains, Messung 11.06.2026) lag bei Ø-CES 30,1, Höchstwert 47,8; bei 90 % der Domains lag Cluster F bei 0.
Healthcare
Krankenhäuser und Gesundheitseinrichtungen fallen unter NIS2 (Anhang I). Diagnose-KI ist meist ein Medizinprodukt und damit über Annex I Hochrisiko (ab 2. August 2028); die Triage von Notfallpatienten fällt unter Annex III Nr. 5. Benchmark-Befund: Die Health-Liste (Juni-Messung, teilweise vom Messfehler in Cluster A betroffen; Werte eher zu niedrig) enthält mit 55,1 den höchsten gemessenen Einzelwert — CERTIFIED erreichte keine Domain (Korrekturhinweis).
Kritische Infrastruktur
Betreiber in den Bereichen Energie, Wasser und Verkehr sind wesentliche Einrichtungen unter NIS2. KI-Systeme als Sicherheitsbauteile in der Steuerung dieser Infrastruktur fallen unter Annex III Nr. 2. Die Werte der KRITIS-Liste im CERTavia-Benchmark sind wegen eines Messfehlers zurückgezogen (Korrekturhinweis). In allen zehn Branchenlisten des CERTavia-Benchmarks liegt Cluster F (AI Governance) im Median bei 0; zwischen 52 % (ECOM100-DE) und 90 % (BaFin50) der Domains zeigen kein einziges AI-Governance-Signal (Juni-Messungen; dieser Befund ist vom Messfehler in Cluster A nicht betroffen, siehe Korrekturhinweis).
IKT-Drittdienstleister
Software- und Infrastrukturdienstleister, die Finanzunternehmen beliefern, werden über Verträge und Drittanbieter-Risikobewertungen ihrer Kunden von DORA erfasst. Gehören sie selbst zu einem NIS2-Sektor, etwa IKT-Dienstleistungsmanagement, gilt NIS2 direkt.
Was CERTavia dazu liefert
CERTavia erzeugt maschinell verifizierbare Layer-0-Evidenz der öffentlichen Infrastruktur einer Domain. Cluster A–E (DNS, TLS, Header, Maschinenlesbarkeit, Consent, Agent-Schnittstellen) liefern Input für NIS2 (Lieferkette, § 30 BSIG) und DORA (Drittparteienrisiko, Art. 28); Cluster F dokumentiert KI-Governance-Deklarationen mit Bezug zur Art.-50-Dokumentation.
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.
Den Sovereign Vault Link können Sie an externe Auditoren, Auftraggeber oder Behörden weitergeben. 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.
Externe Infrastruktur-Evidenz für NIS2, DORA und den EU AI Act
CERTavia liefert maschinell verifizierbare Layer-0-Evidenz der öffentlich sichtbaren Infrastruktur. 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 kein behördlich anerkanntes Zertifikat aus. Der SOVP-Nachweis ist ein technischer Beleg über die öffentlich sichtbare Infrastruktur einer Domain — signiert und durch Auditoren unabhängig 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 im Median nach rund 10 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).