Die behördlichen Kontrollen nehmen stetig zu, während Cyberbedrohungen sich rasant weiterentwickeln. Wer Risiken heute noch unstrukturiert in Excel-Tabellen oder E-Mail-Verläufen erfasst, wird diesem doppelten Druck nicht standhalten. Ein Risikomanagement-Framework bietet Unternehmen stattdessen einen strukturierten Leitfaden. Es schützt die Assets eines Unternehmens und wächst flexibel mit den Anforderungen mit.

Der eigentliche Mehrwert liegt aber in der Standardisierung: Es geht nicht nur darum, Risiken zu erkennen, sondern sie jedes Mal auf die gleiche Weise zu handhaben, unabhängig davon, wer die Arbeit erledigt. Ein Framework bietet verschiedenen Teams zudem eine gemeinsame Sprache. Wenn IT-Security, Finanzabteilung und operatives Geschäft auf dasselbe Risikoregister blicken, verstehen alle exakt dasselbe unter einem „hohen Risiko“. Ohne diese gemeinsame Basis verliert man sich in endlosen Diskussionen über Definitionen, anstatt handfeste Entscheidungen zu treffen.

Was ist ein Risikomanagement-Framework (RMF)?

Ein Risikomanagement-Framework ist ein wiederholbarer Prozess zur Identifizierung, Bewertung und Minderung von Unternehmensrisiken. Es bietet für jede Risikobewertung denselben Ausgangspunkt: dieselben Kategorien, dieselbe Bewertungslogik, denselben Überprüfungszyklus.

Diese Konsistenz können fragmentierte Tabellenkalkulationen nicht bieten. Eine Tabellenkalkulation kann Risiken auflisten. Sie kann jedoch nicht sicherstellen, dass jedes Risiko auf die gleiche Weise bewertet, termingerecht überprüft oder bei Bedarf eskaliert wird. Wenn die Anzahl der Risiken wächst und immer mehr Personen auf das Risikoregister zugreifen, führt das unweigerlich zu einem Kontrollverlust. Ein Framework schließt diese Lücke, indem es den Prozess einmalig definiert und dann überall konsistent anwendet.

Die meisten Frameworks basieren auf drei zentralen Bausteinen: Einem gemeinsamen Vokabular, um Risiken zu beschreiben. Einem klaren Prozess, der zeigt, wie aus einer bloßen Bedrohung ein gesteuertes Risiko wird. Und einer Methode, um im Nachhinein lückenlos nachzuweisen, dass dieser Prozess auch wirklich stattgefunden hat. Dieser dritte Punkt ist wichtiger, als es zunächst klingt: Aufsichtsbehörden und Prüfer fragen selten, ob Sie über ein Risiko nachgedacht haben. Sie fordern, dass Sie es belegen.

Ein vereinfachter 5-Schritte-Prozess für das Risikomanagement

Die im Folgenden genannten Standards unterscheiden sich in Struktur und Terminologie, und ihre einzelnen Prozessschritte folgen nicht immer einer strengen Abfolge. Das NIST RMF arbeitet mit sieben Schritten, das NIST CSF 2.0 mit sechs Funktionen und die ISO 31000 nutzt fünf Phasen mit wieder anderen Bezeichnungen. Trotz dieser Unterschiede basieren die meisten Frameworks im Kern jedoch auf denselben wiederkehrenden Prozessschritten.

Hier ist eine vereinfachte Darstellung, die einen schnellen Vergleich von Frameworks ermöglicht, jedoch kein eigenständiges offizielles Modell darstellt:

1. Identifizieren

Potenzielle operative, finanzielle, Cyber- und Compliance-Bedrohungen aufdecken, bevor sie zu Vorfällen werden. Dieser Schritt ist bewusst breit angelegt. Eine Bedrohung, die in dieser Phase nicht in die Liste aufgenommen wird, wird später nicht bewertet.

2. Bewerten

Es wird ermittelt, wie wahrscheinlich ein Risiko ist und welche Auswirkungen es heute hätte. Das kann das inhärente Risiko sein (wenn noch keine Maßnahmen ergriffen wurden) oder das aktuelle Risikoniveau (wenn bereits erste Kontrollen existieren). Diese Bewertung entscheidet darüber, ob ein Risiko überhaupt gemindert werden muss oder ob es innerhalb der Grenzen liegt, die das Unternehmen bereits tolerieren kann.

