Regulierung nennt Ergebnisse, keine Produkte. Wer von einer Einkaufsliste an Werkzeugen aus plant, riskiert, das Mandat zu verfehlen. Wir gehen den umgekehrten Weg: Wir nehmen jede Anforderung von NIS2 und DORA und bilden sie auf die Design-Eigenschaft ab, die sie erfüllt. Folgt man dieser Kette Mandat → Prinzip, ist die Architektur durch Konstruktion konform — und jede regelkonforme Technologie kann sie erfüllen.
Dieses Framework nennt bewusst keine Technologie. Es bleibt auf der Ebene: was das Gesetz fordert und welche Design-Eigenschaft das beantwortet. Die konkreten Werkzeuge werden pro Produkt an anderer Stelle zugeordnet; dies ist das vorgelagerte Artefakt, das jedes Lösungsdesign und jede Audit-Gap-Analyse steuert.
Sind Sie betroffen, was NIS2 konkret verlangt, und wie Sie es mit selbst gehosteter Open-Source erfüllen — mit 90-Tage-Startplan. Nur Ihre geschäftliche E-Mail.
Trust-Zonen auf L2/L3 getrennt, Default-Deny zwischen Zonen, Begrenzung des Schadensradius.
Zugriff nach Rolle/Bedarf; Management-Ebene von Nutzer- und Datenebene isoliert.
Multi-Faktor- / phishing-resistente Authentifizierung für privilegierten und Fernzugriff.
Verschlüsselte Verbindungen und Daten; verwaltete Schlüssel/Zertifikate; keine Klartext-Steuerkanäle.
Kritische Pfade dupliziert; kontrollierte Degradation; definierte RTO/RPO.
Unveränderliche, ausgelagerte Kopien; Wiederherstellung durch Test bewiesen, nicht angenommen.
Zentrale, zeitlich korrelierte Logs; Alarmschwellen; überwachter Ein-/Ausgangsverkehr.
Geprüfte, versionierte, umkehrbare Änderungen; reproduzierbarer Zustand.
Kontinuierliche Erkennung; geplante, belegte Behebung; koordinierte Offenlegung.
Verbindliches Verzeichnis von Assets, Adressen und Abhängigkeiten.
Geprüfte Lieferanten/Software; Herkunftsnachweis und Update-Integrität.
Regelmäßige Failover-/DR-Tests und — sofern anwendbar — bedrohungsgeführte Penetrationstests.
Erkennen → klassifizieren → reagieren → melden innerhalb regulatorischer Fristen; Nachweise aufbewahrt.
Sicherheit eingebaut in Beschaffung, Entwicklung, Wartung und Außerbetriebnahme.
Grund-Hygiene, RBAC-Disziplin, Awareness/Schulung als Design-Annahme.
Die Risikomanagement-Maßnahmen nach Art. 21(2) müssen mindestens Folgendes umfassen. Art. 23 regelt die Vorfallmeldung.
| NIS2-Vorgabe | Anforderung (gekürzt) | Prinzipien |
|---|---|---|
| 21(2)(a) | Konzepte für Risikoanalyse & Sicherheit der Informationssysteme | DP-10, DP-8, DP-14 |
| 21(2)(b) | Bewältigung von Sicherheitsvorfällen | DP-7, DP-13 |
| 21(2)(c) | Aufrechterhaltung des Betriebs — Backup, Notfallwiederherstellung, Krisenmanagement | DP-5, DP-6, DP-12 |
| 21(2)(d) | Sicherheit der Lieferkette (direkte Anbieter/Dienstleister) | DP-11 |
| 21(2)(e) | Sicherheit bei Beschaffung, Entwicklung & Wartung; Schwachstellenbehandlung & -offenlegung | DP-9, DP-14 |
| 21(2)(f) | Bewertung der Wirksamkeit der Risikomanagement-Maßnahmen | DP-12, DP-8 |
| 21(2)(g) | Grundlegende Cyber-Hygiene & Schulungen | DP-15 |
| 21(2)(h) | Kryptografie und, sofern angemessen, Verschlüsselung | DP-4 |
| 21(2)(i) | Personalsicherheit, Zugriffskontrolle, Asset-Management | DP-2, DP-10, DP-15 |
| 21(2)(j) | MFA / kontinuierliche Authentifizierung, gesicherte Kommunikation | DP-3, DP-4 |
| Art. 23 | Meldung an CSIRT (Frühwarnung ≤24 h / Meldung ≤72 h) | DP-13, DP-7 |
| DORA-Vorgabe | Anforderung (gekürzt) | Prinzipien |
|---|---|---|
| Art. 8 — Identifizierung | IKT-Assets, Funktionen & Abhängigkeiten identifizieren | DP-10 |
| Art. 9 — Schutz & Prävention | Segregation, Zugriffskontrolle, Verschlüsselung, resilientes Design | DP-1, DP-2, DP-3, DP-4 |
| Art. 10 — Erkennung | Mehrschichtige Erkennung; Alarmschwellen | DP-7 |
| Art. 11 — Reaktion & Wiederherstellung | IKT-Kontinuität; auf Zielwerte reagieren & wiederherstellen | DP-5, DP-13 |
| Art. 12 — Backup & Wiederherstellung | Backup-Richtlinien; Wiederherstellungsmethoden; getrennte Kopien | DP-6 |
| Art. 13 — Lernen & Weiterentwickeln | Lernen aus Vorfällen; kontinuierliche Verbesserung | DP-12, DP-8 |
| Art. 17–23 — Vorfallmanagement (Kap. III) | Schwerwiegende IKT-Vorfälle klassifizieren & melden | DP-13, DP-7 |
| Art. 24–27 — Resilienztests (Kap. IV) | Testprogramm; bedrohungsgeführte Penetrationstests (TLPT) | DP-12 |
| Art. 28–44 — Drittparteienrisiko (Kap. V) | Vertrags-, Konzentrations- & Aufsichtskontrollen über Anbieter | DP-11 |
Jedes High- und Low-Level-Design wird gegen DP-1…DP-15 geprüft. Ein Design, das ein Prinzip nicht nachweisen kann, hält ein Restrisiko fest — nichts wird durchgewunken.
Jedes Prinzip wird pro Produkt in konkrete Controls und Nachweise übersetzt — die Technologieebene, die dieses Framework bewusst auslässt.
Die Gap-Analyse bewertet Ihren Ist-Zustand gegen dieselben Prinzipien, sodass jeder Befund direkt auf eine regulatorische Vorgabe zurückführt.
Abnahme- und Sandbox-Tests weisen die Prinzipien für Redundanz, Backup, Erkennung und Resilienz (DP-5/6/7/12) mit Nachweisen nach — bewiesen, nicht angenommen.
Quellen (maßgeblich). NIS2 = Richtlinie (EU) 2022/2555, insb. Art. 21(2)(a)–(j) und Art. 23 — EUR-Lex 32022L2555. DORA = Verordnung (EU) 2022/2554, insb. Kap. II Art. 8–13, Kap. III Art. 17–23, Kap. IV Art. 24–27, Kap. V Art. 28–44 — EUR-Lex 32022R2554.
Copyright © XpertOne Security Consulting GmbH. Alle Rechte vorbehalten. | Impressum | Datenschutz