Was ist die NIS2-Richtlinie?

Dokumentierte Risikoanalysemethodik und schriftliche Sicherheitsrichtlinien für alle Informationssysteme. Richtlinien müssen auf Vorstands- oder Geschäftsführungsebene genehmigt werden.

Praxisbeispiele

• Eine schriftliche Risikobeurteilung, die mindestens jährlich und nach jeder wesentlichen Infrastrukturänderung aktualisiert wird, mit Risikobewertung nach Wahrscheinlichkeit und Auswirkung.
• Eine vom Vorstand genehmigte Informationssicherheitsrichtlinie, die Klassifizierung, Zugriffskontrolle und Incident Response abdeckt — unterzeichnet vom Geschäftsführer oder gleichwertiger Funktion.
• Ein Asset-Inventar, das jedes System und jeden Datenspeicher mit Eigentümer, Sensitivitätsstufe und angewendeten Kontrollen auflistet.

Formale Reaktionspläne für Sicherheitsvorfälle mit Erkennung, Eindämmung, Beseitigung, Wiederherstellung und Nachbereitung. Klassifizierung der Vorfälle entsprechend der 24-72-1-Meldepflicht.

Praxisbeispiele

• Ein getestetes Incident-Response-Playbook mit zugewiesenen Rollen: Incident Commander, Kommunikationsverantwortlicher, juristischer Ansprechpartner und ein designierter NIS2-Meldeverantwortlicher.
• Eine Schwere-Matrix: P1 (Dienstausfall mit Kundenwirkung) löst die 24-Stunden-NIS2-Frühwarnung aus; P2 (beeinträchtigte Leistung) wird intern protokolliert, aber nicht gemeldet.
• Nachbesprechungen zu Vorfällen, dokumentiert mit Grundursache, Zeitachse und Korrekturmaßnahmen mit namentlich genannten Verantwortlichen und Fälligkeitsterminen.

BCP- und DR-Pläne mit definierten Wiederherstellungszeit- (RTO) und Wiederherstellungspunkt-Zielen (RPO). Regelmäßige Tests der Backup-Systeme sind verpflichtend.

Praxisbeispiele

• Dokumentiertes RTO von 4 Stunden und RPO von 1 Stunde für kritische Systeme, mit monatlich getesteten Offsite-Backups durch tatsächliche Wiederherstellungsverfahren.
• Ein jährlicher vollständiger Failover-Test mit schriftlichen Bestehens-/Nichtbestehens-Kriterien, beobachtet von einem Mitglied der Geschäftsleitung.
• Eine Satzung des Krisenmanagementteams, die festlegt, wer einen Notfall ausruft, wer extern kommuniziert und in welcher Reihenfolge Systeme wiederhergestellt werden.

Bewertung und vertragliche Sicherheitsanforderungen für alle direkten Lieferanten und Dienstleister. Umfasst auch die Software-Lieferkette und Open-Source-Komponenten.

Praxisbeispiele

• Ein Sicherheitsfragebogen oder ISO-27001-Zertifikat, das von allen kritischen Lieferanten vor Vertragsabschluss gefordert wird, mit jährlicher Neubewertung.
• Vertragsklauseln, die Lieferanten verpflichten, Ihr Sicherheitsteam innerhalb von 24 Stunden über Vorfälle mit Auswirkung auf Ihre Daten zu informieren, mit einem jährlichen Prüfungsrecht.
• Automatisches Open-Source-Komponenten-Scanning (z.B. Snyk oder OWASP Dependency-Check) in der CI/CD-Pipeline, das Builds mit kritischen CVEs blockiert.

Sicherheitsanforderungen in Beschaffung, Entwicklung und Wartung von IKT-Systemen integriert. Umfasst auch Schwachstellenbehandlung und Offenlegungsrichtlinien.

Praxisbeispiele

• Jede Ausschreibung für neue IKT-Systeme enthält einen Sicherheitsanhang, der OWASP-Top-10-Abdeckung und einen nicht älter als 12 Monate datierenden Penetrationstest-Bericht verlangt.
• Eine koordinierte Richtlinie zur Offenlegung von Schwachstellen, die auf der Unternehmenswebsite veröffentlicht wird, damit Forscher Befunde ohne rechtliches Risiko melden können.
• Ein Patch-SLA: Kritische CVEs werden innerhalb von 72 Stunden, hohe Schweregrade innerhalb von 7 Tagen und mittlere innerhalb von 30 Tagen behoben — mit Protokollierung und Genehmigung von Ausnahmen.

