ISO 27001 Risikoregister: Aufbau und Beispieleinträge
Ein ISO 27001 Risikoregister ist die dokumentierte Information aus dem Risikobeurteilungsprozess, den Abschnitt 6.1.2 verlangt: Risiken für die Vertraulichkeit, Integrität und Verfügbarkeit von Informationen im Geltungsbereich deines ISMS, jedes mit einem namentlich benannten Risikoeigentümer, einer analysierten Auswirkung und Eintrittswahrscheinlichkeit sowie einer Bewertung anhand deiner eigenen Risikokriterien. Die Spalten, auf die es ankommt, sind die, die der Standard impliziert: Risikobeschreibung mit Bezug zu einem Wert und einer Bedrohung, Eigentümer, Auswirkung, Eintrittswahrscheinlichkeit, resultierendes Risikoniveau, Behandlungsoption, ausgewählte Maßnahmen und das Restrisiko, das der Eigentümer akzeptiert hat. Zehn konkrete Einträge, die du wirklich überprüfst, schlagen hundert generische Zeilen aus einem Download.
Ein ISO 27001 Risikoregister ist die dokumentierte Information aus dem Risikobeurteilungsprozess, den Abschnitt 6.1.2 verlangt. Es hält Risiken für die Vertraulichkeit, Integrität und Verfügbarkeit von Informationen im Geltungsbereich deines ISMS fest – jedes mit einem namentlich benannten Eigentümer, einer analysierten Auswirkung und Eintrittswahrscheinlichkeit sowie einer Bewertung anhand von Risikokriterien, die du vorab festgelegt hast.
Wenn du zuerst die allgemeine Variante des Konzepts ohne ISO-Bezug willst: Wir haben eine Einführung dazu, was ein Risikoregister ist und warum jedes wachsende Unternehmen davon profitiert. Dieser Artikel ist enger gefasst: die Struktur, die ein Zertifizierungsaudit übersteht, und fünf ausgearbeitete Einträge, die du übernehmen kannst.
Was Abschnitt 6.1.2 tatsächlich fordert
Der Standard schreibt kein Format vor, aber er schreibt einen Prozess vor – und der Prozess impliziert die Spalten. Abschnitt 6.1.2 verlangt, dass du einen Risikobeurteilungsprozess festlegst und anwendest, der:
- Risikokriterien festlegt und aufrechterhält, einschließlich der Risikoakzeptanzkriterien und der Kriterien für die Durchführung von Beurteilungen. Entscheide, was „hoch" bedeutet und womit du leben kannst, bevor du zu bewerten anfängst, nicht danach.
- Konsistente, valide und vergleichbare Ergebnisse liefert, wenn er wiederholt wird. Zwei Personen, die dasselbe Risiko beurteilen, sollten ungefähr beim selben Ergebnis landen, und die diesjährige Beurteilung sollte mit der letztjährigen vergleichbar sein.
- Risiken identifiziert, die mit dem Verlust der Vertraulichkeit, Integrität und Verfügbarkeit von Informationen im Geltungsbereich verbunden sind.
- Risikoeigentümer identifiziert – benannte Personen, keine Abteilungen.
- Risiken analysiert – realistische Auswirkungen und Eintrittswahrscheinlichkeiten einschätzt und das resultierende Risikoniveau bestimmt.
- Risiken bewertet – sie mit deinen Kriterien vergleicht und für die Behandlung priorisiert.
Abschnitt 6.1.2 verlangt außerdem, dass du dokumentierte Information über den Prozess aufbewahrst. Das Register ist der Weg, über den die meisten Organisationen das erfüllen.
Der minimale Spaltensatz
Jede Spalte unten bildet etwas ab, das der Standard verlangt. Wenn eine Spalte in deiner Vorlage das nicht tut, ist sie Dekoration – und Dekoration macht aus einem Register eine lästige Pflicht, die niemand pflegt.
| Spalte | Warum es sie gibt |
|---|---|
| ID | Eine stabile Referenz, auf die Behandlungspläne und Auditfeststellungen zeigen können |
| Risikobeschreibung | Wert + Bedrohung + Auswirkung, in einem konkreten Satz |
| Betroffener Wert oder Prozess | Verbindet das Risiko mit deinem Inventar der Werte |
| VIV-Auswirkung | Welche der drei – Vertraulichkeit, Integrität, Verfügbarkeit – auf dem Spiel steht |
| Risikoeigentümer | Abschnitt 6.1.2 c) 2 – eine benannte Person, die tatsächlich entscheiden kann |
| Auswirkung | Analysierte Auswirkung, bewertet anhand deiner Kriterien |
| Eintrittswahrscheinlichkeit | Realistische Wahrscheinlichkeit, bewertet anhand deiner Kriterien |
| Risikoniveau | Das resultierende Niveau, bewertet gegen die Akzeptanzkriterien |
| Behandlungsoption | Verringern, akzeptieren, vermeiden oder teilen |
| Ausgewählte Maßnahmen | Die Maßnahmen, die das Risiko behandeln, mit Querverweis auf deine SoA |
| Restrisiko | Das Niveau nach der Behandlung – und ob der Eigentümer es akzeptiert hat |
| Prüfdatum | Wann zuletzt draufgeschaut wurde, damit Veralten sichtbar wird |
Fünf ausgearbeitete Einträge
Diese sind für ein Cloud-Startup geschrieben. Die Bewertung nutzt eine einfache Skala von 1 bis 5 für Auswirkung und Eintrittswahrscheinlichkeit, wobei das Risikoniveau das Produkt beider ist – für ein kleines Team mehr als ausreichend. Dem Standard ist wichtig, dass deine Methode konsistent ist, nicht dass sie ausgefeilt ist.
R-01 — Ausgeschiedene Mitarbeiterin behält SaaS-Zugang
Beschreibung: Eine Mitarbeiterin verlässt das Unternehmen, und der Zugang zu einem SaaS-Tool außerhalb des SSO wird nicht entzogen, sodass weiterhin Zugriff auf Kundendaten besteht. Wert: Kundensupport-Plattform. VIV: Vertraulichkeit. Eigentümer: Head of Operations. Auswirkung 4, Eintrittswahrscheinlichkeit 3, Niveau 12. Behandlung: Verringern – Offboarding-Checkliste, die Nicht-SSO-Tools abdeckt, plus quartalsweise Überprüfungen der Zugriffsrechte. Restrisiko: 4, akzeptiert.
R-02 — Ausfall einer Cloud-Region überschreitet das Wiederherstellungsziel
Beschreibung: Ein länger andauernder Ausfall einer Availability Zone beim Hosting-Anbieter legt die Plattform über die in Kundenverträgen zugesagte Wiederherstellungszeit hinaus lahm. Wert: Produktionsplattform. VIV: Verfügbarkeit. Eigentümer: CTO. Auswirkung 4, Eintrittswahrscheinlichkeit 2, Niveau 8. Behandlung: Verringern – Multi-AZ-Deployment, dokumentiertes Wiederherstellungs-Runbook, jährlich getestet. Restrisiko: 4, akzeptiert.
R-03 — Extremwetter stört einen kritischen Lieferanten
Beschreibung: Überschwemmungen oder hitzebedingte Belastung des Stromnetzes am Standort eines Lieferanten unterbrechen einen Dienst, von dem die Plattform abhängt. Wert: vom Lieferanten erbrachter Dienst. VIV: Verfügbarkeit. Eigentümer: CTO. Auswirkung 3, Eintrittswahrscheinlichkeit 2, Niveau 6. Behandlung: Akzeptieren, mit Überwachung – Kontinuitätszusagen des Lieferanten werden jährlich überprüft. Lohnt sich ausdrücklich aufzunehmen, seit die Änderung von 2024 Klimaaspekte in die Abschnitte 4.1 und 4.2 gebracht hat – siehe die Änderung, von der dir niemand erzählt hat. Restrisiko: 6, akzeptiert.
R-04 — Secrets landen in der Versionsverwaltung
Beschreibung: API-Schlüssel oder Zugangsdaten werden in ein Repository committet und sind für jeden mit Repo-Zugriff einsehbar – oder öffentlich, falls das Repo je geöffnet wird. Wert: Quellcode-Repositories. VIV: Vertraulichkeit. Eigentümer: Engineering Lead. Auswirkung 5, Eintrittswahrscheinlichkeit 3, Niveau 15. Behandlung: Verringern – automatisches Secret-Scanning in der CI, verwalteter Secret Store, Rotationsverfahren. Siehe Maßnahmen für sichere Entwicklung. Restrisiko: 5, akzeptiert.
R-05 — Abhängigkeit von einer einzelnen Person beim Produktions-Deployment
Beschreibung: Nur ein Entwickler hat das Wissen und die Zugriffsrechte, um die Produktion auszurollen und wiederherzustellen – das erzeugt ein Verfügbarkeitsrisiko, wenn er nicht erreichbar ist. Wert: Deployment-Pipeline. VIV: Verfügbarkeit. Eigentümer: CTO. Auswirkung 4, Eintrittswahrscheinlichkeit 3, Niveau 12. Behandlung: Verringern – dokumentierte Runbooks, eine zweite eingearbeitete Person, Break-Glass-Zugriffsverfahren. Restrisiko: 6, akzeptiert.
Ready to Streamline Your Compliance?
Discover how AuditBadger can simplify your compliance management process.
Risikoeigentümer sind Personen, keine Abteilungen
„IT" kann kein Risiko akzeptieren. „Engineering" kann keinen Behandlungsplan genehmigen. Abschnitt 6.1.2 verlangt von dir, Risikoeigentümer zu benennen, weil Abschnitt 6.1.3 später fordert, dass genau diese Eigentümer den Risikobehandlungsplan genehmigen und die Restrisiken akzeptieren – und das kann nur ein Mensch.
In einem kleinen Unternehmen tauchen dieselben zwei oder drei Namen immer wieder auf, und das ist in Ordnung. Entscheidend ist, dass der benannte Eigentümer die Befugnis hat, eine Lösung zu finanzieren – oder zu akzeptieren, dass es ohne sie weitergeht. Wenn dein Register einen Eigentümer aufführt, der beides nicht kann, ist der Eintrag Dekoration.
Wie das Register in die SoA einfließt
Das Register ist nicht das Ende der Kette. Nach Abschnitt 6.1.3 nimmst du die bewerteten Risiken und:
- Wählst Behandlungsoptionen aus – verringern, akzeptieren, vermeiden oder teilen.
- Bestimmst die Maßnahmen, die zur Umsetzung dieser Optionen nötig sind.
- Vergleichst deine bestimmten Maßnahmen mit Anhang A, um zu prüfen, dass keine notwendige Maßnahme übersehen wurde. Anhang A ist eine Gegenprobe, keine Einkaufsliste.
- Erstellst eine Erklärung zur Anwendbarkeit, die festhält, welche Maßnahmen zutreffen, warum, und ob sie umgesetzt sind.
- Formulierst einen Risikobehandlungsplan und holst die Genehmigung des Plans durch die Risikoeigentümer sowie deren Akzeptanz der Restrisiken ein.
Ein Auditor verfolgt diese Kette in beide Richtungen. Er greift sich eine in deiner SoA als „anwendbar" markierte Maßnahme heraus und fragt, welches Risiko sie ausgelöst hat. Dann greift er sich ein hoch bewertetes Risiko aus deinem Register und fragt, welche Maßnahmen es behandeln. Ein Register, das nicht zur SoA passt, gehört zu den unangenehmeren Feststellungen, weil es nahelegt, dass die beiden Dokumente unabhängig voneinander entstanden sind – und genau das ist meistens passiert.
Die Anti-Patterns
- Der Hundert-Zeilen-Download. Eine generische Vorlage voller Risiken, die nichts mit deinem Geschäft zu tun haben. Sie sieht gründlich aus und lässt sich miserabel überprüfen, weil niemand irgendetwas davon wiedererkennt.
- Risiken als Kategorien formuliert. „Cyberrisiko" ist kein Risiko. „Kundendaten werden über ein kompromittiertes Admin-Konto abgezogen" schon.
- Bewertungstheater. Ausgeklügelte Formeln ohne dokumentierte Kriterien. Der Standard will Konsistenz und Vergleichbarkeit, und die liefert eine einfache, aufgeschriebene Skala besser als ein unerklärter Algorithmus.
- Kein Restrisiko. Wenn du nie festhältst, was nach der Behandlung übrig bleibt, hat der Eigentümer nichts zu akzeptieren – und Abschnitt 6.1.3 verlangt genau das von ihm.
- Das eingefrorene Register. Dieselben zwölf Zeilen, dieselben Bewertungen, dieselben Daten, Jahr für Jahr. Das ist die mit Abstand häufigste Feststellung bei Überwachungsaudits, weil sie auf einen Blick sichtbar ist.
Das Fazit
Bau das Register um das herum, was Abschnitt 6.1.2 verlangt: konkrete Risiken mit Bezug zu echten Werten, benannte Eigentümer mit Befugnis, Kriterien, die du vor der Bewertung aufgeschrieben hast, und ein Restrisiko, das wirklich jemand akzeptiert hat. Dann überprüfe es in einem festen Rhythmus und lass die Überprüfung an den Daten sichtbar werden. Zehn Einträge, die du wirklich pflegst, bestehen ein Audit, das hundert geerbte Zeilen nicht bestehen.
Weiter geht's: Abschnitt 6 im Ganzen, Methoden der Risikobeurteilung, falls du dich noch für einen Ansatz entscheidest, oder schau dir an, wie die Risikobewertung in AuditBadger dafür sorgt, dass Register, Behandlungsplan und SoA aufeinander zeigen.
