Wann ist ein ISMS sinnvoll?
Ein Informationssicherheits-Managementsystem ist selten Selbstzweck. Vier Auslöser erklären die meisten Vorhaben, und sie bestimmen den Zuschnitt stärker als jede Methodik.
| Auslöser | Was daraus für das ISMS folgt |
|---|---|
| Kunden- und Ausschreibungsanforderungen | Der Geltungsbereich muss die belieferten Standorte und Leistungen abdecken; ein Zertifikat wird zum Ziel |
| Regulatorische Pflichten (etwa NIS2, DORA, DSGVO) | Der Anwendungsbereich des Gesetzes gibt den Rahmen vor, Melde- und Nachweispflichten kommen hinzu |
| Lieferkettenanforderungen von Großkunden | Nachweisfähigkeit gegenüber Dritten steht im Vordergrund, oft ohne formale Zertifizierung |
| Ein Vorfall oder ein Beinahe-Vorfall | Die fehlende Steuerung ist sichtbar geworden; Priorität haben Vorfallbehandlung und Wiederanlauf |
Wer ohne einen dieser Auslöser startet, sollte die Frage nach dem Zweck vorher beantworten. Ein ISMS erzeugt dauerhaften Aufwand: Risikobewertungen, interne Audits, Managementbewertungen, Nachweispflege. Rechtfertigen lässt er sich nur, wenn er auf ein konkretes Ziel einzahlt.
Umgekehrt gibt es einen Punkt, ab dem informelle Sicherheitsarbeit nicht mehr trägt. Er ist erreicht, wenn niemand mehr vollständig sagen kann, welche Systeme personenbezogene oder geschäftskritische Daten verarbeiten, wenn Zugriffsrechte historisch gewachsen sind, wenn Maßnahmen zwar existieren, ihre Wirksamkeit aber nie überprüft wurde, oder wenn Kundenfragebögen regelmäßig Wochen an Recherche auslösen. Alle vier Symptome beschreiben dasselbe Defizit: Es gibt Sicherheit, aber keine Steuerung.
Eine Zertifizierung ist dabei eine eigene Entscheidung. Ein ISMS lässt sich vollständig betreiben, ohne es zertifizieren zu lassen; ein Zertifikat setzt umgekehrt immer ein tatsächlich betriebenes ISMS voraus. Legen Sie das Ziel früh fest: Eine geplante Zertifizierung beeinflusst die Dokumentationsanforderungen und den Zuschnitt des Geltungsbereichs.
Die Reihenfolge auf einen Blick
Die verbreitete Darstellung „in sieben Schritten zum ISMS“ ist als Merkhilfe brauchbar und als Projektplan unzureichend, weil sie verschweigt, warum die Reihenfolge feststeht. Entscheidend ist nicht die Nummerierung, sondern dass jeder Schritt das Ergebnis des vorherigen als Eingang braucht. Wo dieser Eingang fehlt, entsteht kein Zeitgewinn, sondern Arbeit, die später erneut anfällt. Nach derselben Logik ordnet die Checkliste zur ISMS-Einführung die ersten 90 Tage, von Auftrag und Rollen über Bestandsaufnahme und Risikobild bis zum Regelbetrieb.
| Schritt | Braucht als Eingang | Liefert | Was passiert, wenn man ihn überspringt |
|---|---|---|---|
| 1. Zweck und Ziel klären | Anlass (Kunde, Gesetz, Lieferkette, Vorfall) | Entscheidung über Zertifizierung ja/nein | Der Zuschnitt wird später zweimal geändert |
| 2. Geltungsbereich abgrenzen | Zweck, Organisations- und Standortstruktur | Dokumentierte Abgrenzung samt Schnittstellen | Jede spätere Aussage bezieht sich auf nichts Bestimmtes |
| 3. Werte und Assets erfassen | Geltungsbereich | Inventar mit Eigentümer, Schutzbedarf, Abhängigkeiten | Die Risikobewertung wird zur Meinungsumfrage |
| 4. Risiken bewerten und behandeln | Inventar, dokumentierte Kriterien | Risikoregister, Risikobehandlungsplan | Maßnahmen lassen sich im Audit nicht begründen |
| 5. Maßnahmen auswählen und umsetzen | Risikobehandlungsplan, Anhang A als Gegenprobe | Statement of Applicability, umgesetzte Maßnahmen | Der Anhang wird zur Checkliste, das ISMS austauschbar |
| 6. Vorgaben dokumentieren | Beschlossene Maßnahmen | Leitlinie, Richtlinien, Verfahren | Richtlinien beschreiben einen Zustand, den es nicht gibt |
| 7. Betrieb aufnehmen und schulen | Freigegebene Vorgaben | Aufzeichnungen aus dem Tagesgeschäft | Es fehlt der Zeitraum, über den Wirksamkeit sichtbar wird |
| 8. Wirksamkeit prüfen | Aufzeichnungen | Internes Audit, Managementbewertung, Korrekturmaßnahmen | Das System altert unbemerkt zwischen zwei Terminen |
Zwei Schritte lassen sich vorziehen, ohne die Logik zu brechen. Eine Gap-Analyse gegen die Norm ist schon nach Schritt 2 sinnvoll, weil sie den Umfang der Schritte 3 bis 6 schätzbar macht – sie ersetzt aber die Risikobewertung nicht, sondern priorisiert nur ihre Vorbereitung. Und die Sensibilisierung der Beschäftigten darf früh beginnen; sie ist die einzige Maßnahme, deren Wirkung Zeit braucht und die deshalb nicht auf den Nachweisbedarf warten sollte.
Wie legt man den Geltungsbereich fest?
Der Geltungsbereich ist der erste inhaltliche Schritt und die folgenreichste Einzelentscheidung. Er legt fest, worauf sich jede spätere Aussage bezieht: welche Risiken erhoben werden, welche Maßnahmen gelten, welche Nachweise entstehen und, falls zertifiziert wird, was auf der Urkunde steht.
Abgegrenzt wird entlang von vier Dimensionen: Organisation (welche Rechtseinheiten, Bereiche, Rollen), Standorte (welche Gebäude, Rechenzentren, Homeoffice-Regelungen), Prozesse und Leistungen (welche Produkte oder Dienstleistungen) sowie Informationen und Systeme (welche Datenkategorien und Anwendungen).
An den Schnittstellen entscheidet es sich. Ein Geltungsbereich, der eine Entwicklungsabteilung umfasst, aber die von ihr genutzte Cloud-Plattform, den externen IT-Dienstleister und die konzernweite Identitätsverwaltung ausklammert, ist nicht abgegrenzt, sondern unvollständig. Für jede Schnittstelle nach außen ist zu bestimmen, wer sie verantwortet, welche Anforderungen gelten und wie deren Einhaltung nachgewiesen wird. Ausgelagert werden kann die Leistung, nicht die Verantwortung.
Für den Einstieg gilt: eng beginnen, kontrolliert erweitern. Ein Geltungsbereich, der die gesamte Unternehmensgruppe in einem Schritt abdecken soll, scheitert im Mittelstand regelmäßig an der Verfügbarkeit von Fachbereichen. Ein zu enger Zuschnitt hat allerdings einen Preis: Kunden lesen die Urkunde genau, und ein Geltungsbereich, der die belieferte Leistung nicht enthält, hilft in der Lieferantenprüfung nicht.
Halten Sie die Abgrenzung schriftlich fest, einschließlich der Begründung für Ausschlüsse. Diese Begründung ist das erste, wonach ein Auditor fragt; gebraucht wird sie erneut, sobald der Geltungsbereich später erweitert wird.
Wie werden Assets und Verantwortlichkeiten erfasst?
Ohne Inventar ist jede Risikobewertung Spekulation. Der Aufbau des Asset-Verzeichnisses ist deshalb der erste größere Arbeitsblock und zugleich der, den Projekte am häufigsten unterschätzen.
Was ins Inventar gehört
Erfasst werden nicht nur Server und Endgeräte. Zum Bestand gehören auch Informationen und Datenkategorien, Anwendungen und Cloud-Dienste, Netze und Infrastruktur, physische Werte wie Gebäude und Archive, Dienstleister mit Zugang zu Systemen oder Daten sowie Wissen, das an einzelne Personen gebunden ist.
Ohne diese Angaben trägt kein Eintrag:
- Eigentümer. Eine benannte Person, keine Abteilung. Der Eigentümer entscheidet über Schutzbedarf, Zugriffe und die Behandlung von Risiken.
- Schutzbedarf. Eine Einstufung getrennt nach Vertraulichkeit, Integrität und Verfügbarkeit. Eine einzelne Gesamtnote verdeckt genau die Unterschiede, auf die es ankommt.
- Abhängigkeiten. Welche Prozesse hängen daran, worauf hängt es selbst: Betriebssystem, Hosting, Dienstleister, Schnittstellen.
- Aktualität. Ein Datum und ein Verfahren, das die Angaben bei Änderungen nachzieht.
Vorhandene Quellen nutzen
Der Aufwand lässt sich erheblich senken, wenn vorhandene Quellen genutzt werden: die Konfigurationsdatenbank der IT, die Lieferanten- und Vertragsübersicht, die Anlagenbuchhaltung und, bei personenbezogenen Daten, das Verzeichnis von Verarbeitungstätigkeiten nach Art. 30 DSGVO. Letzteres enthält Zwecke, Datenkategorien, Empfänger und Löschfristen und deckt sich in weiten Teilen mit dem, was das ISMS für informationsbezogene Assets braucht. Zwei getrennt gepflegte Verzeichnisse laufen erfahrungsgemäß innerhalb eines Jahres auseinander.
Ein Hinweis zur Granularität: Ein Verzeichnis mit tausenden Einzelgeräten ist nicht pflegbar. Bilden Sie Gruppen mit gleichem Schutzbedarf und gleichen Maßnahmen und führen Sie nur dort Einzelobjekte, wo sie sich tatsächlich unterscheiden.
Wie läuft der Risikomanagement-Prozess ab?
Das Risikoverfahren ist der Kern des ISMS. Es begründet, warum die Organisation gerade diese Maßnahmen betreibt – und ohne diese Begründung bleibt jede Maßnahmenliste eine Sammlung von Meinungen.
Kriterien und Akzeptanzschwelle
Vor der ersten Bewertung sind die Kriterien festzulegen und zu dokumentieren: die Skalen für Eintrittswahrscheinlichkeit und Auswirkung, was in die Auswirkung einfließt (finanziell, rechtlich, Reputation, Betrieb, Betroffenenrechte), wie sich daraus ein Risikowert ergibt und ab welchem Wert ein Risiko behandelt werden muss. Diese Akzeptanzschwelle ist eine Managemententscheidung, keine Fachentscheidung, und sie gehört schriftlich festgehalten.
Der Ablauf in fünf Schritten
Der Ablauf ist in allen gängigen Methodiken derselbe:
- Identifikation. Risiken werden je Asset oder Prozess aus Bedrohungen und Schwachstellen abgeleitet. Nützliche Quellen sind Vorfallhistorie, Auditfeststellungen, Lieferantenlisten und der Maßnahmenkatalog als Gegenprobe.
- Analyse und Bewertung. Einstufung nach den festgelegten Skalen, zunächst ohne, dann mit Berücksichtigung bereits vorhandener Maßnahmen. Die Unterscheidung zwischen Brutto- und Nettorisiko macht den Beitrag jeder Maßnahme sichtbar.
- Behandlung. Vier Optionen stehen zur Verfügung: vermindern, vermeiden, übertragen oder akzeptieren. Jede Entscheidung braucht einen benannten Risikoeigentümer, eine Begründung und eine Wiedervorlage.
- Risikobehandlungsplan. Die beschlossenen Maßnahmen mit Verantwortlichen, Terminen und Ressourcen. Er ist das Bindeglied zwischen Bewertung und Umsetzung.
- Überwachung und Wiederholung. Risiken werden in festem Turnus und zusätzlich bei Änderungen neu bewertet: bei neuen Systemen, neuen Dienstleistern, Umstrukturierungen und nach Vorfällen.
Zwei häufig übersehene Punkte
Erstens: Akzeptierte Risiken sind Entscheidungen der Leitung, nicht des Sicherheitsbeauftragten, und müssen von der Person freigegeben werden, die die Folgen trägt. Zweitens: Die Risikobewertung ist keine Einmalübung zum Projektstart. Ein Register, das seit einem Jahr unverändert ist, obwohl die Systemlandschaft sich geändert hat, ist der zuverlässigste Hinweis auf ein ISMS, das nur auf dem Papier existiert.
Maßnahmen auswählen
Maßnahmen folgen aus der Risikobehandlung, nicht umgekehrt. Diese Reihenfolge ist der wichtigste methodische Unterschied zwischen einem ISMS und einer Sicherheitscheckliste, und sie ist auch der Grund, warum Auditoren bei der Risikobewertung beginnen.
Anhang A als Gegenprobe
Anhang A der ISO/IEC 27001 dient dabei als Gegenprobe: Nach der Maßnahmenauswahl wird geprüft, ob eine notwendige Maßnahme übersehen wurde. Anhang A führt in der Fassung 2022 insgesamt 93 Referenzmaßnahmen in vier Themenfeldern.
| Themenfeld | Anzahl | Beispiele für Gegenstände |
|---|---|---|
| Organisatorisch | 37 | Richtlinien, Rollen, Lieferantensteuerung, Vorfallmanagement, Cloud-Nutzung |
| Personenbezogen | 8 | Eignungsüberprüfung, Sensibilisierung, Disziplinarverfahren, Fernarbeit |
| Physisch | 14 | Zutrittskontrolle, Sicherungsbereiche, Geräteschutz, Entsorgung |
| Technologisch | 34 | Zugriffsverwaltung, Kryptografie, Protokollierung, Schwachstellen, sichere Entwicklung |
Die Kurzbeschreibungen in Anhang A bestehen jeweils nur aus Titel und einem knappen Satz. Die ausführliche Darstellung mit Zweck und Umsetzungshinweisen steht in ISO/IEC 27002; die Norm ist damit das Arbeitsdokument für die Umsetzung, während Anhang A der normative Bezugsrahmen bleibt. ISO/IEC 27002 stellt keine Anforderungen an ein Managementsystem und ist nicht zertifizierbar.
Nicht jede der 93 Maßnahmen muss umgesetzt werden. Verpflichtend ist, jede zu prüfen und die Entscheidung über Anwendung oder Ausschluss nachvollziehbar zu begründen. Genau das leistet das Statement of Applicability, das die Norm in Abschnitt 6.1.3 d) als Ergebnis der Risikobehandlung verlangt. Aus ihm zieht ein Auditor seine Stichprobe.
Reihenfolge der Umsetzung
Bei der Priorisierung hat sich bewährt, statt der Reihenfolge des Anhangs Maßnahmen mit breiter Wirkung vorzuziehen: Zugriffsverwaltung, Protokollierung, Datensicherung und Wiederanlauf, Lieferantensteuerung, Sensibilisierung. Wer den Katalog von oben nach unten abarbeitet, kann im Audit nicht begründen, warum das ISMS gerade so aussieht.
Der zweite Weg: IT-Grundschutz
Anhang A ist nicht der einzige Maßnahmenvorrat. Der IT-Grundschutz des BSI beschreibt dieselbe Managementsystem-Logik in eigenen Dokumenten – BSI-Standard 200-1 für das Managementsystem selbst, 200-2 für die Vorgehensweise mit ihren Varianten Basis-, Kern- und Standard-Absicherung und 200-3 für die Risikoanalyse – und ergänzt sie um das IT-Grundschutz-Kompendium mit seinen Bausteinen. Der methodische Unterschied liegt im Freiheitsgrad: Der IT-Grundschutz nimmt einen Teil der Risikoanalyse dadurch vorweg, dass er je Baustein Anforderungen für einen normalen Schutzbedarf setzt; eine eigene Risikoanalyse nach 200-3 wird erst dort verlangt, wo der Schutzbedarf höher liegt oder kein passender Baustein existiert. Das senkt den Begründungsaufwand und erhöht den Dokumentationsaufwand. In der öffentlichen Verwaltung und bei deren Dienstleistern wird dieser Weg häufig ausdrücklich verlangt; er führt ebenfalls zu einem Zertifikat mit Bezug auf ISO/IEC 27001.
Welche Nachweise und Dokumente verlangt ein ISMS?
Die Norm verlangt „dokumentierte Information“, nicht einen bestimmten Umfang und kein bestimmtes Werkzeug. Der praktische Maßstab lautet: Alles, was für den Betrieb und den Nachweis der Wirksamkeit erforderlich ist, muss vorhanden, aktuell und auffindbar sein.
Vorgabedokumente und Aufzeichnungen
Es hilft, zwei Arten von Unterlagen zu unterscheiden. Vorgabedokumente beschreiben den Soll-Zustand: Leitlinie, Richtlinien, Verfahrensanweisungen, Geltungsbereich, Risikokriterien, Statement of Applicability. Aufzeichnungen belegen, dass tatsächlich gehandelt wurde: Protokolle, Freigaben, Auditberichte, Schulungsnachweise, Prüfergebnisse, Tickets, Zugriffsüberprüfungen.
Der zweite Typ ist der schwierigere. Vorgabedokumente lassen sich in wenigen Wochen erstellen; Aufzeichnungen entstehen nur im Betrieb, über Zeit. Wo sie eigens für ein Audit erzeugt werden, verschiebt sich der Aufwand lediglich auf das nächste Mal.
Zwei Prinzipien senken den Pflegeaufwand dauerhaft. Erstens: Nachweise sollten dort entstehen, wo ohnehin gearbeitet wird, also im Ticketsystem, im Freigabeworkflow, in der Protokollierung, statt in einer parallelen Nachweisablage. Zweitens: Was zählt, ist die Verknüpfung. Ein Risiko verweist auf die Maßnahme, die Maßnahme auf den SoA-Eintrag, der Eintrag auf den Nachweis und der Nachweis auf einen Verantwortlichen. Bricht diese Kette, ist der Nachweis vorhanden, aber nicht zuordenbar und damit für den Wirksamkeitsnachweis wertlos.
Für jedes Dokument gehören Version, Freigabe, Verantwortlicher und Prüfturnus festgehalten. Bei Aufzeichnungen kommt die Aufbewahrungsdauer hinzu, die sich mit datenschutzrechtlichen Löschpflichten abstimmen muss.
Wie betreibt man ein ISMS dauerhaft?
Ein ISMS ist zyklisch angelegt. Nach der Einführung tritt der Regelbetrieb an die Stelle des Projekts, und die Frage lautet nicht mehr „ist es aufgebaut“, sondern „wird es gesteuert“.
Diesen Betrieb tragen wiederkehrende Elemente:
- Messung der Wirksamkeit. Legen Sie je wesentlicher Maßnahme fest, woran sich ihre Wirkung zeigt, und werten Sie das regelmäßig aus. Ohne diesen Schritt bleibt die Verbesserung eine Behauptung.
- Internes Audit. Es prüft nach einem Programm den gesamten Geltungsbereich über einen Zyklus, durchgeführt von Personen, die den geprüften Bereich nicht selbst verantworten. Ein internes Audit ohne einzige Feststellung ist selbst eine Feststellung.
- Managementbewertung. Die oberste Leitung bewertet das System anhand von Auditergebnissen, Vorfällen, Kennzahlen, Status der Maßnahmen und Änderungen im Kontext – und trifft Entscheidungen über Ressourcen, Ziele und Verbesserungen. Ein Protokoll ohne Entscheidung erfüllt die Anforderung formal, nicht inhaltlich.
- Umgang mit Abweichungen. Jede Abweichung braucht Ursachenanalyse, Korrektur des Einzelfalls, Maßnahme gegen die Ursache und einen Wirksamkeitsnachweis. Wer nur das Symptom behebt, sieht dieselbe Feststellung im nächsten Zyklus wieder.
Hinzu kommen die anlassbezogenen Auslöser: neue Systeme und Dienstleister, Umstrukturierungen, Vorfälle, geänderte rechtliche Anforderungen. Für sie sollte definiert sein, wer das ISMS informiert und welche Schritte dann anlaufen; sonst altert das System zwischen zwei Turnusterminen unbemerkt.
Welche Rollen braucht ein ISMS?
Die Gesamtverantwortung liegt bei der obersten Leitung; die Norm formuliert das im Kapitel Führung ausdrücklich. Delegiert wird die Aufgabe, nicht die Verantwortung. Für regulierte Unternehmen kommt hinzu, dass das Gesetz dieselbe Verantwortung ausdrücklich der Geschäftsleitung zuweist: § 38 Absatz 1 BSIG verpflichtet die Geschäftsleitungen besonders wichtiger und wichtiger Einrichtungen, die Risikomanagementmaßnahmen umzusetzen und ihre Umsetzung zu überwachen. § 38 Absatz 2 knüpft daran eine Haftung gegenüber der eigenen Einrichtung nach den Regeln des jeweils anwendbaren Gesellschaftsrechts, und § 38 Absatz 3 verlangt von den Leitungsorganen selbst die regelmäßige Teilnahme an Schulungen.
| Rolle | Verantwortung | Typische Fehlbesetzung |
|---|---|---|
| Oberste Leitung | Leitlinie, Ziele, Ressourcen, Risikoakzeptanz, Managementbewertung | Beteiligung erschöpft sich in der Unterschrift unter die Leitlinie |
| Informationssicherheitsbeauftragter oder CISO | Steuerung des ISMS, Methodik, Berichterstattung, Koordination | Rolle ohne Zeitbudget, Weisungsbefugnis oder Zugang zur Leitung |
| Risikoeigentümer | Bewertung, Entscheidung über Behandlung, Akzeptanz von Restrisiken | Sammelzuweisung an eine Abteilung statt an eine Person |
| Asset-Eigentümer | Schutzbedarf, Zugriffe, Aktualität der Angaben | IT wird pauschal als Eigentümer aller Systeme geführt |
| Maßnahmenverantwortliche | Umsetzung und Betrieb einzelner Maßnahmen | Zuständigkeit ohne Ressourcen |
| Interne Auditoren | Unabhängige Prüfung der Wirksamkeit | Prüfung des eigenen Bereichs |
Zwei Konflikte sind aufzulösen. Der Sicherheitsbeauftragte sollte nicht zugleich für den IT-Betrieb verantwortlich sein, den er bewertet; wo sich das in kleinen Organisationen nicht vermeiden lässt, ist die Trennung durch Berichtswege an die Leitung und durch externe Prüfung abzufedern. Und interne Auditoren dürfen ihren eigenen Bereich nicht prüfen; in kleinen Organisationen ist das die eigentliche Hürde, lösbar durch gegenseitige Prüfung zwischen Bereichen oder durch externe Auditoren, die nicht zugleich zertifizieren. Warum kleine Organisationen Rollen zuschneiden sollten, statt Konzernstrukturen zu kopieren, begründet der Beitrag Compliance in kleinen Teams.
Datenschutz und Informationssicherheit bleiben getrennte Rollen mit klarer Schnittstelle. Der Datenschutzbeauftragte hat eine gesetzlich definierte Aufgabe und Unabhängigkeit; die technischen und organisatorischen Maßnahmen nach Art. 32 DSGVO überschneiden sich jedoch weitgehend mit den Maßnahmen des ISMS. Eine gemeinsame Erhebung von Assets, Risiken und Nachweisen erspart doppelte Arbeit, ohne die Rollen zu vermischen.
Wie sich Assets, Risiken, Maßnahmen und Nachweise in einer gemeinsamen Struktur verknüpfen lassen, sodass der Umsetzungsstand jederzeit belegbar bleibt, zeigt unsere Seite zur Informationssicherheit.
Wie Rizzqo diese Reihenfolge erzwingt
Der Leitfaden argumentiert für eine bestimmte Reihenfolge: Geltungsbereich, Werte, Risiken, dann Maßnahmen und Dokumente. Das Problem an einer empfohlenen Reihenfolge ist, dass unter Termindruck alle die Abkürzung nehmen und mit den Richtlinien beginnen. In Rizzqo ist die Reihenfolge nicht empfohlen, sondern in die Struktur eingebaut, weil jeder Schritt den vorherigen als Eingang braucht.
Der Geltungsbereich ist eine Menge von Objekten statt einer Textpassage: die primären Werte, also Informationen, Prozesse und Dienstleistungen, und die Systeme, Anwendungen, Standorte, Dienstleister und Personalfunktionen, die sie tragen. Erst mit dieser Verknüpfung existiert ein Schutzbedarf, denn er wird von den primären Werten an die unterstützenden Objekte vererbt, auch über mehrere Stufen. Und erst mit der Klassifizierung eines Objekts erscheinen daran die Anforderungen, die für seine Kategorie hinterlegt sind, aus ISO/IEC 27002, ISO/IEC 27001 oder einem weiteren Katalog.
Von dort läuft die Arbeit dorthin, wo sie hingehört. Jede Anforderung trägt einen Bearbeiter, wird am Objekt mit Begründung und Beleg beantwortet und unter Name und Zeitstempel abgeschlossen. Was offen bleibt, wird nicht ignoriert, sondern als Risikobewertung bewusst getragen, in Eintrittswahrscheinlichkeit und Schadenshöhe in Euro.