Der erste NIS2-Artikel skizzierte die Pflichten grob. Die häufigste Anschlussfrage lautet: Wie baue ich jetzt ein ISMS, das die Richtlinie wirklich trägt? Hier die wichtigsten Bausteine.

1. Framework wählen (aber schlank halten)

  • ISO 27001 / 27002 als Basis reicht völlig; keine Sondernorm nötig.
  • Für Unternehmen ohne Zertifizierungsdruck genügt ein „ISO-light“ mit klarer Mapping-Tabelle zu NIS2-Artikeln.
  • Wichtig: Controls priorisieren. Nicht alles sofort, sondern risikobasiert.

2. Scope & Kritikalität

  • Scope-Dokument: Welche Standorte, Systeme, Dienste? Abgrenzung schreiben.
  • Asset-Klassifizierung: Geschäftsprozesse → Dienste → Assets. Kritikalität (hoch/mittel/niedrig) + Owner.
  • Verknüpfung zu NIS2-Meldepflichten: Kritische Dienste identifizieren, damit Playbooks greifen.

3. Policies & Prozesse (Minimum Viable ISMS)

Dokument Zweck
Sicherheitsleitlinie Management-Commitment, Rollen, Ziele
Risikomanagement-Prozess Methode, Schwellenwerte, Review-Zyklen
Incident-Playbook 24h/72h/1-Monats-Reports, Kommunikationsmatrix
Lieferkettenguide Security-Anforderungen, Assessments, Eskalation
Awareness-Plan Schulungstypen, Frequenz, Nachweisdokumentation

Alles Versionieren (Git/SharePoint) und mit Verantwortlichen versehen.

4. Risikomanagement praktikabel machen

  • Risiko-Katalog (Top-15 Szenarien) statt 200 Einzelrisiken.
  • Bewertung: Eintrittswahrscheinlichkeit x Auswirkung; Ampelfarben reichen.
  • Behandlung: Akzeptieren, Reduzieren, Transfer, Avoid. Maßnahmenplan mit Termin.
  • Review: Quartalsweise, plus bei Veränderungen (M&A, neue Cloud-Services, Vorfälle).

5. Controls technisch verankern

  • Identifizieren: Asset-Inventar, Vulnerability Management, Security Logging.
  • Schützen: MFA, Hardening, NetSeg, Patch-Policy, Backup-Testplan.
  • Erkennen: SIEM/SOC Use-Cases, Anomalie-Erkennung, KPIs (MTTD).
  • Reagieren: Incident-Response-Runbook, Lessons Learned, Ticket-System.
  • Wiederherstellen: DR-Tests, Kommunikationsplan, Stakeholder-Template.

Alles sauber dokumentieren (Diagramm + Text + Verantwortlicher).

6. Kennzahlen & Reporting

  • MTTD / MTTR pro Incident-Kategorie.
  • Patch-Compliance (% kritischer Systeme < 14 Tage).
  • Awareness-Quote (geschulte Mitarbeitende pro Quartal).
  • Lieferantenstatus (bewertete Supplier vs. Gesamtanzahl).
  • Audit-Feststellungen (offen/geschlossen).

Diese KPIs monatlich aufbereiten, quartalsweise ans Management.

7. Integration in den Betrieb

  • Change-Management koppeln: Jede Änderung braucht Sicherheitsimpact.
  • Produktentwicklung: Secure SDLC / DevSecOps-Checkliste.
  • HR-Prozesse: On-/Offboarding mit Rechteprüfung.
  • Facility & OT: Zutritt, Video, physische Redundanzen.

8. Tooling

Bereich Tool-Ideen
Doku & Workflows Confluence/Notion + Jira/ServiceNow
Risikoregister Excel + Power BI oder spezialisierte GRC-Tools
ISMS-Automation Drata, Vanta, Alyne (für mittelgroße Unternehmen)
Monitoring Splunk, Elastic, Microsoft Sentinel, Wazuh

9. Roadmap (12 Monate)

  1. Monat 1–2: Scope, Governance, Policy-Rumpf
  2. Monat 3–4: Asset-/Risikoregister, Quick-Wins (MFA, Backup-Test)
  3. Monat 5–6: Incident-Playbook + Tabletop, Lieferantenguideline
  4. Monat 7–9: Monitoring/SOC-Use-Cases, Awareness-Programm
  5. Monat 10–12: Internes Audit, Management-Review, Feintuning

Fazit: Ein ISMS für NIS2 muss nicht bürokratisch sein. Entscheidend ist, dass Prozesse dokumentiert, Verantwortliche benannt und Maßnahmen nachverfolgbar sind. Mit diesem Fokus wird das System prüffähig – ohne das Tagesgeschäft zu lähmen.