3. Minderung

Anwendung interner Kontrollmaßnahmen, Übertragung des Risikos durch Versicherungen oder Verträge oder formelle Akzeptanz von Risiken, die innerhalb der Toleranzgrenzen liegen. Jede Kontrolle ist mit einem erwarteten Restrisiko verbunden, also dem Niveau, auf das das Risiko sinken soll, sobald sie aktiv ist. Nicht jedes Risiko erfordert zwingend eine Kontrolle. Manche Risiken sind kostengünstiger zu akzeptieren als zu beheben, und ein gutes Rahmenwerk macht dies zu einer expliziten Entscheidung und nicht zu einer Standardvorgehensweise.

4. Überwachen

Das Nachverfolgen, ob das tatsächliche Risiko dem Restrisiko entspricht, das durch die Minimierung erreicht werden sollte, sowie das Anpassen von Kontrollen beim Auftreten neuer Bedrohungen. Eine Kontrolle, die im letzten Jahr noch funktioniert hat, kann unbemerkt ihre Wirksamkeit verlieren, wenn sich Systeme, Anbieter und Mitarbeiter ändern. Durch die Überwachung wird die Lücke zwischen Erwartung und Realität erkannt, bevor es zu einem Vorfall kommt.

5. Steuerung

Festlegung von Verantwortlichkeiten auf Führungsebene und Festlegung der Art und Weise, wie Risiken an den Vorstand gemeldet werden. Ohne einen benannten Verantwortlichen fällt die Verantwortung für ein Risiko in der Regel demjenigen zu, der es zuerst angesprochen hat, und nicht demjenigen, der tatsächlich dafür verantwortlich ist.

Die gängigsten Arten von Risikomanagement-Frameworks

Jedes der unten aufgeführten Frameworks wurde entwickelt, um ein anderes Problem zu lösen. Das ist der Hauptgrund, warum man die Unterschiede kennen sollte. Wählt man das falsche aus, löst man ein Problem, das man gar nicht hat.

ISO 31000 ist eine globale Norm, die Grundsätze und einen Prozess für das Risikomanagement festlegt, jedoch keine zertifizierbare Checkliste darstellt. Der Prozess umfasst die Festlegung des Kontexts, die Risikobewertung, den Umgang mit Risiken sowie die Überwachung und Überprüfung, wobei Kommunikation und Konsultation durchgängig eine Rolle spielen. Die Norm gilt für jede Organisation, unabhängig von ihrer Größe und Branche, was sie zum gängigsten Ausgangspunkt für ein allgemeines Risikomanagement-Programm macht.

Da ISO 31000 nicht zertifizierbar ist, führt niemand ein Audit danach durch, wie es etwa bei der ISO 27001 der Fall ist. Für die meisten Unternehmen ist das ein klarer Vorteil. Das bedeutet, dass Sie die für Sie passenden Teile übernehmen und auf die für Sie nicht relevanten Formalitäten verzichten können, ohne dies durch ein externes Audit nachweisen zu müssen.

NIST RMF und NIST CSF

Hierbei handelt es sich um zwei separate NIST-Veröffentlichungen, deren Verwechslung ein häufiger Fehler ist. Das NIST RMF, offiziell SP 800-37, umfasst sieben Schritte (Vorbereiten, Kategorisieren, Auswählen, Implementieren, Bewerten, Autorisieren, Überwachen) zur Zertifizierung und Autorisierung einzelner Informationssysteme. Es ist vor allem im US-Bundesbereich und bei Auftragnehmern verbreitet, obwohl seine Struktur weit darüber hinaus übernommen wurde.

Das NIST CSF ist ein eigenständiges, umfassenderes Framework für die gesamte Cybersicherheitslage einer Organisation. Die aktuelle Version, CSF 2.0, die im Februar 2024 veröffentlicht wurde, gliedert die Arbeit in sechs Funktionen: Steuern, Identifizieren, Schützen, Erkennen, Reagieren und Wiederherstellen. Die Funktion „Steuern“ wurde speziell in dieser Version hinzugefügt, was widerspiegelt, welche Bedeutung Governance mittlerweile im gesamten Framework einnimmt.

