Wer ist eigentlich verantwortlich, wenn die Informationssicherheit einer Organisation nicht funktioniert?
Der Administrator? Die IT-Leitung? Der Informationssicherheitsbeauftragte? Ein externer IT-Dienstleister?
Mit NIS-2 wird die Antwort auf diese Frage wesentlich deutlicher: Cybersicherheit ist eine Führungsaufgabe.
Die Leitung einer betroffenen Organisation kann die operative Umsetzung vieler Sicherheitsmaßnahmen selbstverständlich an Fachabteilungen, IT-Verantwortliche oder externe Dienstleister übertragen. Die Verantwortung dafür, dass ein angemessenes Sicherheitsniveau geschaffen und aufrechterhalten wird, lässt sich jedoch nicht einfach vollständig an die IT-Abteilung abschieben.
Damit verändert NIS-2 auch die organisatorische Sicht auf Informationssicherheit. Technik bleibt wichtig – Governance, klare Verantwortlichkeiten, dokumentierte Entscheidungen und ein funktionierendes Informationssicherheitsmanagement werden jedoch ebenso entscheidend.
In Teil 5 unserer Serie betrachten wir deshalb, wie eine geeignete Sicherheitsorganisation aufgebaut werden kann.
Was bedeutet Governance im Zusammenhang mit NIS-2?
Unter Governance versteht man die Strukturen und Regeln, mit denen eine Organisation gesteuert und kontrolliert wird.
Auf die Informationssicherheit übertragen bedeutet das unter anderem:
- Wer entscheidet über Sicherheitsmaßnahmen?
- Wer trägt welche Verantwortung?
- Wer berichtet an die Leitung?
- Wie werden Risiken behandelt?
- Wer darf Restrisiken akzeptieren?
- Wie werden Sicherheitsmaßnahmen kontrolliert?
- Welche Eskalationswege bestehen?
- Wie wird die Umsetzung dokumentiert?
Eine Organisation benötigt dafür klare Strukturen.
Das Ziel lautet nicht, möglichst viele Gremien und Dokumente zu schaffen. Vielmehr muss jederzeit nachvollziehbar sein:
Wer entscheidet was, auf welcher Grundlage und mit welcher Verantwortung?
Die Rolle der Geschäftsführung
Eine der zentralen Aussagen von NIS-2 betrifft die Verantwortung der Leitungsebene.
Die Leitung einer Organisation muss die Maßnahmen zum Management von Cybersicherheitsrisiken genehmigen und deren Umsetzung überwachen.
Damit wird Informationssicherheit endgültig zu einem Managementthema.
Die Geschäftsführung beziehungsweise Behördenleitung sollte beispielsweise regelmäßig Informationen darüber erhalten:
- welche wesentlichen Cyberrisiken bestehen,
- welche kritischen Systeme betroffen sind,
- welche Sicherheitsvorfälle aufgetreten sind,
- welche Maßnahmen umgesetzt wurden,
- welche Maßnahmen noch ausstehen,
- welche Restrisiken bestehen,
- welche Ressourcen benötigt werden.
Eine einfache Aussage wie
„Dafür ist unsere IT zuständig.“
reicht nicht aus.
Was muss die Leitung konkret tun?
Die Leitung muss nicht selbst Firewalls konfigurieren oder Sicherheitslogs analysieren.
Sie muss jedoch sicherstellen, dass geeignete Strukturen vorhanden sind.
Dazu gehört insbesondere:
- Sicherheitsmaßnahmen genehmigen
- Umsetzung überwachen
- Verantwortlichkeiten festlegen
- Ressourcen bereitstellen
- Risiken regelmäßig betrachten
- Berichte entgegennehmen
- Eskalationswege definieren
- Sicherheitsorganisation unterstützen
- Schulungen wahrnehmen
Besonders wichtig ist dabei die Fähigkeit, informierte Entscheidungen zu treffen.
Dafür muss die Leitung ein grundlegendes Verständnis für Cyberrisiken besitzen.
Cybersicherheit gehört in die Führungsebene
Informationssicherheit wurde früher häufig als rein technisches Thema behandelt.
Die typische Organisationsstruktur sah vereinfacht so aus:
Geschäftsführung → IT-Leitung → Administratoren.
Sicherheitsfragen wurden innerhalb der IT gelöst.
Das funktioniert bei modernen Cyberrisiken nur noch eingeschränkt.
Ein erfolgreicher Ransomware-Angriff betrifft beispielsweise nicht nur Server und Computer. Er kann gleichzeitig Auswirkungen haben auf:
- Produktion
- Verwaltung
- Personal
- Kommunikation
- Kunden
- Lieferanten
- Datenschutz
- Finanzen
- Reputation
Cyberrisiken sind damit Unternehmensrisiken beziehungsweise Organisationsrisiken.
Haftung der Leitung
Ein besonders relevantes Thema ist die Haftung.
NIS-2 sieht ausdrücklich eine Verantwortung der Leitungsorgane für die Umsetzung der vorgeschriebenen Risikomanagementmaßnahmen vor. Die konkrete persönliche Haftung richtet sich dabei nach der jeweiligen nationalen Umsetzung und den allgemeinen gesellschafts-, dienst- und haftungsrechtlichen Regelungen.
Wichtig ist deshalb eine differenzierte Betrachtung:
Nicht jeder erfolgreiche Cyberangriff führt automatisch zu einer persönlichen Haftung der Geschäftsführung.
Auch eine hervorragend geschützte Organisation kann Opfer eines Angriffs werden.
Entscheidend ist vielmehr, ob die Leitung ihre Pflichten angemessen erfüllt hat.
Dazu gehören beispielsweise:
- Risiken ernst nehmen
- geeignete Maßnahmen beschließen
- ausreichende Ressourcen bereitstellen
- Umsetzung kontrollieren
- bekannte Probleme nicht ignorieren
- Entscheidungen dokumentieren
Informationssicherheit sollte daher als kontinuierliche Managementaufgabe verstanden werden.
Dokumentierte Entscheidungen schützen die Organisation
Angenommen, eine Risikoanalyse identifiziert eine kritische Schwachstelle.
Die IT empfiehlt eine Sicherheitsmaßnahme.
Die Geschäftsführung entscheidet jedoch, die Maßnahme aus wirtschaftlichen Gründen zunächst nicht umzusetzen.
Eine solche Entscheidung kann grundsätzlich Bestandteil eines Risikomanagementprozesses sein. Nicht jedes Risiko lässt sich sofort beseitigen.
Die Entscheidung sollte dann jedoch nachvollziehbar dokumentiert werden:
- Welches Risiko besteht?
- Wie hoch ist das Risiko?
- Welche Maßnahme wurde empfohlen?
- Warum wurde sie nicht umgesetzt?
- Welche Alternativen bestehen?
- Welches Restrisiko wird akzeptiert?
- Wer hat die Entscheidung getroffen?
- Wann wird die Entscheidung erneut überprüft?
Damit entsteht eine nachvollziehbare Risikoakzeptanz.
Informationspflichten innerhalb der Organisation
Damit die Leitung ihre Verantwortung wahrnehmen kann, benötigt sie Informationen.
Eine funktionierende Sicherheitsorganisation braucht deshalb geregelte Berichtswege.
Der Informationssicherheitsverantwortliche könnte beispielsweise regelmäßig berichten über:
Sicherheitsvorfälle
Wie viele relevante Vorfälle gab es?
Schwachstellen
Welche kritischen Schwachstellen bestehen?
Patchstatus
Wie viele Systeme besitzen fehlende Sicherheitsupdates?
Risiken
Welche Risiken besitzen aktuell die höchste Priorität?
Maßnahmen
Welche Sicherheitsprojekte laufen?
Schulungen
Wie hoch ist die Teilnahmequote?
Audits
Welche Abweichungen wurden festgestellt?
Diese Informationen können beispielsweise in einem regelmäßigen Sicherheitsbericht zusammengefasst werden.
Sicherheitsorganisation aufbauen
Je nach Größe der Organisation kann die Sicherheitsorganisation unterschiedlich aufgebaut sein.
Typische Rollen sind beispielsweise:
- Geschäftsführung beziehungsweise Behördenleitung
- CIO oder IT-Leitung
- CISO
- Informationssicherheitsbeauftragter
- IT-Sicherheitsverantwortliche
- Administratoren
- Datenschutzbeauftragter
- Notfallmanagement
- Fachbereichsverantwortliche
- interne Revision
Nicht jede Organisation benötigt für jede Aufgabe eine eigene Vollzeitstelle.
Entscheidend ist vielmehr, dass die notwendigen Funktionen vorhanden und die Verantwortlichkeiten eindeutig definiert sind.
Die Rolle des Informationssicherheitsbeauftragten
Eine zentrale Rolle kann der Informationssicherheitsbeauftragte – häufig kurz ISB – übernehmen.
Zu seinen Aufgaben können beispielsweise gehören:
- Sicherheitsrichtlinien koordinieren
- Risikoanalysen begleiten
- Sicherheitsmaßnahmen überwachen
- Sicherheitsvorfälle bewerten
- Awareness-Maßnahmen koordinieren
- Audits begleiten
- an die Leitung berichten
- Verbesserungsmaßnahmen verfolgen
Der ISB sollte dabei ausreichend unabhängig arbeiten können und direkten Zugang zur Leitungsebene besitzen.
Ein strukturelles Problem entsteht beispielsweise, wenn dieselbe Person eine Sicherheitsmaßnahme technisch betreibt und anschließend vollständig unabhängig deren Wirksamkeit kontrollieren soll.
Je nach Organisationsgröße sollten deshalb mögliche Interessenkonflikte berücksichtigt werden.
Fachbereiche tragen ebenfalls Verantwortung
Informationssicherheit ist nicht ausschließlich Aufgabe des ISB oder der IT.
Auch Fachbereiche spielen eine wichtige Rolle.
Ein Fachbereich kennt beispielsweise am besten:
- seine Geschäftsprozesse
- verwendete Daten
- notwendige Verfügbarkeiten
- Auswirkungen von Ausfällen
- fachliche Anforderungen
Deshalb sollten Fachbereiche insbesondere bei der Schutzbedarfs- und Risikobewertung beteiligt werden.
Die IT kann beurteilen, dass ein Server ausgefallen ist.
Der Fachbereich kann beurteilen, was dieser Ausfall für die Organisation bedeutet.
Klare Verantwortlichkeiten mit RACI
Eine praktische Möglichkeit zur Definition von Verantwortlichkeiten ist eine sogenannte RACI-Matrix.
RACI steht für:
Responsible
Wer führt die Aufgabe aus?
Accountable
Wer trägt die Gesamtverantwortung?
Consulted
Wer muss fachlich einbezogen werden?
Informed
Wer muss über das Ergebnis informiert werden?
Für einen Sicherheitsvorfall könnte dies beispielsweise bedeuten:
Incident Response wird operativ vom Security-Team durchgeführt.
Die IT-Leitung trägt die Verantwortung für den technischen Prozess.
Datenschutz und betroffene Fachbereiche werden konsultiert.
Die Geschäftsführung wird über schwerwiegende Vorfälle informiert.
Dadurch lassen sich Unklarheiten im Ernstfall erheblich reduzieren.
Ein ISMS als organisatorisches Fundament
Viele der notwendigen Prozesse lassen sich in einem Information Security Management System, kurz ISMS, bündeln.
Ein ISMS ist kein einzelnes Softwareprodukt.
Es handelt sich vielmehr um ein strukturiertes Managementsystem für Informationssicherheit.
Ein ISMS umfasst beispielsweise:
- Sicherheitsziele
- Richtlinien
- Risikoanalysen
- Verantwortlichkeiten
- Maßnahmen
- Kontrollen
- Audits
- Verbesserungsprozesse
- Dokumentation
Bekannte Rahmenwerke hierfür sind beispielsweise ISO/IEC 27001 und der BSI IT-Grundschutz.
Eine Zertifizierung ist dabei nicht automatisch gleichbedeutend mit der Erfüllung sämtlicher NIS-2-Pflichten. Ein etabliertes ISMS kann jedoch eine hervorragende organisatorische Grundlage darstellen.
Der kontinuierliche Verbesserungsprozess
Ein ISMS funktioniert nicht nach dem Prinzip:
Einführen → Dokumentieren → Fertig.
Stattdessen handelt es sich um einen kontinuierlichen Prozess.
Häufig wird dafür der PDCA-Zyklus verwendet:
Plan
Risiken analysieren und Maßnahmen planen.
Do
Maßnahmen umsetzen.
Check
Wirksamkeit überprüfen.
Act
Verbesserungen durchführen.
Danach beginnt der Zyklus erneut.
Dieser Ansatz passt sehr gut zum risikobasierten Charakter von NIS-2.
Sicherheitsrichtlinien schaffen verbindliche Regeln
Ein wichtiger Bestandteil der Governance sind dokumentierte Richtlinien.
Typische Beispiele sind:
- Informationssicherheitsleitlinie
- Passwortrichtlinie
- Berechtigungskonzept
- Backup-Richtlinie
- Patchmanagement-Richtlinie
- Mobile-Device-Richtlinie
- Homeoffice-Richtlinie
- Incident-Response-Richtlinie
- Lieferantenrichtlinie
- Notfallmanagement
- Logging- und Monitoring-Richtlinie
Eine Richtlinie sollte jedoch nicht nur existieren.
Sie muss:
- verständlich sein,
- genehmigt werden,
- kommuniziert werden,
- umgesetzt werden,
- regelmäßig überprüft werden.
Eine zehn Jahre alte Sicherheitsrichtlinie, die niemand kennt, bietet kaum praktischen Nutzen.
Richtlinie, Prozess und Arbeitsanweisung unterscheiden
Bei der Dokumentation ist eine einfache Trennung hilfreich.
Eine Richtlinie beschreibt grundsätzlich, was gelten soll.
Ein Prozess beschreibt, wie ein wiederkehrender Ablauf organisiert ist.
Eine Arbeitsanweisung beschreibt konkret, wie eine bestimmte Tätigkeit durchgeführt wird.
Beispiel Patchmanagement:
Die Richtlinie fordert, kritische Sicherheitsupdates zeitnah einzuspielen.
Der Prozess legt fest, wie Schwachstellen erkannt, bewertet, getestet und freigegeben werden.
Die Arbeitsanweisung beschreibt anschließend beispielsweise konkret, wie ein Administrator Updates auf einer bestimmten Serverplattform installiert.
Diese Struktur erleichtert die Pflege der Dokumentation erheblich.
Dokumentation als Nachweis
Ein entscheidender Grundsatz für NIS-2 lautet sinngemäß:
Sicherheitsmaßnahmen müssen nicht nur existieren – ihre Umsetzung sollte auch nachvollziehbar sein.
Dazu können beispielsweise folgende Nachweise gehören:
- genehmigte Sicherheitsrichtlinien
- Protokolle von Leitungssitzungen
- Risikoanalysen
- Risikoregister
- Maßnahmenpläne
- Auditberichte
- Schulungsnachweise
- Patchberichte
- Backup-Protokolle
- Restoretests
- Incident-Berichte
- Lieferantenbewertungen
- Ergebnisse von Schwachstellenscans
Dadurch entsteht eine nachvollziehbare Sicherheitsorganisation.
Dokumentation aktuell halten
Dokumentation besitzt allerdings nur dann einen Wert, wenn sie den tatsächlichen Zustand widerspiegelt.
Deshalb sollten Dokumente mindestens Informationen enthalten wie:
- Dokumentenverantwortlicher
- Version
- Freigabestatus
- Freigabedatum
- Änderungsverlauf
- nächster Prüftermin
Veraltete Dokumente sollten eindeutig gekennzeichnet oder archiviert werden.
So lässt sich vermeiden, dass Mitarbeitende versehentlich nach überholten Vorgaben arbeiten.
Management-Reporting etablieren
Die Leitung benötigt keine hundertseitigen technischen Reports über einzelne Firewall-Ereignisse.
Sie benötigt Informationen, anhand derer Entscheidungen getroffen werden können.
Ein Management-Dashboard könnte beispielsweise zeigen:
- Anzahl kritischer Risiken
- offene Sicherheitsmaßnahmen
- überfällige Maßnahmen
- kritische Schwachstellen
- Patchquote
- MFA-Abdeckung
- Backup-Erfolgsquote
- Ergebnisse von Restoretests
- Sicherheitsvorfälle
- Schulungsquote
- Lieferantenrisiken
Besonders interessant ist dabei die Entwicklung über einen längeren Zeitraum.
Steigt die Zahl kritischer Schwachstellen kontinuierlich, besteht Handlungsbedarf.
Eskalationswege festlegen
Governance bedeutet ebenfalls, festzulegen, wann ein Problem eskaliert werden muss.
Beispielsweise könnte definiert werden:
Ein kritisches ungepatchtes System wird zunächst an die IT-Leitung gemeldet.
Wird die Schwachstelle innerhalb einer bestimmten Frist nicht behoben, erfolgt eine Eskalation an den Informationssicherheitsbeauftragten.
Besteht anschließend weiterhin ein nicht akzeptables Risiko, wird die Geschäfts- oder Behördenleitung informiert.
Solche Regeln verhindern, dass bekannte Sicherheitsprobleme monatelang unbearbeitet bleiben.
Externe Dienstleister entlasten nicht von der Verantwortung
Viele Organisationen betreiben ihre IT teilweise oder vollständig über externe Anbieter.
Beispiele sind:
- Managed Service Provider
- Cloud-Anbieter
- Rechenzentren
- externe Administratoren
- Security Operations Center
- Backup-Dienstleister
Diese Unternehmen können zahlreiche operative Aufgaben übernehmen.
Die eigene Organisation muss jedoch weiterhin sicherstellen, dass die ausgelagerten Leistungen angemessen abgesichert sind.
Dazu gehören unter anderem:
- klare Verträge
- definierte Sicherheitsanforderungen
- geregelte Meldewege
- überprüfbare Service-Level
- Verantwortlichkeiten
- Notfallkontakte
- Kontroll- und Nachweismöglichkeiten
Outsourcing der IT bedeutet nicht automatisch Outsourcing der Verantwortung.
Ein mögliches Governance-Modell
Für eine mittelgroße Organisation könnte die Struktur beispielsweise folgendermaßen aussehen:
Geschäftsführung / Behördenleitung
trägt die übergeordnete Verantwortung und trifft wesentliche Entscheidungen.
↓
Informationssicherheitsbeauftragter / CISO
koordiniert Informationssicherheit, Risiken und Reporting.
↓
IT-Leitung
verantwortet die operative technische Umsetzung.
↓
IT- und Security-Teams
setzen konkrete Sicherheitsmaßnahmen um.
Parallel dazu werden:
- Datenschutz
- Fachbereiche
- Einkauf
- Personal
- Gebäudemanagement
- Notfallmanagement
je nach Thema eingebunden.
Damit entsteht Informationssicherheit als organisationsweite Struktur statt als isolierte IT-Aufgabe.
Typische Governance-Fehler
In der Praxis treten immer wieder ähnliche Probleme auf:
- Informationssicherheit wird ausschließlich der IT überlassen.
- Die Leitung erhält keine regelmäßigen Sicherheitsberichte.
- Verantwortlichkeiten sind nicht dokumentiert.
- Niemand darf verbindlich über Restrisiken entscheiden.
- Sicherheitsrichtlinien sind veraltet.
- Maßnahmen besitzen keine Verantwortlichen.
- Fristen werden nicht überwacht.
- Sicherheitsentscheidungen werden nicht dokumentiert.
- Externe Dienstleister werden nicht ausreichend kontrolliert.
- Sicherheitsrollen verfügen nicht über ausreichende Ressourcen.
- Interessenkonflikte werden nicht berücksichtigt.
Viele dieser Probleme lassen sich organisatorisch lösen, ohne sofort große Investitionen in neue Technik vorzunehmen.
Eine einfache Governance-Checkliste
Für eine erste Überprüfung können Sie folgende Fragen verwenden:
☐ Ist Informationssicherheit ausdrücklich als Führungsaufgabe definiert?
☐ Sind Rollen und Verantwortlichkeiten dokumentiert?
☐ Gibt es einen Informationssicherheitsverantwortlichen?
☐ Existieren regelmäßige Berichte an die Leitung?
☐ Werden wesentliche Cyberrisiken der Leitung bekannt gemacht?
☐ Gibt es ein dokumentiertes Risikoregister?
☐ Sind Risikoakzeptanzen nachvollziehbar freigegeben?
☐ Existieren verbindliche Sicherheitsrichtlinien?
☐ Haben Maßnahmen Verantwortliche und Termine?
☐ Werden externe Dienstleister in die Sicherheitsorganisation einbezogen?
☐ Werden Richtlinien regelmäßig überprüft?
☐ Kann die Umsetzung wichtiger Maßnahmen nachgewiesen werden?
☐ Existieren definierte Eskalationswege?
☐ Werden Sicherheitsentscheidungen dokumentiert?
Je mehr dieser Fragen mit Nein beantwortet werden, desto größer ist der organisatorische Handlungsbedarf.
Governance braucht gelebte Praxis
Eine Organisation kann hunderte Seiten Sicherheitsdokumentation besitzen und trotzdem schlecht geschützt sein.
Entscheidend ist deshalb nicht allein die Menge der Dokumente.
Eine funktionierende Governance zeigt sich vielmehr daran, dass:
Risiken erkannt werden.
Verantwortliche bekannt sind.
Entscheidungen getroffen werden.
Maßnahmen umgesetzt werden.
Ergebnisse kontrolliert werden.
Probleme eskaliert werden.
Verbesserungen stattfinden.
Dokumentation dient anschließend dazu, diese Prozesse nachvollziehbar zu machen.
NIS-2 macht deutlich, dass Informationssicherheit nicht allein in den Serverraum gehört. Cybersicherheit ist eine Führungs- und Organisationsaufgabe.
Geschäftsführungen und Behördenleitungen müssen geeignete Risikomanagementmaßnahmen genehmigen, ihre Umsetzung überwachen und sich ausreichend mit den bestehenden Cyberrisiken beschäftigen. Gleichzeitig braucht die Organisation klare Verantwortlichkeiten, funktionierende Berichts- und Eskalationswege sowie eine nachvollziehbare Dokumentation.
Ein strukturiertes ISMS kann dabei zum organisatorischen Fundament werden. Es verbindet Risikoanalysen, Sicherheitsrichtlinien, Verantwortlichkeiten, Kontrollen und kontinuierliche Verbesserungen zu einem gemeinsamen Managementsystem.
Die entscheidende Frage lautet damit nicht mehr nur:
„Ist unsere IT sicher?“
Sondern:
„Können wir nachvollziehbar zeigen, wer für unsere Informationssicherheit verantwortlich ist, welche Risiken wir kennen, welche Entscheidungen getroffen wurden und ob unsere Sicherheitsmaßnahmen tatsächlich funktionieren?“
Wer diese Frage belastbar beantworten kann, hat einen wesentlichen Schritt auf dem Weg zu einer strukturierten NIS-2-Umsetzung geschafft.