Was NIS2 & DORA technisch von Ihrer Website verlangen, und für wen sie gelten

Digitale Illustration eines Schutzschild-Symbols über einem stilisierten Server-Rack, cyanfarbene Verbindungslinien auf schwarzem Hintergrund.
Symbolbild, KI-generiert

Verfasst von

in

Stand der Korrektur 06.11.2026: Wen DORA erfasst, die Größenschwelle nach § 28 BSIG und die KRITIS-Schwellenwerte sind richtiggestellt; ergänzt sind die Zusatzpflichten für Betreiber kritischer Anlagen, präzisiert ist die Haftung der Geschäftsleitung.

Für Geschäftsführer: Was bedeutet das für mein Risiko und meine Kosten

Seit dem 6. Dezember 2025 gilt in Deutschland das NIS2-Umsetzungsgesetz (BSIG-2025). Es verpflichtet tausende Unternehmen, ihre IT-Sicherheit auf ein nachweisbares Mindestniveau zu heben, darunter auch Anforderungen, die sich direkt an der eigenen Webseite und am eigenen Mailserver ablesen lassen. Parallel gilt seit Januar 2025 die europäische DORA-Verordnung für nahezu den gesamten Finanzsektor, mit ähnlichen technischen Kernpflichten.

Die gute Nachricht zuerst: Ein Großteil dessen, was NIS2 §30 BSIG technisch fordert, lässt sich mit einem einzigen automatisierten Scan prüfen, TLS-Verschlüsselung, Zertifikate, Sicherheits-Header, Mail-Absicherung und bekannte Schwachstellen. Diese Prüfpunkte sind zugleich der technische Kern von DORA (Artikel 9 der Verordnung) und der KRITIS-Anforderungen des BSI. Wer hier sauber aufgestellt ist, bedient drei Rahmenwerke gleichzeitig, unabhängig davon, ob er formal darunterfällt.

Die schlechte Nachricht: Ob Sie überhaupt unter NIS2, DORA oder KRITIS fallen, ist keine rein technische Frage. Es hängt von Ihrer Branche, Ihrer Unternehmensgröße (vereinfacht: mindestens 50 Mitarbeitende, oder mehr als 10 Millionen Euro Umsatz zusammen mit mehr als 10 Millionen Euro Bilanzsumme; Zahlen verbundener Unternehmen und anteilig die von Partnerunternehmen zählen grundsätzlich mit, die genaue Schwelle ist im Einzelfall zu prüfen) und, im Fall von KRITIS, von den Schwellenwerten ab, die derzeit die BSI-Kritisverordnung je Anlagenart festlegt. Sie leiten sich meist aus einem Regelwert von 500.000 versorgten Personen ab und sind deshalb je Anlage verschieden, bei einem Krankenhaus etwa 30.000 vollstationäre Fälle im Jahr, bei einem Rechenzentrum 3,5 Megawatt vertraglich vereinbarte Leistung. Diese Einordnung kann und will ein technischer Scan nicht abschließend leisten, das wäre Rechtsberatung. Was er leisten kann: Ihnen zeigen, wo Ihre Technik heute steht, und Ihnen einen begründeten Hinweis geben, ob eine nähere Prüfung Ihrer Betroffenheit sinnvoll ist.

Warum das für Sie als Geschäftsführung relevant ist: Bei NIS2-pflichtigen Unternehmen muss die Geschäftsleitung die Risikomanagement-Maßnahmen umsetzen und ihre Umsetzung überwachen; verletzt sie diese Pflicht schuldhaft, haftet sie ihrem Unternehmen persönlich für den Schaden, nach den Regeln des Gesellschaftsrechts (§ 30 i. V. m. § 38 Abs. 1 und 2 BSIG). Verstöße gegen Melde- und Nachweispflichten können mit empfindlichen Bußgeldern geahndet werden. Und selbst wenn Sie formal nicht betroffen sind, gelten die gleichen technischen Mindeststandards vielerorts längst als „Stand der Technik“, ein Kriterium, das auch außerhalb von NIS2 in Haftungsfragen herangezogen wird (etwa bei der DSGVO oder im Wettbewerbsrecht).

Kurz gesagt: Ein technischer Website- und Mail-Scan ist keine Formalität, sondern der schnellste Weg, den eigenen Status zu kennen, bevor eine Aufsichtsbehörde oder ein Vorfall ihn für Sie klärt.


Für Techniker: Was konkret geprüft wird und wie Sie es selbst nachvollziehen

NIS2 (Richtlinie (EU) 2022/2555, national umgesetzt im BSIG-2025) verlangt in §30 Absatz 2 zehn Kategorien von Risikomanagement-Maßnahmen. Nur ein Teil davon ist an einer Webseite technisch messbar, der Rest betrifft Prozesse (Schulungen, Backup-Konzepte, Krisenmanagement), die sich nicht scannen lassen. Konkret prüfbar sind vor allem:

Transportverschlüsselung (§30 Abs. 2 Nr. 8, BSI TR-03116-4):

  • Nur TLS 1.2 und 1.3 aktiv, ältere Protokollversionen (SSLv3, TLS 1.0/1.1) deaktiviert (RFC 8996)
  • Ausschließlich Perfect-Forward-Secrecy-Cipher (ECDHE) mit AEAD-Verschlüsselung (AES-GCM)
  • Schlüssellängen ab 3072 Bit bei RSA/DH, moderne elliptische Kurven
  • Gültiges Zertifikat einer vertrauenswürdigen Zertifizierungsstelle, keine abgelaufenen oder fehlerhaften Ketten
  • TLS-Kompression deaktiviert (Schutz gegen CRIME-Angriffe), Client-Renegotiation aus, OCSP-Stapling aktiv