Beides ist keine Zertifizierung, die man erwerben kann. Stattdessen bieten beide ein gemeinsames Vokabular für Cybersicherheitsrisiken. In der Praxis nutzen viele Organisationen schlichtweg beide. Das RMF dient dabei der Autorisierung auf Systemebene und das CSF steuert das übergeordnete Sicherheitsprogramm.

COSO ERM

Das 2017 aktualisierte Enterprise Risk Management Framework von COSO richtet sich an eine ganz andere Zielgruppe als die zuvor genannten Regelwerke. Der Schwerpunkt liegt auf der Integration von Risiken in die Unternehmensstrategie, die Leistungsentwicklung und die Unternehmenskultur, nicht auf technischen Kontrollen. Es gliedert sich in fünf Komponenten: Governance und Kultur, Strategie und Zielsetzung, Leistungsentwicklung, Überprüfung und Überarbeitung sowie Information, Kommunikation und Berichterstattung. Diese Bereiche umfassen insgesamt 20 zugrunde liegende Prinzipien.

Ähnlich wie die ISO 31000 ist auch das COSO ERM nicht zertifizierbar. Vorstände und Führungsteams wenden es freiwillig an, um zu zeigen, dass das Risikomanagement wirklich in die Unternehmensführung integriert ist. Für rein technische Cybersicherheitsthemen ist dieses Framework daher weniger geeignet. Es spielt seine Stärken jedoch voll aus, wenn die Zielgruppe für Risikodialoge die Geschäftsführung ist und nicht das IT-Team.

COBIT

COBIT wird von der ISACA herausgegeben und ist speziell auf IT-Governance zugeschnitten, anstatt auf das allgemeine Risikomanagement. Die aktuelle Version COBIT 2019 gliedert 40 Governance- und Managementziele in fünf Kernbereiche. Ein Bereich deckt die Governance selbst ab. Die anderen vier umfassen Managementaktivitäten wie die Planung, den Aufbau, den Betrieb und die Überwachung der IT.

Unternehmen greifen meist auf COBIT zurück, wenn Technologieentscheidungen optimal an den geschäftlichen Zielen ausgerichtet werden sollen. Das Risikomanagement zieht sich dabei wie ein roter Faden durch diese umfassende Governance-Arbeit, ist aber nicht der eigentliche Hauptzweck des Regelwerks. COBIT wird oft treffend als ein Framework für das Management anderer Frameworks beschrieben. Es steht als übergeordnete Schicht über Normen wie der ISO 27001 oder NIST, ohne diese zu ersetzen.

Risikomanagement-Frameworks für Drittanbieter und KI

Beziehungen zu Anbietern und KI-Systeme haben jeweils eigene, spezifische Frameworks erhalten, da keines der beiden klar in die oben genannten Frameworks passt. Das Risikomanagement für Drittanbieter (Third-Party Risk Management, TPRM) deckt die Risiken ab, die ein Anbieter oder Lieferant für Ihr Unternehmen mit sich bringt. Es handelt sich um einen Bereich, in dem Vorgaben wie DORA und NIS-2 zunehmend von Unternehmen erwarten, dass sie diese Risiken formell managen und nicht einfach ignorieren. Die schwache Sicherheitslage eines Anbieters wird in dem Moment zu Ihrem Risiko, in dem dieser mit Ihren Daten oder Ihren Systemen in Berührung kommt.

Aufseiten der künstlichen Intelligenz gliedert das 2023 veröffentlichte NIST AI Risk Management Framework die KI-spezifischen Risiken in vier Kernfunktionen: Steuern, Erfassen, Messen und Handhaben. Die Anwendung ist freiwillig und es gibt dafür kein formelles Audit oder Zertifikat. Für Organisationen, die stattdessen ein zertifizierbares Äquivalent wünschen, deckt die Norm ISO 42001 KI-Managementsysteme ab, so wie die Norm ISO 27001 die Informationssicherheit abdeckt. Es ist zu erwarten, dass immer mehr Organisationen das eine oder das andere verlangen werden, da KI-Systeme zu einem festen Bestandteil von Sicherheitsüberprüfungen bei Anbietern werden.

So wählen Sie das richtige Framework für Ihr Unternehmen

