Sicherheitsrahmen werden erst mit Aufgaben im Betrieb nützlich

Kurz gesagt: Ein Sicherheitsrahmen ist ein Ordnungssystem für den Umgang mit Cyberrisiken. Er beschreibt, welche Fähigkeiten eine Organisation braucht, damit sie Risiken erkennt, Schutzmaßnahmen plant, Angriffe bemerkt, Störungen bearbeitet und wieder arbeitsfähig wird. Bekannte Beispiele sind das NIST Cybersecurity Framework aus den USA und der IT-Grundschutz des Bundesamts für Sicherheit in der Informationstechnik. Für ITSM und IT-Management zählt aber nicht der Name des Rahmenwerks, sondern die Frage, ob daraus im Alltag konkrete Aufgaben entstehen.

Cybersecurity-Rahmenwerke klingen oft nach Strategiepapier, Auditordner oder Managementfolie. Genau dort verlieren sie im Betrieb schnell ihren Wert. Ein schönes Zielbild verhindert keinen Ausfall, wenn niemand weiß, wer eine Schwachstelle bewertet, wer eine Ausnahme freigibt, wer eine Kontrolle wiederholt und wer nach einer Störung den Prozess verbessert. Der nützliche Teil beginnt erst, wenn aus Vorgaben sichtbare Arbeit wird.

Warum der Rahmen allein nicht reicht

Das NIST Cybersecurity Framework ordnet Cybersecurity in Funktionen wie Governance, Identifizieren, Schützen, Erkennen, Reagieren und Wiederherstellen. Die aktuelle Fassung hebt Governance besonders hervor. Damit wird deutlich: Sicherheit ist nicht nur eine technische Aufgabe der Security-Abteilung, sondern eine Führungs- und Betriebsaufgabe mit Rollen, Risikoentscheidungen und laufender Steuerung.

Der deutsche IT-Grundschutz verfolgt ebenfalls einen strukturierten Ansatz. Er hilft Organisationen, Informationssicherheit systematisch aufzubauen und typische Gefährdungen mit passenden Maßnahmen zu verbinden. Auch hier entsteht der Nutzen nicht durch das bloße Vorhandensein eines Standards. Der Nutzen entsteht, wenn Teams daraus ableiten, was im eigenen Betrieb tatsächlich geprüft, dokumentiert, umgesetzt und verbessert werden muss.

ITSM übersetzt Vorgaben in Arbeit

IT Service Management ist an dieser Stelle mehr als ein Unterstützer. ITSM kann die Brücke zwischen Rahmenwerk und Tagesgeschäft bauen. Ein Risiko wird erst dann bearbeitbar, wenn es als Aufgabe auftaucht. Eine Schutzmaßnahme wird erst dann belastbar, wenn sie einen Besitzer, einen Termin, eine Prüffrequenz und eine Eskalationsregel hat. Eine Reaktion auf Sicherheitsvorfälle wird erst dann zuverlässig, wenn sie mit Störungsmanagement, Change Management, Wissensdatenbank und Kommunikation verbunden ist.

Das klingt unspektakulär, ist aber entscheidend. Sicherheitsanforderungen scheitern im Alltag selten daran, dass ihr Ziel falsch wäre. Sie scheitern daran, dass sie zwischen Gremien, Tools und Zuständigkeiten hängen bleiben. Der Service Desk sieht Auffälligkeiten, aber kennt den Meldeweg nicht. Das Infrastrukturteam pflegt Systeme, aber erhält Sicherheitsausnahmen ohne Ablaufdatum. Das Management verlangt Kennzahlen, aber niemand hat festgelegt, welche Daten belastbar genug sind.

Aus Kontrollen werden Betriebsroutinen

Ein Sicherheitsrahmen sollte deshalb nicht als zusätzlicher Dokumentationsberg eingeführt werden. Besser ist die Frage: Welche Routinen müssen daraus im Betrieb entstehen? Dazu gehören wiederkehrende Prüfungen von Berechtigungen, saubere Übergaben nach Änderungen, nachvollziehbare Ausnahmeentscheidungen, klare Reaktionswege bei Warnungen und verständliche Rückmeldungen an betroffene Fachbereiche.

Ein Beispiel ist die Behandlung von Sicherheitswarnungen. Ein Rahmenwerk kann sagen, dass Risiken erkannt und behandelt werden müssen. Im Betrieb braucht es aber mehr: Wer bewertet die Warnung? Wann wird daraus ein Incident? Wann reicht ein normales Ticket? Wer entscheidet über eine kurzfristige Änderung? Wie wird dokumentiert, dass die Maßnahme wirkt? Erst diese Übersetzung macht aus einem Sicherheitsprinzip eine wiederholbare Arbeitsweise.

Governance braucht sichtbare Besitzer

Besonders wichtig ist die Besitzerfrage. Governance bedeutet nicht, dass ein Lenkungskreis alles selbst entscheidet. Governance bedeutet, dass Zuständigkeiten, Entscheidungsgrenzen und Rückmeldungen klar sind. Für jeden wichtigen Sicherheitsbereich sollte sichtbar sein, wer fachlich verantwortlich ist, wer technisch liefert, wer Risiken akzeptieren darf und wer bei Abweichungen informiert werden muss.

Ohne diese Klarheit werden Audits und Reviews schnell zur Suche nach Schuldigen. Mit klaren Besitzern wird daraus eine Steuerungsschleife. Ein Team erkennt eine Lücke, priorisiert sie, setzt eine Maßnahme um, prüft die Wirkung und meldet zurück, wo Regeln oder Ressourcen angepasst werden müssen. Genau diese Schleife unterscheidet gelebte Sicherheit von Papierarbeit.

Welche Fragen jetzt helfen

• Rollen: Gibt es für jede zentrale Sicherheitsanforderung einen operativen Besitzer und einen Entscheider?
• Ticketfähigkeit: Lassen sich Vorgaben als konkrete Aufgaben mit Termin, Status und Ergebnis verfolgen?
• Ausnahmen: Haben Abweichungen Ablaufdatum, Begründung, Risikoentscheidung und Wiedervorlage?
• Rückmeldung: Kommen Erkenntnisse aus Störungen, Warnungen und Audits wieder in Prozesse und Wissensdatenbank zurück?
• Kennzahlen: Zeigen Reports echte Betriebsfähigkeit oder nur, dass Dokumente existieren?

Für IT-Leitungen und Serviceverantwortliche liegt die Chance darin, Sicherheitsrahmen pragmatisch zu nutzen. Nicht jedes Kapitel muss sofort perfekt sein. Entscheidend ist, die wichtigsten Risiken in wiederholbare Arbeit zu übersetzen. Dann wird aus einem Rahmenwerk kein schwerer Ordner, sondern ein gemeinsamer Arbeitsplan für Sicherheit, Betrieb und Management.

Quellen: NIST Cybersecurity Framework, NIST-Veröffentlichung zur Version 2.0, BSI IT-Grundschutz. Stand der Quellenprüfung: 12.06.2026.

Bildquelle: Pexels / https://www.pexels.com/photo/3184292/