ISO 27001 schreibt kein Risikoregister vor, doch die Abschnitte 6.1.2, 6.1.3 und 8.2 verlangen Aufzeichnungen, die auf eines hinauslaufen: jedes Risiko, sein Eigentümer, seine Folgen und seine Wahrscheinlichkeit, sein Niveau gemessen an Ihren Kriterien, die gewählte Behandlung sowie die Freigabe des Plans und die Akzeptanz des Restrisikos durch den Eigentümer. Auditoren prüfen es an Ihrer eigenen Methode und an seinen Datumsangaben.
Dieser Leitfaden behandelt, was die Norm verlangt, welche Spalten ein Register braucht, eine Vorlage zum Kopieren, die Bewertung, das Restrisiko, was Auditoren prüfen, warum Register scheitern, wie NIS2 hineinpasst, und eine Checkliste.
| Anforderung | Abschnitt | Wo sie im Register sichtbar wird |
|---|---|---|
| Risikokriterien einschließlich Risikoakzeptanzkriterien; konsistente, vergleichbare Ergebnisse | 6.1.2 a), b) | Eine einseitige Methode mit definierten Skalen und einer Akzeptanzschwelle |
| Risiken für Vertraulichkeit, Integrität und Verfügbarkeit und ihre Eigentümer | 6.1.2 c) | Spalten für Szenario, Schutzziele und Eigentümer |
| Folgen, Wahrscheinlichkeit, Niveau, Priorität | 6.1.2 d), e) | Bewertungen im Vergleich zur Akzeptanzschwelle |
| Behandlung, Abgleich der Controls mit Anhang A, Erklärung zur Anwendbarkeit | 6.1.3 a) bis d) | Verweise auf Controls, die zur SoA passen |
| Risikobehandlungsplan | 6.1.3 e) | Maßnahmen, Verantwortliche, Fälligkeitstermine |
| Freigabe des Plans und des Restrisikos durch den Eigentümer | 6.1.3 f) | Restniveau, Name, Datum, Begründung |
| Neubeurteilung in geplanten Abständen oder bei erheblichen Änderungen | 8.2 | Überprüfungsdaten und Änderungshistorie |
| Umsetzung des Plans | 8.3 | Status und Nachweise |
Was verlangt ISO 27001 für ein Risikoregister?
Die Anforderungen stehen in zwei Planungsabschnitten und zwei operativen Abschnitten. Sinngemäß:
- Abschnitt 6.1.2, Risikobeurteilung. Risikokriterien festlegen, einschließlich der Kriterien für die Risikoakzeptanz und für die Durchführung von Beurteilungen. Sicherstellen, dass wiederholte Beurteilungen konsistente, gültige und vergleichbare Ergebnisse liefern. Risiken für die Vertraulichkeit, Integrität und Verfügbarkeit der Informationen im Anwendungsbereich sowie deren Risikoeigentümer identifizieren. Mögliche Folgen und realistische Wahrscheinlichkeit beurteilen und Risikoniveaus bestimmen. Diese mit Ihren Kriterien vergleichen und priorisieren.
- Abschnitt 6.1.3, Risikobehandlung. Behandlungsoptionen wählen. Die erforderlichen Controls bestimmen, mit Anhang A abgleichen, damit nichts Notwendiges fehlt, und die Erklärung zur Anwendbarkeit (SoA) erstellen. Einen Risikobehandlungsplan erstellen. Die Freigabe des Plans und die Akzeptanz der Restrisiken durch die Risikoeigentümer einholen.
- Abschnitt 8.2. Risiken in geplanten Abständen beurteilen oder wenn erhebliche Änderungen vorgeschlagen werden oder eintreten, anhand der Kriterien aus 6.1.2. Die Ergebnisse aufbewahren.
- Abschnitt 8.3. Den Behandlungsplan umsetzen. Die Ergebnisse aufbewahren.
Alle vier Abschnitte verlangen zudem dokumentierte Information: Aufzeichnungen, kein Format. Eine Tabellenkalkulation funktioniert ebenso wie ein GRC-Tool. Eine assetbasierte Methode ist nicht vorgeschrieben; ISO/IEC 27005:2022, die Leitfadennorm, stellt ereignisbasierte und assetbasierte Ansätze einander gegenüber. Und das Register steht nicht für sich allein. Seine Controls müssen mit Ihrem Anwendungsbereich und Ihrer Erklärung zur Anwendbarkeit übereinstimmen, und Abschnitt 9.3.2 macht die Ergebnisse der Risikobeurteilung und den Stand der Risikobehandlung zu einer Eingabe für die Managementbewertung.
Was muss ein Risikoregister nach ISO 27001 enthalten?
Die Abschnitte legen das Minimum fest. Die Praxis ergänzt Felder, die das Register nutzbar machen; die Vorlage kennzeichnet, was woher kommt.
Risikoregister-Vorlage nach ISO 27001
RISIKOREGISTER NACH ISO 27001: EINE ZEILE PRO RISIKO
Spalte Inhalt Grundlage
------------------- -------------------------------------------- ---------------
ID R-01, R-02 usw., nie wiederverwendet Praxis
Risikoszenario Ursache, Ereignis und Folge in einem Satz 6.1.2 c)
Schutzziele Vertraulichkeit, Integrität, Verfügbarkeit 6.1.2 c)
Assets, Dienste Beteiligte Systeme, Daten oder Prozesse Praxis
Risikoeigentümer Rolle mit Befugnis zur Risikoakzeptanz 6.1.2 c)
Bestehende Controls Was das Risiko bereits senkt Praxis
Wahrscheinlichkeit 1 bis 5, laut Methodenseite 6.1.2 d)
Folge 1 bis 5, laut Methodenseite 6.1.2 d)
Risikoniveau Wahrscheinlichkeit x Folge 6.1.2 d)
Priorität Niveau im Vergleich zur Akzeptanzschwelle 6.1.2 e)
Behandlungsoption Mindern, vermeiden, übertragen, akzeptieren 6.1.3 a)
Controls Verweise auf Anhang A, wie in der SoA 6.1.3 b) bis d)
Maßnahmen Was getan wird 6.1.3 e)
Zuständig, Frist Wer, und bis wann 6.1.3 e)
Wirksamkeitstest Woran Sie erkennen, dass das Control wirkt Praxis
Restniveau Wahrscheinlichkeit x Folge nach Behandlung 6.1.3 f)
Akzeptanz Name des Eigentümers, Datum und Begründung 6.1.3 f)
Status, Nachweis Offen, erledigt, neu geplant, Link zum Beleg 8.3
Zuletzt geprüft Datum letzter echter Prüfung oder Änderung 8.2
METHODENSEITE (BEISPIEL, ZAHLEN ANPASSEN)
Stufe Wahrscheinlichkeit Folge
----- -------------------------- ---------------------------------------------
1 Seltener als alle 10 Jahre Unter 10.000 €, kein Kunde merkt es
2 Alle 3 bis 10 Jahre 10.000 bis 50.000 €, Stunden an Störung
3 Alle 1 bis 3 Jahre 50.000 bis 250.000 € oder ein Tag Ausfall
4 Etwa einmal pro Jahr 250.000 € bis 1 Mio. €, Kunden betroffen
5 Mehrmals pro Jahr Über 1 Mio. € oder Aufsichtsbehörde beteiligt
Akzeptanzschwelle: Ein Niveau von 8 oder darunter darf der Risikoeigentümer
akzeptieren. Über 8: behandeln, oder nur mit Freigabe der obersten Leitung
und schriftlicher Begründung akzeptieren.
BEISPIELZEILE
ID R-07
Risikoszenario Ein anderswo geleaktes Passwort wird für das Postfach
der Buchhaltung wiederverwendet, das keinen zweiten
Faktor hat, und eine Lieferantenzahlung wird umgeleitet.
Schutzziele Vertraulichkeit, Integrität
Risikoeigentümer CFO
Bestehende Controls Rückruf beim Lieferanten vor jeder Änderung der
Bankverbindung
Niveau Wahrscheinlichkeit 3 x Folge 4 = 12, über der Schwelle
Behandlung Mindern
Controls A.5.17, A.8.5
Maßnahmen MFA für jedes Postfach, Legacy-Anmeldung sperren
Zuständig, Frist IT-Leitung, 30. Juni 2026
Wirksamkeitstest Monatlicher Bericht: Postfächer ohne MFA = 0
Restniveau 2 x 4 = 8
Akzeptanz CFO, 14. Juli 2026. Es bleibt Phishing, das MFA
aushebelt, und der Rückruf gilt weiterhin. Weitere
Controls kosten mehr als das Schadenspotenzial.
Überprüfung in Q1 2027 oder bei einem Bankwechsel.
Status, Nachweis Erledigt, MFA-Bericht angehängt
Zuletzt geprüft 14. Juli 2026Übernehmen Sie die Spalten in eine Tabellenkalkulation und führen Sie die Methodenseite separat. Skalen und Akzeptanzschwelle sind Beispiele: Legen Sie Ihre eigenen fest, aber schriftlich.
Wie bewerten Sie Wahrscheinlichkeit und Folgen?
Jede Skala funktioniert, wenn sie definiert ist. Das Register, das wir am häufigsten sehen, hat etwa vierzig Zeilen, jede mit einer Wahrscheinlichkeit von eins bis fünf, einer Auswirkung von eins bis fünf, einem Produkt und einer Farbe. Die Farben sind überwiegend gelb.
Eine Fünf-mal-fünf-Matrix ist in Ordnung. Das Problem: In neun von zehn Fällen steht nirgends, was die Zahlen bedeuten. Was unterscheidet eine Wahrscheinlichkeit von zwei von einer drei? Wo liegt die Schwelle für die Auswirkung, in Euro, in Stunden Ausfall oder in offengelegten Datensätzen? Ohne das bewerten zwei Personen dasselbe Risiko unterschiedlich, und der Prozess liefert nicht die konsistenten und vergleichbaren Ergebnisse, die Abschnitt 6.1.2 verlangt.
Die Lösung ist die Methodenseite: einmal geschrieben, definiert sie jeden Skalenpunkt und die Kriterien für die Risikoakzeptanz. Sie kostet einen Nachmittag, und sie ist das Erste, was ein kompetenter Auditor nach dem Register selbst sehen will.
Wie dokumentieren Sie das Restrisiko und seine Akzeptanz?
Abschnitt 6.1.3 verlangt, dass die Risikoeigentümer die Restrisiken akzeptieren. Nach unserer Erfahrung ist das die Anforderung, die am häufigsten nicht erfüllt wird.
Register gehen meist auf eine von drei Arten damit um. Manche hören bei der Behandlung auf. Manche tragen nach der Behandlung einen niedrigeren Wert ein, ohne Erklärung. Manche schreiben „Risiko von der Geschäftsleitung akzeptiert“, ohne Namen und ohne Begründung.
Nichts davon hält einer genauen Prüfung stand. Was standhält, liest sich wie eine Entscheidung. Dieses Risiko bleibt nach diesen Maßnahmen auf diesem Niveau. Wir akzeptieren es, weil weitere Minderung mehr kostet als das Schadenspotenzial. Diese namentlich genannte Person hat es an diesem Datum akzeptiert. Wir überprüfen es zu diesem Termin. Vier Sätze pro akzeptiertem Risiko machen aus dem schwächsten Teil des Registers den Teil, der zeigt, dass Governance tatsächlich gelebt wird. Akzeptierte Risiken gehören zurück in die Managementbewertung, statt stillschweigend weitergereicht zu werden.
Was prüfen Auditoren in einem Risikoregister nach ISO 27001?
In Stufe 1 liest der Auditor Methode, Register, SoA und Behandlungsplan. In Stufe 2 prüft er, ob der Prozess tatsächlich läuft, wie in Audits der Stufe 1 und Stufe 2 beschrieben. In der Praxis sollten Sie mit Folgendem rechnen:
- Die Methode: Skalen, Akzeptanzkriterien, wer welches Niveau akzeptieren darf.
- Konsistenz: einige Risiken, neu bewertet nach Ihren eigenen Definitionen.
- Eigentümerschaft: Jedes Risiko hat einen Eigentümer, der es im Interview erklären kann.
- Nachvollziehbarkeit: ein Risiko als Stichprobe, verfolgt bis zu seinen Controls, zur SoA und zu Nachweisen, dass die Controls wirken.
- Freigabe: Freigabe des Plans und Akzeptanz des Restrisikos durch die Eigentümer, mit Namen und Datum.
- Änderungen: Neubeurteilung nach erheblichen Änderungen wie einem neuen System oder Lieferanten, wie Abschnitt 8.2 es verlangt, und in der Praxis nach Sicherheitsvorfällen.
- Fortschritt: Maßnahmen erledigt oder mit Begründung neu geplant, wie Abschnitt 8.3 es verlangt.
Die Datumsangaben verraten es
Ein Auditor kann ein Register in etwa neunzig Sekunden beurteilen, und das Feld, auf das er dabei schaut, sind nicht die Bewertungen. Es sind die Datumsangaben.
Ein Register, in dem jede Zeile in derselben Woche geändert wurde, drei Wochen vor dem Audit, erzählt eine vollständige Geschichte. Ebenso eines, in dem vierzig Zeilen dasselbe Überprüfungsdatum tragen, oder eines, in dem sich seit dem Anlegen der Datei kein Risiko verändert hat und keines geschlossen oder hinzugefügt wurde.
Ein Register, das tatsächlich benutzt wurde, sieht auf eine bestimmte Art unordentlich aus: Risiken, die zu verschiedenen Zeitpunkten hinzukamen, einige mit Begründung geschlossen, Behandlungstermine, die sich verschoben haben und neu geplant wurden, Zeilen, die nach einem Vorfall oder einem neuen Lieferanten überarbeitet wurden. Diese Textur lässt sich nicht in der Woche davor herstellen, und genau deshalb vertraut man ihr.
Warum fallen Risikoregister im Audit durch?
Fast jedes Unternehmen, das wir bewerten, hat ein Risikoregister. Fast keines hat eines, das seinen Zweck erfüllt. Es fehlt der Teil, der es zu einer Aufzeichnung von Entscheidungen macht statt zu einer Liste von Sorgen.
Es listet Lücken, keine Risiken
Die Zeilen lauten „keine Multi-Faktor-Authentifizierung“, „Backups nicht getestet“, „kein Asset-Inventar“. Das sind Lücken. Eine Lückenliste ist nützlich, aber sie ist ein anderes Dokument.
Ein Risiko ist ein Szenario. ISO/IEC 27005 definiert ein Risikoszenario als eine Abfolge oder Kombination von Ereignissen, die von der ursprünglichen Ursache zur unerwünschten Folge führt. In der Beispielzeile ist der fehlende zweite Faktor die Ursache und die umgeleitete Zahlung die Folge. Das Szenario ist das Risiko.
„Keine MFA“ können Sie nicht akzeptieren: Als Satz ergibt das keinen Sinn. Ein Szenario auf einem benannten Niveau können Sie akzeptieren und begründen. Auch die Abdeckung hängt davon ab: Zehn Controls können ein einziges Szenario adressieren, und ein Control kann sechs adressieren. Die Controls aus Anhang A, gruppiert für die Praxis, sind das Vokabular der Behandlung, nicht das des Risikos.
Drei Spalten fehlen
Nach unserer Erfahrung enthalten die meisten Register von KMU das Risiko, die Behandlung und die Maßnahmen. Es fehlt, was das Risiko betrifft, wem es gehört und woran man erkennen würde, dass die Behandlung wirkt. Ohne das Erste kann der Auditor nicht beurteilen, ob die Controls in Ihrer SoA die gefährdeten Systeme abdecken. Ohne Eigentümer kann niemand die Behandlung freigeben oder das Restrisiko akzeptieren. Ohne Wirksamkeitstest haben Sie eine Absicht aufgeschrieben, kein Control.
Es hat zu viele Zeilen
Wir sehen regelmäßig Register mit 120 Zeilen in Unternehmen mit vierzig Beschäftigten, und es sind immer die, die niemand liest. Ein Unternehmen dieser Größe hat vielleicht fünfzehn bis fünfundzwanzig echte Szenarien: kompromittierte Zugangsdaten, Ransomware auf gemeinsam genutztem Speicher, ein Lieferant mit Zugriff auf die Produktion, der Verlust einer Schlüsselperson, Zahlungsbetrug durch vorgetäuschte Identität. Ein kurzes Register, das vierteljährlich überprüft wird, schlägt ein langes, das jährlich überprüft wird.
Verlangt NIS2 ein Risikoregister?
Nicht unter diesem Namen. Artikel 21 Absatz 2 Buchstabe a der NIS2 verlangt mindestens „Konzepte in Bezug auf die Risikoanalyse und Sicherheit für Informationssysteme“.
Für die digitalen Anbieter, die unter die Durchführungsverordnung (EU) 2024/2690 fallen, ist Nummer 2.1 des Anhangs konkret. Sie müssen Risikobewertungen durchführen und dokumentieren sowie einen Risikobehandlungsplan festlegen, umsetzen und überwachen. Sie müssen bestimmen, wer jede Maßnahme bis wann umsetzt, und die Gründe für das Eingehen der Restrisiken „umfassend erläutern“. Ergebnisse und Plan sind in geplanten Abständen, mindestens jährlich, sowie nach erheblichen Änderungen oder erheblichen Sicherheitsvorfällen zu überprüfen.
Die technische Umsetzungsanleitung der ENISA vom Juni 2025 hat empfehlenden Charakter. Sie nennt sieben Punkte, die ein Behandlungsplan mindestens enthalten sollte: das Risiko und seine Auswirkung, die Behandlungsoption, die Assets, die Maßnahmen, wie die Wirksamkeit bewertet wird, Zeitpläne und verantwortliche Rollen. Die Vorlage enthält alle sieben, sodass ein Register beidem dienen kann. Mehr dazu in den zehn NIS2-Maßnahmen aus Artikel 21.
Die technische Realität: Ein Register dokumentiert Entscheidungen, es erkennt nichts
Alles oben Genannte macht das Register belastbar. Nichts davon macht das Unternehmen sicherer.
Ein Register dokumentiert Entscheidungen über Zustände, die als wahr angenommen werden. Es besagt, dass aus dem Internet erreichbare Dienste innerhalb von dreißig Tagen gepatcht werden. Es sagt Ihnen nicht, dass einer davon neunzig Tage im Rückstand ist, dass ein Lieferant nach Vertragsende seinen Zugang behalten hat oder dass das „getestete“ Backup zuletzt im März wiederhergestellt wurde.
Die Norm lässt das offen. Abschnitt 8.3 verlangt, den Plan umzusetzen und die Ergebnisse aufzubewahren; er sagt nicht, woher Sie wissen, dass die Controls noch laufen, wenn kein Auditor da ist. Um diese Lücke zu schließen, müssen die Annahmen des Registers laufend geprüft werden: die Asset-Liste aus dem abgeleitet, was tatsächlich läuft, der Patch-Stand gemessen statt behauptet, Lieferantenzugänge mit den Verträgen abgeglichen, Wiederherstellungen verifiziert statt nur eingeplant. Die Wirksamkeitsspalte füllt sich dann von selbst.
So arbeitet die CloudSoul-Plattform: automatisierte Prüfungen Ihrer Systeme, wobei ein Mensch die Ausnahmen bewertet. Ein unabhängiges Sicherheitsaudit liefert die Szenarioliste und den aktuellen Stand in einem Zug, und das vollständige Programm steht auf der ISO-27001-Seite.
Checkliste für das Risikoregister nach ISO 27001
Schreiben Sie das Register nicht neu. Arbeiten Sie das vorhandene durch.
- Schreiben Sie eine Seite, die die Skalen und die Risikoakzeptanzkriterien definiert.
- Formulieren Sie Lückenzeilen als Szenarien mit einer Ursache und einer Folge um.
- Geben Sie jedem Risiko einen Eigentümer mit der Befugnis, es zu akzeptieren.
- Verweisen Sie bei jeder Behandlung auf die Controls aus Anhang A und prüfen Sie, ob sie zur SoA passen.
- Ergänzen Sie jede Behandlung um einen Wirksamkeitstest, und sei es „die vierteljährliche Überprüfung der Zugriffsrechte zeigt keine verwaisten Konten“.
- Dokumentieren Sie jede Akzeptanz eines Restrisikos mit Namen, Datum und Begründung.
- Beurteilen Sie die Risiken in geplanten Abständen und nach erheblichen Änderungen neu.
- Bringen Sie die Ergebnisse und den Stand der Behandlung in die Managementbewertung ein.
Quellen
- ISO/IEC 27001:2022, Informationssicherheitsmanagementsysteme: Anforderungen, Abschnitte 6.1.2, 6.1.3, 8.2, 8.3 und 9.3.2, ISO.
- ISO/IEC 27005:2022, Leitfaden zur Handhabung von Informationssicherheitsrisiken, Abschnitt 3.1.4, ISO.
- Richtlinie (EU) 2022/2555 (NIS2), Artikel 21 Absatz 2 Buchstabe a, EUR-Lex.
- Durchführungsverordnung (EU) 2024/2690 der Kommission, Anhang, Nummern 2.1.1 bis 2.1.4, EUR-Lex.
- ENISA, NIS2 Technical Implementation Guidance, Version 1.0, Juni 2025, ENISA.
Häufige Fragen
Was muss ein Risikoregister nach ISO 27001 enthalten?
Jedes Risiko, seinen Risikoeigentümer, seine wahrscheinlichen Folgen und seine Wahrscheinlichkeit, sein Niveau im Vergleich zu Ihren Risikokriterien, die gewählte Behandlung sowie die Freigabe des Risikobehandlungsplans und die Akzeptanz des Restrisikos durch den Risikoeigentümer. In der Praxis kommen die verwendeten Controls aus Anhang A, Termine für die Maßnahmen, ein Wirksamkeitstest und ein Überprüfungsdatum hinzu.
Ist ein Risikoregister für ISO 27001 Pflicht?
ISO 27001 schreibt kein Dokument namens Risikoregister vor. Die Norm verlangt dokumentierte Information über die Prozesse der Risikobeurteilung und der Risikobehandlung und über deren Ergebnisse, und ein Register ist der übliche Weg, sie zu führen.
Wer akzeptiert das Restrisiko nach ISO 27001?
Der Risikoeigentümer. Abschnitt 6.1.3 verlangt, dass die Organisation die Freigabe des Risikobehandlungsplans und die Akzeptanz der verbleibenden Informationssicherheitsrisiken durch die Risikoeigentümer einholt.
Wie oft muss die Risikobeurteilung nach ISO 27001 aktualisiert werden?
Abschnitt 8.2 verlangt Risikobeurteilungen in geplanten Abständen oder wenn erhebliche Änderungen vorgeschlagen werden oder eintreten. Sinnvoll ist eine vierteljährliche Überprüfung des Registers und mindestens einmal im Jahr eine vollständige Neubeurteilung.
Was prüfen Auditoren in einem Risikoregister?
In der Praxis: ob die Bewertungen Ihren schriftlichen Kriterien folgen, ob jedes Risiko einen Eigentümer hat, der seine Behandlung freigegeben und das Restrisiko akzeptiert hat, ob die Controls zur Erklärung zur Anwendbarkeit passen und ob die Datumsangaben zeigen, dass das Register tatsächlich genutzt wird.
