Vom Lückenbericht zum Projektplan: Verantwortliche, Nachweise und Zeitpläne

Die Lückenanalyse durchzuführen ist der einfache Teil. Unser Schritt-für-Schritt-Leitfaden führt Sie zu einem Tracker, in dem jede unerfüllte Anforderung aufgelistet ist. Was danach passiert, entscheidet, ob das Programm gelingt: Zu viele Tracker bleiben lange Tabellen mit Zeilen, die als "nicht erfüllt" markiert sind und niemandem gehören.

Schritt 1: Zeilen zu Workstreams gruppieren

Anforderungen sind nach der Logik des Frameworks nummeriert, nicht nach Ihrer. Gruppieren Sie die unerfüllten Zeilen neu danach, was sie beheben wird:

• Governance und Richtlinien (Geltungsbereich, Rollen, Richtlinien, Freigabe durch das Management)
• Identität und Zugriff
• Schwachstellen- und Patch-Management
• Protokollierung und Monitoring
• Incident Response und Meldung
• Lieferantenmanagement
• Business Continuity und Backup
• Sichere Entwicklung
• Physische Sicherheit

Ein Workstream schließt oft zehn oder zwanzig Zeilen. Sicherheitsanforderungen an Lieferanten in Verträge aufzunehmen kann beispielsweise Anforderungen aus ISO 27001, PCI DSS, DSGVO (GDPR) und NIS2 zugleich erfüllen.

Schritt 2: nach Abhängigkeit und Risiko sortieren

1. Blocker zuerst: Geltungsbereich, Governance, Richtlinien und Risikobewertung. Technische Arbeit ohne sie muss wiederholt werden.
2. Danach hohe Risiken: exponierte Systeme ohne MFA, ungepatchte, aus dem Internet erreichbare Dienste, ungetestete Backups.
3. Dann der Rest, wobei Dokumentation und Nachweissammlung parallel laufen, nicht erst am Ende.

Schritt 3: ehrlich schätzen

Schätzen Sie für jeden Workstream: die Arbeit, wer sie erledigt, wie lange sie dauert und was sie kostet (Personal, Tools, externe Unterstützung). Versteckte Kosten fallen meist im laufenden Betrieb der Kontrolle an (ein Quartalsreview bedeutet vier Termine pro Jahr, dauerhaft), nicht beim Aufbau.

Schritt 4: Verantwortliche benennen, die die Kontrolle betreiben

Der Owner einer Behebungsaufgabe sollte die Person sein, die die Kontrolle danach betreibt: der IT-Leiter für Patching, der Einkauf für Lieferantenverträge, die Personalabteilung für Überprüfungen. Die Compliance-Verantwortlichen koordinieren, prüfen Nachweise und berichten den Fortschritt, können aber nicht alles verantworten.

Schritt 5: "erledigt" als Nachweis definieren

Eine Aufgabe ist erledigt, wenn die Kontrolle wirksam arbeitet und Nachweise erzeugt: das erste freigegebene Zugriffsreview, der erste protokollierte Wiederherstellungstest, die genehmigte und kommunizierte Richtlinie. Tragen Sie den Nachweisverweis laufend im Tracker ein; zum Audit ist der Tracker Ihr Nachweisverzeichnis.

Ein Praxisbeispiel

Angenommen, ein nach ISO 27001 zertifiziertes Unternehmen benötigt NIS2. Der Lückenbericht ISO 27001 → NIS2 ordnet jeden NIS2-Punkt einem Punkt in ISO zu, doch die Validierung gegen die Realität zeigt ein Dutzend Punkte, die nur teilweise erfüllt sind. Nach Behebung gruppiert verdichten sie sich zu vier Workstreams:

• Governance: Freigabe der Maßnahmen durch das Management und Schulung der Geschäftsleitung (eine Vorstandssitzung, ein Schulungskurs, dokumentiert).
• Meldung: ein Verfahren für erhebliche Sicherheitsvorfälle mit Fristen von 24 und 72 Stunden, Vorlagen und eine Übung.
• Lieferanten: Auswahlkriterien, Vertragsklauseln und eine Überprüfung der zwanzig wichtigsten Lieferanten.
• Technische Tiefe: Schwachstellenmeldung, eine Kryptografie-Richtlinie und Wirksamkeitskennzahlen.

Vier Verantwortliche, vier Pläne, jeweils mit Termin und Nachweisliste, statt eines Dutzends unverbundener Zeilen. Governance und Meldung kommen zuerst, weil Aufsichtsbehörden danach zuerst fragen werden; die technische Tiefe folgt im nächsten Quartal.

Wichtigste Erkenntnisse

• Gruppieren Sie unerfüllte Anforderungen danach, was sie beheben wird, nicht nach Anforderungsnummer.
• Erledigen Sie zuerst Governance, Geltungsbereich und Richtlinien; sie lösen alles Weitere aus.
• Geben Sie jedem Workstream einen Owner, der die Kontrolle danach betreibt.
• Definieren Sie "erledigt" als Kontrolle, die wirksam arbeitet und Nachweise erzeugt.

Schritt 6: Fortschritt einfach berichten

Die Leitung möchte drei Zahlen: erfüllte, laufende und nicht begonnene Anforderungen, jeweils je Workstream, dazu die verspäteten Risiken. Wiederholen Sie die Lückenanalyse regelmäßig; wenn sie, wie bei uns, aus Live-Daten berechnet wird, verschieben sich die Abdeckungswerte, während Sie Lücken schließen und sich Frameworks ändern.

Als Ausgangspunkt führen Sie die Lückenanalyse zwischen dem Framework, das Sie haben, und dem, das Sie benötigen, durch und exportieren sie. Die Vergleiche zeigen die häufigsten Paare in beide Richtungen.

Fragen

Wie sollten Compliance-Lücken priorisiert werden?

Nach Risiko und Abhängigkeit: zuerst die Lücken, die andere blockieren (Governance, Geltungsbereich, Richtlinien), dann technische Lücken mit hohem Risiko, danach Dokumentation und Nachweise. Die Nummerierung der Anforderungen ist ein schlechter Anhaltspunkt für die Reihenfolge.

Wer sollte Compliance-Behebungsaufgaben verantworten?

Die Personen, die die Kontrolle danach betreiben, nicht das Compliance-Team. Compliance koordiniert und prüft Nachweise; die Kontroll-Owner liefern.

Wie detailliert sollte ein Compliance-Projektplan sein?

So detailliert, dass jeder Workstream einen Owner, ein Ergebnis, einen Termin und eine Nachweisliste hat. Detailangaben auf Anforderungsebene gehören in den Tracker; der Plan sollte auf ein bis zwei Seiten passen.