Diese drei Faktoren helfen Ihnen dabei, die Auswahl einzugrenzen:

Branche und regulatorische Anforderungen

Ein Unternehmen im Gesundheitswesen und ein Softwareanbieter stehen vor unterschiedlichen Verpflichtungen, und diese Verpflichtungen weisen oft auf unterschiedliche Frameworks hin. Finanzdienstleister, die DORA unterliegen, brauchen zum Beispiel ein Framework, das IKT-Risiken gemäß den Anforderung der DORA abbildet. Deshalb wählen die meisten eher NIST-orientierte oder auf ISO 31000 basierende Ansätze statt COBIT.

Unternehmensgröße und Komplexität

Ein kleineres Unternehmen mit einem Risikoverantwortlichen und einer Handvoll Systemen benötigt nicht die 40 Ziele von COBIT. Es braucht etwas, das es tatsächlich konsequent umsetzen kann. Ein größeres Unternehmen mit mehr komplexen Komponenten ist oft auf etwas mehr Struktur angewiesen, um Risiken abteilungsübergreifend im Blick zu behalten.

Ihre aktuelle Compliance-Struktur

Haben Sie bereits eine ISO-27001-Zertifizierung, bietet sich ISO 31000 als Ergänzung an, damit Sie im gesamten Unternehmen eine einheitliche Risikosprache verwenden. Streben Sie dagegen NIS-2 an oder einen Vertrag mit NIST-Vorgaben, passen die Kontrollen aus NIST RMF oder CSF meist besser. Wählt man stattdessen ein Framework, das nicht zur bestehenden Struktur passt, macht man sich damit nur zusätzliche Arbeit, die beim nächsten Mal wieder ansteht.

Keiner dieser Punkte zählt für sich allein. Ein mittelgroßes Finanzunternehmen unter DORA bringt zum Beispiel oft mehrere davon mit: eine regulierte Branche, mittlere Komplexität und meist schon eine ISO-27001-Zertifizierung. In so einem Fall macht es in der Regel Sinn, auf dem aufzubauen, was schon da ist, statt auf ein Framework mit ganz anderem Fokus zu wechseln, wie COBIT mit seinem Blick auf IT-Governance oder COSO mit seiner Perspektive aus der Vorstandsebene.

Beispiele für Risikomanagement-Frameworks nach Anwendungsfall

Das sind Ansatzpunkte, keine endgültigen Antworten. Die meisten Organisationen kombinieren am Ende zwei Frameworks, statt sich für genau eines zu entscheiden, ähnlich wie NIST RMF und CSF häufig zusammen eingesetzt werden.

Risikomanagement-Frameworks in Formalize verwalten

Die meisten Unternehmen starten ihr Risikoregister in einer Excel-Tabelle. Eine Excel-Tabelle kann eine Liste von Risiken enthalten, aber kein Risiko automatisch neu bewerten, wenn eine Kontrolle ausfällt, keinen Verantwortlichen daran erinnern, dass eine Überprüfung überfällig ist, und einem Auditor keinen aktuellen, einheitlichen Datensatz zeigen statt eines Exports vom letzten Quartal.

Diese Lücke zeigt sich meistens im ungünstigsten Moment, oft kurz vor einem Audit oder einer Vorstandsprüfung, wenn jemand merkt, dass die Tabelle seit dem Wechsel von drei Teammitgliedern nicht mehr aktualisiert wurde.

Das einheitliche Risikobewertungstool von Formalize ermöglicht es Teams, individuelle oder vorgefertigte Risikokontrollen zuzuordnen, Risiken einheitlich zu bewerten und sie fortlaufend zu überwachen, statt die Übung jedes Quartal manuell zu wiederholen. Für Unternehmen, die Risiken über mehrere Frameworks hinweg verwalten, hält die All-in-One-Risikomanagement-Plattform von Formalize diese Arbeit in einem einzigen System, statt in parallelen Tabellen per Framework. Und da Lieferantenrisiken selten lange getrennt vom restlichen Risikoregister bleiben, hält die Funktion für Drittanbieter-Risikomanagement (TPRM) von Formalize das Lieferantenrisiko im selben System wie alles andere, statt in einem eigenen, isolierten Prozess.