Dokumentierte Cyber-Hygiene-Praktiken und regelmäßige Sicherheitsbewusstseinstraining für alle Mitarbeiter. Cybersicherheitsschulung auf Vorstands- und Geschäftsführungsebene ist ebenfalls erforderlich.

Praxisbeispiele

• Jährliche Phishing-Simulation mit mindestens 90 % Mitarbeiterbeteiligung; Mitarbeiter, die klicken, erhalten innerhalb von 5 Werktagen ein verpflichtendes Nachschulungstraining.
• Eine dokumentierte Passwort- und Anmeldedaten-Richtlinie: Mindestens 12-stellige Passwörter, keine geteilten Konten, Passwort-Manager für alle Mitarbeiter bereitgestellt.
• Ein Cybersicherheits-Briefing auf Vorstands- und Geschäftsführungsebene, das mindestens einmal jährlich abgehalten wird und die aktuelle Bedrohungslage sowie die NIS2-Compliance des Unternehmens behandelt.

Richtlinien für den Einsatz von Kryptografie und, wo angemessen, Verschlüsselung von Daten bei Übertragung und Speicherung. Schlüsselverwaltungsprozesse müssen dokumentiert werden.

Praxisbeispiele

• TLS 1.2 oder höher wird auf allen nach außen gerichteten Diensten erzwungen; TLS 1.0 und 1.1 sind auf allen Endpunkten deaktiviert — überprüft durch vierteljährliche automatisierte Scans.
• Datenbanken und Dateiablagen mit persönlichen oder sensiblen Daten werden im Ruhezustand mit AES-256 oder gleichwertigem Verfahren verschlüsselt.
• Ein Schlüsselverwaltungsverfahren, das Erzeugung, Speicherung (HSM oder gleichwertig), Rotationshäufigkeit (mindestens jährlich) und Widerrufschritte abdeckt.

Hintergrundprüfungen wo zulässig, Sicherheitsverpflichtungen in Arbeitsverträgen und eine formale Zugangskontrollrichtlinie auf Basis des Prinzips der geringsten Rechte.

Praxisbeispiele

• Ein Einstellungs-/Versetzungs-/Austritts-Prozess: Systemzugang wird innerhalb von 1 Werktag nach Beginn bereitgestellt und innerhalb von 4 Stunden nach Austrittsmitteilung entzogen.
• Rollenbasierte Zugriffskontrolle (RBAC) mit vierteljährlichen Überprüfungen aller privilegierten Konten; jedes Konto, das 90 Tage inaktiv ist, wird automatisch deaktiviert.
• Sicherheitsverpflichtungen in Arbeitsverträgen und eine unterzeichnete Nutzungsvereinbarung, die vor dem ersten Systemzugang erforderlich ist.

MFA oder kontinuierliche Authentifizierungslösungen müssen für alle privilegierten Zugriffe und alle Fernzugriffe auf Netz- und Informationssysteme verwendet werden.

Praxisbeispiele

• MFA wird auf allen VPN-, RDP- und Cloud-Administrationsportalen (Azure AD, AWS IAM, Google Workspace) ohne Ausnahme erzwungen, auch für Dienstkonten.
• Hardware-Token oder Authentifizierungs-Apps sind für privilegierte Konten erforderlich; SMS-only-MFA wird für Administrator- oder Root-Zugang nicht akzeptiert.
• Richtlinien für bedingten Zugriff, die Anmeldungen von nicht verwalteten oder nicht konformen Geräteprofilen blockieren, mit Benachrichtigungen an das SOC für jeden blockierten Versuch.

Verschlüsselte und authentifizierte Kommunikation für Sprache, Video und Text. Notfallkommunikationssysteme mit angemessenen Sicherheitskontrollen.

Praxisbeispiele

• Ein Ende-zu-Ende-verschlüsselter Nachrichtenkanal (getrennt von normaler E-Mail), der für die Incident-Response-Kommunikation designiert und vierteljährlich getestet wird.
• Ein Out-of-Band-Krisenkommunikationssystem, das unabhängig von der primären IT-Infrastruktur betrieben wird — damit es auch bei Ausfall des Hauptnetzwerks verfügbar bleibt.
• E-Mail-Gateway mit DMARC, DKIM und SPF-Einträgen im Erzwingungsmodus konfiguriert, plus Anhang-Sandbox für eingehende Dateien.