Sicherheits-Header (OWASP-Empfehlung, IT-Grundschutz-Baustein APP.3.1, nicht Teil von TR-03116-4):

  • HSTS mit ausreichender max-age und includeSubDomains
  • Restriktive Content-Security-Policy
  • X-Content-Type-Options: nosniff, Referrer-Policy, Klickjacking-Schutz
  • Cookie-Attribute Secure, HttpOnly, SameSite
  • Erzwungene HTTPS-Weiterleitung ohne Mixed Content

Mail-Sicherheit (§30 Abs. 2 Nr. 8, BSI TR-03108):

  • SPF-Record mit striktem Fail-Mechanismus
  • DKIM mit mindestens 2048 Bit Schlüssellänge
  • DMARC mit p=quarantine oder p=reject und Reporting-Adresse
  • DNSSEC-signierte Zone plus DANE/TLSA-Records für den Mailserver
  • MTA-STS im Enforce-Modus und TLS-RPT-Reporting

Ergänzend gehört zur gesicherten Kommunikation nach §30 Abs. 2 Nr. 10 BSIG auch die Multi-Faktor-Authentifizierung (MFA) für Admin- und Login-Zugänge. Sie lässt sich nicht direkt am TLS- oder Mail-Scan ablesen, ist aber ein zentraler Baustein der geforderten Login-Härtung.

Meldekanal für Schwachstellen (§30 Abs. 2 Nr. 2/5):

  • /.well-known/security.txt nach RFC 9116, mit gültigem Contact-Feld und Expires-Datum unter einem Jahr, ausgeliefert über HTTPS

Lieferketten- und Patchstand-Indikatoren (§30 Abs. 2 Nr. 4/5):

  • Eingebundene Drittanbieter-Skripte, CDNs und Tag-Manager sichtbar machen
  • Erkennbare veraltete Server- oder CMS-Versionen und öffentlich bekannte Schwachstellen (CVEs)

DORA (Verordnung (EU) 2022/2554, seit 17. Januar 2025 anwendbar) richtet sich vor allem an Finanzunternehmen im Sinne von Artikel 2 Abs. 2 (Banken, Versicherungen, Zahlungs- und E-Geld-Institute, Wertpapierfirmen, Krypto-Dienstleister und weitere). Daneben nennt Artikel 2 Abs. 1 Buchst. u auch IKT-Drittdienstleister, also Unternehmen, die IKT-Dienstleistungen bereitstellen. Sie erreicht DORA vor allem über die Verträge mit ihren Finanzkunden (Artikel 30) und unmittelbar unter Aufsicht erst, wenn sie als kritisch eingestuft werden (Artikel 31). Für Finanzunternehmen ist DORA lex specialis, sie geht der NIS2-Anwendung vor. Der weit überwiegende Teil von DORA ist organisatorisch (Governance, Asset-Inventar, Incident-Reporting, bedrohungsgeleitete Pentests). Der technisch scanbare Kern deckt sich jedoch weitgehend mit dem NIS2-Katalog: Transportverschlüsselung nach Artikel 9 DORA in Verbindung mit den technischen Regulierungsstandards (RTS, Delegierte Verordnung (EU) 2024/1774, Artikel 6 und 14).

KRITIS (BSI-KritisV, Schwellenwerte je Anlagenart) ist die höchste Stufe: Jeder Betreiber einer kritischen Anlage gilt automatisch als „besonders wichtige Einrichtung“ (§ 28 Abs. 1 Nr. 1 BSIG). Die technische Baseline von oben gilt auch hier. Für die IT, die für die kritische Anlage maßgeblich ist, gilt aber ein strengerer Maßstab: Auch Maßnahmen über das Schutzniveau besonders wichtiger Einrichtungen hinaus gelten dort als verhältnismäßig, und Systeme zur Angriffserkennung sind Pflicht (§ 31 BSIG; Sonderregeln gelten unter anderem für Energie, Telekommunikation und den Finanzsektor).

Wichtig für die korrekte Einordnung: HSTS und Content-Security-Policy werden häufig fälschlich der BSI-Richtlinie TR-03116-4 zugeschrieben. Tatsächlich behandelt TR-03116-4 ausschließlich den TLS-Handshake selbst (Protokollversion, Cipher, Schlüssel, Zertifikat). Sicherheits-Header sind OWASP-Best-Practice und Teil des IT-Grundschutz-Bausteins APP.3.1. Diese Unterscheidung ist keine Spitzfindigkeit, sie entscheidet, welchen Prüfpunkt Sie in einem Audit-Bericht welchem Rahmenwerk zuordnen dürfen.

Was ein Scan nicht leisten kann: Ob Sie überhaupt NIS2-, DORA- oder KRITIS-pflichtig sind, folgt aus Sektor- und Größenkriterien, die sich nicht zuverlässig aus einer Webseite ablesen lassen. Ein seriöses Audit-Tool sollte diese Einordnung daher immer als Hinweis beziehungsweise Annahme kennzeichnen, nicht als abschließendes Verdikt, und bei fehlender Betroffenheit ausdrücklich sagen, dass die geprüften Punkte technisch trotzdem als Stand der Technik empfohlen bleiben.

Dieser Beitrag ist eine an die Allgemeinheit gerichtete Darstellung von Rechtsfragen und keine Rechtsdienstleistung (§ 2 Abs. 1 und Abs. 3 Nr. 5 RDG). Er prüft keinen Einzelfall und ersetzt keine anwaltliche Beratung. Maßgeblich ist allein der Gesetzestext in seiner geltenden Fassung; Stand: 15.07.2026, korrigiert am 06.11.2026.

WhatsApp