Die meisten IT-Risikoanalysen bestehen das Audit und verfehlen den Betrieb. Wer Risiken nur f\u00fcr den Nachweis dokumentiert, analysiert sie nicht dort, wo Incidents tats\u00e4chlich entstehen: bei Changes, Releases und Eingriffen in laufende IT-Systeme.<\/p>\n\n\n\n
Dieser Beitrag richtet sich an Verantwortliche f\u00fcr IT-Operations, Infrastruktur und Incident-\/Problem-Management und beantwortet eine Frage: Wie wird die IT-Risikoanalyse vom j\u00e4hrlichen Pflichtdokument zum wiederholbaren Denkprozess, der Ausf\u00e4lle und Major Incidents vermeidbar macht? Dazu ordnen wir Standards und Methoden ein \u2014 und zeigen mit der Potential Problem Analysis einen Prozess, der die Risikoanalyse in die Betriebsroutine holt.<\/p>\n\n\n\n
Eine IT-Risikoanalyse liefert erst dann Wert, wenn sie als wiederholbarer Denkprozess betrieben wird \u2014 nicht als j\u00e4hrliches Audit-Artefakt. Der Kern ist immer derselbe Dreischritt: Gef\u00e4hrdungen f\u00fcr die relevanten Zielobjekte identifizieren, Risiken nach Eintrittswahrscheinlichkeit und Schadensausma\u00df bewerten, \u00fcber die Risikobehandlung entscheiden.<\/p>\n\n\n\n
F\u00fcr die IT-Sicherheit hei\u00dft das: Bedrohungen und Schwachstellen werden systematisch den IT-Assets zugeordnet und gegen die Grundwerte Vertraulichkeit, Integrit\u00e4t und Verf\u00fcgbarkeit gepr\u00fcft. F\u00fcr den Betrieb hei\u00dft es: Die Analyse muss dort stattfinden, wo Risiken konkret werden \u2014 vor Changes, Migrationen, Releases und Wartungsfenstern, nicht nur in der j\u00e4hrlichen ISMS-Runde.<\/p>\n\n\n\n
Zwei Fehlbilder dominieren die Praxis in vielen Unternehmen. Das erste ist die reine Compliance-\u00dcbung: Risiken werden erfasst, bewertet, abgeheftet \u2014 und bis zum n\u00e4chsten Audit nicht wieder angefasst. Das zweite ist die Gleichsetzung von IT-Risiken mit Cyberangriffen: Bedrohungen von au\u00dfen sind nur eine Risikoklasse.<\/p>\n\n\n\n
Fehlkonfigurationen, misslungene Changes, ungepatchte Schwachstellen und Prozessl\u00fccken verursachen einen erheblichen Teil der realen Ausf\u00e4lle. Eine tragf\u00e4hige IT-Risikoanalyse deckt deshalb beides ab: die Informationssicherheit und die Betriebsstabilit\u00e4t der IT-Systeme.<\/p>\n\n\n\n
Ma\u00dfgeblich sind f\u00fcr Unternehmen im DACH-Raum zwei Rahmenwerke: der IT-Grundschutz des BSI mit dem BSI-Standard 200-3 und die ISO 27001. Beide definieren, dass<\/em> und wof\u00fcr<\/em> Risiken analysiert werden m\u00fcssen. Wie<\/em> ein Team im Tagesgesch\u00e4ft systematisch \u00fcber Risiken nachdenkt, lassen sie bewusst offen \u2014 genau dort beginnt die Methodenfrage. Wer die Anforderungen kennt, w\u00e4hlt Methode und Aufwand gezielt, statt Vorgehensweisen ungepr\u00fcft aus Audit-Vorlagen zu \u00fcbernehmen.<\/p>\n\n\n\n Im IT-Grundschutz des BSI ist die explizite Risikoanalyse die Ausnahme, nicht der Regelfall. Sie ist nur f\u00fcr Zielobjekte erforderlich, auf die mindestens einer von drei F\u00e4llen zutrifft: hoher oder sehr hoher Schutzbedarf in einem der Grundwerte Vertraulichkeit, Integrit\u00e4t oder Verf\u00fcgbarkeit; kein hinreichend passender Baustein im IT-Grundschutz-Kompendium; oder eine untypische Einsatzumgebung des Zielobjekts. F\u00fcr alle \u00fcbrigen Zielobjekte gilt: Die Bausteine des Kompendiums decken das Risiko bereits angemessen ab.<\/p>\n\n\n\n Die Methodik daf\u00fcr liefert der BSI-Standard 200-3 \u201eRisikomanagement” (Fassung vom 15.11.2017). Er b\u00fcndelt erstmals alle risikobezogenen Arbeitsschritte des IT-Grundschutzes und arbeitet mit einem vereinfachten Gef\u00e4hrdungsmodell auf Basis der elementaren Gef\u00e4hrdungen des IT-Grundschutz-Kompendiums. Der Ablauf: Gef\u00e4hrdungs\u00fcbersicht erstellen, Risiken nach Eintrittswahrscheinlichkeit und Schadensausma\u00df einstufen, Risikobehandlung festlegen, Ergebnisse in den Sicherheitsprozess zur\u00fcckf\u00fchren.<\/p>\n\n\n\n Die ISO 27001 definiert die Anforderungen an ein ISMS \u2014 und die aktuelle Fassung ISO\/IEC 27001:2022 macht den Risikomanagementprozess zu dessen Kern: Ein ISMS wahrt Vertraulichkeit, Integrit\u00e4t und Verf\u00fcgbarkeit von Informationen, indem es einen Risikomanagementprozess anwendet. Zertifiziert wird also das Managementsystem, nicht die einzelne Analyse.<\/p>\n\n\n\n Die Anleitung dazu liefert ISO\/IEC 27005:2022 mit Leitlinien f\u00fcr das Management von Informationssicherheitsrisiken. Sie adaptiert die Prinzipien der ISO 31000 f\u00fcr die Informationssicherheit und deckt den vollst\u00e4ndigen Zyklus ab: Risk Assessment, Risikobehandlung, Kommunikation, Monitoring und Review.<\/p>\n\n\n\n Entscheidend f\u00fcr die Praxis: IT-Grundschutz wie ISO 27001 sind methodenoffen. Sie fordern ein nachvollziehbares, wiederholbares Risk Assessment mit konsistenten Kriterien \u2014 mit welcher Methode ein Unternehmen Bedrohungen und Schwachstellen bewertet, bleibt seine Entscheidung. Die Norm verlangt den Prozess; die Qualit\u00e4t des Denkens muss die Organisation selbst mitbringen.<\/p>\n\n\n\n Risikomatrix, quantitative Verfahren und FMEA beantworten je eine andere Frage \u2014 wer die Methoden einordnet, statt sie aufzuz\u00e4hlen, w\u00e4hlt nach Entscheidungsbedarf und nicht nach Gewohnheit. Drei Fragen leiten die Wahl: Wie pr\u00e4zise muss die Bewertung sein? Wie klar definiert ist das betrachtete System? Und wie h\u00e4ufig muss die Analyse wiederholt werden?<\/p>\n\n\n\n F\u00fcr IT-Betriebsrisiken ist die qualitative Bewertung meist tragf\u00e4higer als eine scheingenaue Quantifizierung. Grundlage ist die Risikomatrix: F\u00fcr jedes IT-Asset \u2014 Systeme, Anwendungen, Netzkomponenten, Daten \u2014 werden Gef\u00e4hrdungen erfasst und in einer Matrix aus Eintrittswahrscheinlichkeit und Schadensausma\u00df eingestuft. Quantitative Verfahren rechnen stattdessen mit Geldwerten und H\u00e4ufigkeiten; sie lohnen sich dort, wo belastbare Ausfalldaten vorliegen, etwa bei Verf\u00fcgbarkeitsentscheidungen f\u00fcr kritische IT-Infrastruktur.<\/p>\n\n\n\n Entscheidend ist nicht die Kommastelle, sondern die konsistente Skala: Wenn zwei Teams dasselbe Risiko unterschiedlich einstufen, ist die Risikobewertung keine Entscheidungsgrundlage mehr. Die Skalendefinition \u2014 was bedeutet \u201ehoch” in Euro, Ausfallstunden oder betroffenen Nutzern? \u2014 ist deshalb wichtiger als die Wahl zwischen qualitativ und quantitativ.<\/p>\n\n\n\n Die FMEA (Failure Mode and Effects Analysis) stammt aus der Fertigung und funktioniert dort, wo ein technisches System klar definiert ist: Fehlerarten, Fehlerfolgen und Ursachen werden systematisch durchgearbeitet und priorisiert. In der IT eignet sich die FMEA deshalb f\u00fcr abgegrenzte IT-Systeme und Prozesse \u2014 etwa eine Storage-Architektur oder einen Zahlungsprozess.<\/p>\n\n\n\n F\u00fcr breite Change- und Betriebsrisiken ist die FMEA jedoch zu granular. Hier braucht es ein Screening auf h\u00f6herer Flugh\u00f6he, das Bedenken schnell identifiziert und nur dort in die Tiefe geht, wo eine genauere Pr\u00fcfung n\u00f6tig ist \u2014 genau an dieser Stelle setzt die Potential Problem Analysis<\/a> an.<\/p>\n\n\n\n Die Potential Problem Analysis (PPA) ist einer der f\u00fcnf Kernprozesse der Kepner-Tregoe-Methodik PSDM (Problem Solving & Decision Making) \u2014 neben Situation Appraisal<\/a>, Problem Analysis, Decision Analysis<\/a> und Potential Opportunity Analysis. Ihre Aufgabe: Risiken vorab managen und die Folgen begrenzen, wenn etwas nicht nach Plan l\u00e4uft.<\/p>\n\n\n\n Der Unterschied zur klassischen IT-Risikoanalyse liegt nicht im Ziel, sondern im Format: Die PPA ist als Denkprozess angelegt, der sich vor jeder riskanten Aktivit\u00e4t wiederholen l\u00e4sst \u2014 dieselben Fragen, in derselben Reihenfolge, im Team. Zur Risikominderung ist sie seit \u00fcber 60 Jahren im Einsatz. Damit wird Risikoanalyse trainierbar: kein Dokument, das eine Fachabteilung pflegt, sondern eine Routine, die jede Betriebsmannschaft im Unternehmen beherrschen kann. Wie Teams die PSDM-Methodik in der Praxis anwenden, lernen sie im KT Training zur Probleml\u00f6sung & Entscheidungsfindung<\/a>.<\/p>\n\n\n\n Die PPA l\u00e4uft in vier Schritten ab, deren Logik sich so zusammenfassen l\u00e4sst:<\/p>\n\n\n\n Der vierte Schritt unterscheidet die PPA von vielen Risikoanalysen in der Praxis: Sie liefert pro Risiko nicht nur Pr\u00e4vention, sondern auch eine vorbereitete Reaktion samt definiertem Ausl\u00f6ser \u2014 in der IT zum Beispiel den Rollback-Trigger eines Changes.<\/p>\n\n\n\n Eine Checkliste pr\u00fcft bekannte Risiken ab; die PPA fragt systematisch nach dem, was die Checkliste noch nicht kennt. Checklisten sind wertvoll, um Wiederholungsfehler auszuschlie\u00dfen \u2014 aber sie sind r\u00fcckw\u00e4rtsgewandt: Sie enthalten nur Gef\u00e4hrdungen, die bereits eingetreten sind. Der strukturierte Denkprozess der PPA \u00f6ffnet den Blick f\u00fcr die Risiken des konkreten Vorhabens in seiner konkreten Umgebung. Und er erzwingt pro Risiko zwei Entscheidungen statt einer: eine Pr\u00e4ventions- und eine Reaktionsentscheidung. Beides zusammen macht den Unterschied zwischen \u201eRisiko dokumentiert” und \u201eRisiko beherrscht”.<\/p>\n\n\n\n Changes sind der Moment, in dem Risiko konkret wird. Jede \u00c4nderung an produktiven IT-Systemen \u2014 Fix, Upgrade, Release, Konfigurations\u00e4nderung \u2014 greift in eine funktionierende IT-Infrastruktur ein. Die Datenlage unterstreicht das: Laut Uptime Institute (Annual Outage Analysis 2025) meldeten knapp 40 Prozent der Organisationen in den letzten drei Jahren einen schweren Ausfall durch menschliches Versagen; 85 Prozent dieser Vorf\u00e4lle gehen auf das Nichtbefolgen von Verfahren oder auf fehlerhafte Prozesse und Verfahren zur\u00fcck. Menschliches Versagen ist damit in aller Regel kein Personenproblem, sondern ein Verfahrensproblem \u2014 und Verfahren lassen sich verbessern.<\/p>\n\n\n\n Hinzu kommt: Ausf\u00e4lle durch IT- und Netzwerkprobleme stiegen 2024 auf 23 Prozent der folgenreichen Ausf\u00e4lle. Das Uptime Institute f\u00fchrt diesen Anstieg nach eigener Einsch\u00e4tzung auf gewachsene Komplexit\u00e4t zur\u00fcck, die zu Problemen beim Change Management und zu Fehlkonfigurationen f\u00fchrt. Nicht Cyberangriffe, sondern die eigenen Changes sind f\u00fcr viele Unternehmen das untersch\u00e4tzte Betriebsrisiko.<\/p>\n\n\n\n Das Change Management nach ITIL 4 zieht daraus die Konsequenz: Zweck der Practice Change Enablement ist es, die Zahl erfolgreicher Changes zu maximieren \u2014 indem sichergestellt wird, dass Risiken sauber bewertet sind, bevor ein Change autorisiert wird (ITIL 4, Practice Change Enablement, AXELOS 2020). Das Risk Assessment ist im Change-Prozess also keine Formalie, sondern die Eintrittsbedingung f\u00fcr die Autorisierung.<\/p>\n\n\n\n Genau hier scheitert die Compliance-getriebene IT-Risikoanalyse: Das j\u00e4hrliche ISMS-Dokument kennt den konkreten Change nicht. Ein Change Risk Assessment braucht eine Methode, die schnell genug f\u00fcr den Change-Takt ist und trotzdem systematisch bleibt. Die PPA operationalisiert das Change Risk Assessment als vier Fragen: Was k\u00f6nnte bei diesem Change schiefgehen? Woran w\u00fcrde es liegen?<\/p>\n\n\n\n Welche Ma\u00dfnahmen verhindern das vorab? Und was tun wir \u2014 mit welchem Ausl\u00f6ser \u2014, wenn es trotzdem eintritt? So entsteht je Change eine nachvollziehbare Risikobewertung samt Rollback-Kriterien: Schritt f\u00fcr Schritt, in Minuten statt in Tagen. Wie sich dieses Vorgehen im Team trainieren l\u00e4sst, zeigt der Workshop Risikominderung f\u00fcr die IT<\/a>.<\/p>\n\n\n\n PPA vor dem Change und Problem Analysis nach dem Incident sind derselbe Denkprozess in zwei Richtungen. Vor der \u00c4nderung fragt das Team: Was k\u00f6nnte schiefgehen, und woran w\u00fcrde es liegen? Nach dem Incident fragt es:<\/p>\n\n\n\n Was ist schiefgegangen, und woran lag es? Wer beide Prozesse mit derselben Methodik betreibt, schlie\u00dft den Regelkreis: Erkenntnisse aus dem Incident- und Problem-Management flie\u00dfen als neue Gef\u00e4hrdungen, Schwachstellen und wahrscheinliche Ursachen in die n\u00e4chste Risikoanalyse ein \u2014 und sch\u00e4rfen die vorbeugenden Ma\u00dfnahmen. Das gilt unabh\u00e4ngig davon, ob das Unternehmen nach ISO 27001 zertifiziert ist oder dem IT-Grundschutz folgt.<\/p>\n\n\n\n Ohne diese R\u00fcckf\u00fchrung bleibt jede Risikoanalyse statisch: Sie bildet den Wissensstand ihres Erstellungsdatums ab, w\u00e4hrend sich Bedrohungen, Architektur und Prozesse weiterentwickeln. Die Standards fordern Review und Monitoring ausdr\u00fccklich \u2014 praktikabel wird die Aktualisierung aber erst durch den methodischen Regelkreis im Betrieb. Wie sich Risikomanagement als Gesamtdisziplin dazu verh\u00e4lt, beschreibt unser Beitrag zu effektivem Risikomanagement<\/a>; hier ging es um die Analyse-Methodik f\u00fcr den IT-Betrieb.<\/p>\n\n\n\n F\u00fcnf Bestandteile: der Scope (welche Zielobjekte und IT-Assets betrachtet werden), eine Gef\u00e4hrdungs\u00fcbersicht je Zielobjekt, die Risikobewertung nach Eintrittswahrscheinlichkeit und Schadensausma\u00df, die Entscheidung \u00fcber die Risikobehandlung sowie die R\u00fcckf\u00fchrung der Ergebnisse in den Sicherheitsprozess.<\/p>\n\n\n\n In der Praxis haben sich mehrere Risikobehandlungsoptionen etabliert: ein Risiko vermeiden (die riskante Aktivit\u00e4t unterlassen oder umgestalten), es durch Ma\u00dfnahmen reduzieren, es transferieren (etwa an Versicherer oder Dienstleister) oder es bewusst und dokumentiert akzeptieren. Welche Option angemessen ist, entscheidet sich am Verh\u00e4ltnis von Risikoh\u00f6he zu Behandlungsaufwand.<\/p>\n\n\n\n Ja \u2014 die FMEA ist eine formalisierte Risikoanalyse f\u00fcr definierte technische Systeme. F\u00fcr breite Change- und Betriebsrisiken arbeitet die Potential Problem Analysis als schnelleres Screening auf h\u00f6herer Ebene und identifiziert die Punkte, die eine tiefere Pr\u00fcfung \u2014 etwa per FMEA \u2014 brauchen.<\/p>\n\n\n\n Wer die IT-Risikoanalyse als trainierbaren Denkprozess im Team verankert, statt sie als Audit-Artefakt zu pflegen, senkt die Zahl vermeidbarer Incidents \u2014 in der IT-Sicherheit wie im Betrieb. Der eint\u00e4gige, simulationsbasierte Workshop \u201eRisikominderung f\u00fcr die IT” von Kepner-Tregoe vermittelt daf\u00fcr einen F\u00fcnf-Schritte-Prozess zur Reduzierung und Minderung allt\u00e4glicher Risiken \u2014 f\u00fcr Teams, die Changes, Fixes, Upgrades, Releases und Wartung verantworten. Vertiefen Sie die zugrunde liegende PSDM-Methodik anschlie\u00dfend im Workshop-Programm von Kepner-Tregoe<\/a>.<\/p>\n\n\n\nIT-Grundschutz: Risikoanalyse nach BSI-Standard 200-3<\/h3>\n\n\n\n
ISO 27001 und ISO\/IEC 27005: Risk Assessment im ISMS<\/h3>\n\n\n\n
Welche Methoden gibt es f\u00fcr die IT-Risikoanalyse?<\/h2>\n\n\n\n
Von IT-Assets zur Bewertung: qualitativ oder quantitativ?<\/h3>\n\n\n\n
FMEA in der IT: St\u00e4rken und Grenzen<\/h3>\n\n\n\n
Potential Problem Analysis: Risikoanalyse als wiederholbarer Denkprozess<\/h2>\n\n\n\n
Die vier Schritte der PPA<\/h3>\n\n\n\n
\n
Was die PPA von der Checklisten-Risikoanalyse unterscheidet<\/h3>\n\n\n\n
Change Risk Assessment: Warum Changes der Ernstfall der IT-Risikoanalyse sind<\/h2>\n\n\n\n
Von der Risikoanalyse zum Incident- und Problem-Management: ein Regelkreis<\/h2>\n\n\n\n
H\u00e4ufige Fragen zur IT-Risikoanalyse<\/h2>\n\n\n\n
Was geh\u00f6rt alles in eine IT-Risikoanalyse?<\/h3>\n\n\n\n
Welche Risikostrategien gibt es?<\/h3>\n\n\n\n
Ist eine FMEA eine Risikoanalyse?<\/h3>\n\n\n\n
Fazit: Risikoanalyse ist trainierbar<\/h2>\n\n\n\n