Informationssicherheit · Technik und Geschäftsfolgen
Risikoakzeptanz in der Informationssicherheit begründen
Security beschreibt eine Schwachstelle, der Fachbereich benötigt den Betrieb, und die Entscheidung bleibt zwischen beiden hängen. Eine belastbare Risikoakzeptanz verbindet den technischen Zustand mit den möglichen Folgen für Informationen und Geschäftsprozesse.
Direkte Antwort
Was wird in der Informationssicherheit akzeptiert?
Akzeptiert wird ein konkret beschriebenes Informationssicherheitsrisiko innerhalb festgelegter Kriterien und Zuständigkeiten. Die Entscheidung betrifft mögliche Folgen für Vertraulichkeit, Integrität oder Verfügbarkeit. Sie sollte den technischen Befund, den Geschäftskontext, wirksame Schutzmaßnahmen und die verbleibende Unsicherheit zusammenführen.
Vom technischen Befund zum Risikoszenario
Eine fehlende Verschlüsselung, ein veraltetes Betriebssystem oder ein zu weit gefasstes Zugriffsrecht ist zunächst ein Befund. Für eine Geschäftsentscheidung braucht es die Verbindung zu einem plausiblen Ereignis: Wer könnte welche Information unter welchen Bedingungen lesen, verändern oder unzugänglich machen? Ohne diesen Zusammenhang bleiben Security und Fachbereich bei unterschiedlichen Vorstellungen von „hoch“ und „kritisch“.
Betrachten Sie den tatsächlichen Einsatz. Ein isolierter Laborrechner ohne produktive Informationen stellt andere Fragen als ein von außen erreichbares Kundenportal. Die technische Schwachstelle kann ähnlich sein, während Erreichbarkeit, Daten und Abhängigkeiten zu einer anderen Bewertung führen. Dokumentieren Sie den betrachteten Umfang so, dass eine spätere Erweiterung der Nutzung erkennbar wird.
Die drei Schutzziele aus Sicht des Fachbereichs
Ein Fall kann mehrere Schutzziele betreffen. Vermeiden Sie es, die Bewertung auf das zuerst genannte Problem zu reduzieren. Ein manipulierter Datenbestand kann beispielsweise zugleich die Wiederanlaufzeit erhöhen. Wenn mehrere Auswirkungen gemeinsam auftreten könnten, sollte dies in der Begründung sichtbar sein.
Bitten Sie den Fachbereich um nachvollziehbare Folgen statt um frei geschätzte Geldbeträge. Eine beschriebene Prozessunterbrechung mit begründeter Dauer kann hilfreicher sein als eine scheinbar präzise Schadenssumme ohne belastbare Grundlage.
| Schutzziel | Frage an den Fachbereich | Mögliche Folge |
|---|---|---|
| Vertraulichkeit | Wer dürfte die Informationen nicht erhalten? | Unbefugter Einblick in vertrauliche Angebote oder personenbezogene Unterlagen. |
| Integrität | Welche falsche Änderung würde eine Entscheidung beeinflussen? | Veränderte Zahlungsdaten, unzuverlässige Bestände oder fehlerhafte Freigaben. |
| Verfügbarkeit | Wie lange kann der Prozess ohne die Information arbeiten? | Unterbrochene Auftragsbearbeitung, manuelle Ersatzarbeit oder verzögerte Lieferung. |
Wer liefert welche Teile der Entscheidungsgrundlage?
Der Systemverantwortliche kennt Architektur, Betriebszustand und geplante Änderungen. Security prüft Angriffsmöglichkeiten, Schutzwirkung und die Anwendung des Risikomodells. Der Fachbereich erklärt Abhängigkeiten und Auswirkungen. Der Risikoeigentümer führt diese Sichtweisen innerhalb seines Mandats zu einer Entscheidung zusammen. Bei Bedarf kommen Datenschutz, Einkauf oder weitere Fachstellen hinzu.
Diese Zusammenarbeit funktioniert nur, wenn offene Fragen sichtbar bleiben. Eine fehlende Information über exportierte Daten darf nicht stillschweigend als unkritischer Umfang behandelt werden. Dokumentieren Sie Annahmen mit Verantwortlichem und Klärungstermin. Ist eine Unsicherheit entscheidend, sollte der Fall zunächst zur Ergänzung zurückgehen, statt aus Zeitdruck eine vermeintlich vollständige Bewertung zu bestätigen.
Eine tragbare Entscheidung vorbereiten
Geschäftlichen Bedarf eingrenzen
Ermitteln Sie, welcher Betrieb wirklich erforderlich ist. Eine begrenzte Nutzung durch einen kleinen Personenkreis kann eine andere Option sein als die unveränderte Fortsetzung für die gesamte Organisation.
Behandlungsalternativen vergleichen
Beschreiben Sie technische Behebung, Ersatzverfahren oder Einschränkung des Prozesses. Bewerten Sie deren Wirkung und Umsetzbarkeit. Bereits getätigte Investitionen sind kein Nachweis dafür, dass die Fortsetzung vertretbar ist.
Restbelastung und Abhängigkeiten erklären
Halten Sie fest, was die Schutzmaßnahmen tatsächlich reduzieren und welche Folgen bestehen bleiben. Berücksichtigen Sie gemeinsame Abhängigkeiten, etwa mehrere Verfahren, die denselben unsicheren Zugang verwenden.
Bedingungen und Überwachung vereinbaren
Verknüpfen Sie die Freigabe mit überprüfbaren Bedingungen. Bestimmen Sie, wer deren Einhaltung kontrolliert und welche Änderung eine neue Entscheidung verlangt. Zuständigkeit und Laufzeit gehören in dieselbe Akte.
Fiktives Praxisbeispiel
Ein Lieferantenportal unterstützt noch keine Mehrfaktor-Authentisierung
Ein fiktives Einkaufsteam benötigt für zwei Monate den Zugang zu einem Lieferantenportal. Die Plattform unterstützt für diese Konten vorerst nur Passwörter. Im Portal liegen Bestellinformationen; Änderungen an Zahlungsdaten wären besonders folgenreich.
- Risikoszenario
- Ein kompromittiertes Konto könnte Bestellungen einsehen oder manipulieren. Der Fachbereich prüft deshalb, welche Aktionen das Konto überhaupt ausführen muss.
- Begründung
- Offene Lieferungen sollen weiter bearbeitet werden. Das Team prüft als Alternative eine manuelle Abwicklung und begrenzt die Portalnutzung auf erforderliche Vorgänge.
- Maßnahmen
- Individuelle Konten, eingeschränkte Rechte und unabhängige Bestätigung sensibler Änderungen verringern die Folgen. Die fehlende zweite Anmeldekomponente bleibt ein dokumentierter Schwachpunkt.
- Entscheidung
- Die für den Einkaufsprozess zuständige Risikoeigentümerin genehmigt den begrenzten Umfang nach Security-Prüfung innerhalb ihres Mandats. Der Lieferantenverantwortliche hält die Umstellung nach.
- Laufzeit
- Die Freigabe endet nach zwei Monaten. Nach vier Wochen und bei Änderungen der Portalberechtigungen findet ein Review statt.
Das Team akzeptiert damit kein abstraktes „MFA-Risiko“. Die Entscheidung benennt Informationen, mögliche Handlungen, verbleibende Folgen und Bedingungen des Betriebs.
Technische und geschäftliche Sicht in einer Fallakte
Abweichwerk kann die Informationen zusammenführen, die sonst in technischen Tickets, E-Mails des Fachbereichs und Freigabelisten verteilt sind. Betroffene Objekte, Anforderungen, Bewertung und Maßnahmen stehen im Zusammenhang mit der Entscheidung.
Für den Pilot eignet sich ein Fall, in dem bisher mehrere Beteiligte unterschiedliche Unterlagen pflegen. Prüfen Sie, ob die gemeinsame Akte die fachliche Abstimmung erleichtert. Abweichwerk unterstützt den Ausnahmeprozess; die Verantwortung für die Einschätzung und Übernahme des Risikos bleibt bei der Organisation.
Den Abweichwerk-Workflow ansehenHäufige Fragen: Risikoakzeptanz Informationssicherheit
Reicht ein technischer Schweregrad für die Akzeptanz?
Ein technischer Schweregrad kann ein wichtiger Eingangswert sein. Er erklärt jedoch nicht automatisch die konkreten Geschäftsfolgen, vorhandene Schutzmaßnahmen oder den betrachteten Betrieb. Ergänzen Sie diese Informationen, bevor eine zuständige Person über das Risiko entscheidet.
Sollte der CISO jedes Risiko persönlich übernehmen?
Das hängt von den festgelegten Mandaten ab. Die Rolle kann fachlich prüfen und eskalieren, ohne jeden betroffenen Geschäftsprozess zu verantworten. Entscheidend ist, dass die genehmigende Person die Befugnis und den Überblick für den beschriebenen Umfang besitzt.
Wie gehe ich mit unklaren Schadenshöhen um?
Beschreiben Sie plausible Folgen und die zugrunde liegenden Annahmen. Nutzen Sie die qualitativen Stufen Ihres Risikomodells, wenn belastbare Zahlen fehlen. Unsicherheit sollte erkennbar bleiben und bei Bedarf durch zusätzliche Informationen oder konservative Bedingungen berücksichtigt werden.
Kann dieselbe Akzeptanz für weitere Systeme gelten?
Nur wenn diese Systeme vom dokumentierten Geltungsbereich und der Bewertung erfasst sind. Ähnliche Technik allein genügt nicht. Andere Daten, Zugriffe oder Prozessabhängigkeiten können das Risiko verändern und eine neue Prüfung oder erweiterte Entscheidung erforderlich machen.
Risikoentscheidungen über Teamgrenzen hinweg dokumentieren
Prüfen Sie mit einem eigenen Fall, wie Abweichwerk Fachbereich, IT und Security im Pilot zusammenführt.