Die meisten IT-Risikoanalysen bestehen das Audit und verfehlen den Betrieb. Wer Risiken nur für den Nachweis dokumentiert, analysiert sie nicht dort, wo Incidents tatsächlich entstehen: bei Changes, Releases und Eingriffen in laufende IT-Systeme.
Dieser Beitrag richtet sich an Verantwortliche für IT-Operations, Infrastruktur und Incident-/Problem-Management und beantwortet eine Frage: Wie wird die IT-Risikoanalyse vom jährlichen Pflichtdokument zum wiederholbaren Denkprozess, der Ausfälle und Major Incidents vermeidbar macht? Dazu ordnen wir Standards und Methoden ein — und zeigen mit der Potential Problem Analysis einen Prozess, der die Risikoanalyse in die Betriebsroutine holt.
Was muss eine IT-Risikoanalyse für IT-Sicherheit und Betrieb leisten?
Eine IT-Risikoanalyse liefert erst dann Wert, wenn sie als wiederholbarer Denkprozess betrieben wird — nicht als jährliches Audit-Artefakt. Der Kern ist immer derselbe Dreischritt: Gefährdungen für die relevanten Zielobjekte identifizieren, Risiken nach Eintrittswahrscheinlichkeit und Schadensausmaß bewerten, über die Risikobehandlung entscheiden.
Für die IT-Sicherheit heißt das: Bedrohungen und Schwachstellen werden systematisch den IT-Assets zugeordnet und gegen die Grundwerte Vertraulichkeit, Integrität und Verfügbarkeit geprüft. Für den Betrieb heißt es: Die Analyse muss dort stattfinden, wo Risiken konkret werden — vor Changes, Migrationen, Releases und Wartungsfenstern, nicht nur in der jährlichen ISMS-Runde.
Zwei Fehlbilder dominieren die Praxis in vielen Unternehmen. Das erste ist die reine Compliance-Übung: Risiken werden erfasst, bewertet, abgeheftet — und bis zum nächsten Audit nicht wieder angefasst. Das zweite ist die Gleichsetzung von IT-Risiken mit Cyberangriffen: Bedrohungen von außen sind nur eine Risikoklasse.
Fehlkonfigurationen, misslungene Changes, ungepatchte Schwachstellen und Prozesslücken verursachen einen erheblichen Teil der realen Ausfälle. Eine tragfähige IT-Risikoanalyse deckt deshalb beides ab: die Informationssicherheit und die Betriebsstabilität der IT-Systeme.
BSI-Standard 200-3 und ISO 27001: Was die Standards fordern — und was sie offenlassen
Maßgeblich sind für Unternehmen im DACH-Raum zwei Rahmenwerke: der IT-Grundschutz des BSI mit dem BSI-Standard 200-3 und die ISO 27001. Beide definieren, dass und wofür Risiken analysiert werden müssen. Wie ein Team im Tagesgeschäft systematisch über Risiken nachdenkt, lassen sie bewusst offen — genau dort beginnt die Methodenfrage. Wer die Anforderungen kennt, wählt Methode und Aufwand gezielt, statt Vorgehensweisen ungeprüft aus Audit-Vorlagen zu übernehmen.
IT-Grundschutz: Risikoanalyse nach BSI-Standard 200-3
Im IT-Grundschutz des BSI ist die explizite Risikoanalyse die Ausnahme, nicht der Regelfall. Sie ist nur für Zielobjekte erforderlich, auf die mindestens einer von drei Fällen zutrifft: hoher oder sehr hoher Schutzbedarf in einem der Grundwerte Vertraulichkeit, Integrität oder Verfügbarkeit; kein hinreichend passender Baustein im IT-Grundschutz-Kompendium; oder eine untypische Einsatzumgebung des Zielobjekts. Für alle übrigen Zielobjekte gilt: Die Bausteine des Kompendiums decken das Risiko bereits angemessen ab.
Die Methodik dafür liefert der BSI-Standard 200-3 „Risikomanagement” (Fassung vom 15.11.2017). Er bündelt erstmals alle risikobezogenen Arbeitsschritte des IT-Grundschutzes und arbeitet mit einem vereinfachten Gefährdungsmodell auf Basis der elementaren Gefährdungen des IT-Grundschutz-Kompendiums. Der Ablauf: Gefährdungsübersicht erstellen, Risiken nach Eintrittswahrscheinlichkeit und Schadensausmaß einstufen, Risikobehandlung festlegen, Ergebnisse in den Sicherheitsprozess zurückführen.
ISO 27001 und ISO/IEC 27005: Risk Assessment im ISMS
Die ISO 27001 definiert die Anforderungen an ein ISMS — und die aktuelle Fassung ISO/IEC 27001:2022 macht den Risikomanagementprozess zu dessen Kern: Ein ISMS wahrt Vertraulichkeit, Integrität und Verfügbarkeit von Informationen, indem es einen Risikomanagementprozess anwendet. Zertifiziert wird also das Managementsystem, nicht die einzelne Analyse.
Die Anleitung dazu liefert ISO/IEC 27005:2022 mit Leitlinien für das Management von Informationssicherheitsrisiken. Sie adaptiert die Prinzipien der ISO 31000 für die Informationssicherheit und deckt den vollständigen Zyklus ab: Risk Assessment, Risikobehandlung, Kommunikation, Monitoring und Review.
Entscheidend für die Praxis: IT-Grundschutz wie ISO 27001 sind methodenoffen. Sie fordern ein nachvollziehbares, wiederholbares Risk Assessment mit konsistenten Kriterien — mit welcher Methode ein Unternehmen Bedrohungen und Schwachstellen bewertet, bleibt seine Entscheidung. Die Norm verlangt den Prozess; die Qualität des Denkens muss die Organisation selbst mitbringen.
Welche Methoden gibt es für die IT-Risikoanalyse?
Risikomatrix, quantitative Verfahren und FMEA beantworten je eine andere Frage — wer die Methoden einordnet, statt sie aufzuzählen, wählt nach Entscheidungsbedarf und nicht nach Gewohnheit. Drei Fragen leiten die Wahl: Wie präzise muss die Bewertung sein? Wie klar definiert ist das betrachtete System? Und wie häufig muss die Analyse wiederholt werden?
Von IT-Assets zur Bewertung: qualitativ oder quantitativ?
Für IT-Betriebsrisiken ist die qualitative Bewertung meist tragfähiger als eine scheingenaue Quantifizierung. Grundlage ist die Risikomatrix: Für jedes IT-Asset — Systeme, Anwendungen, Netzkomponenten, Daten — werden Gefährdungen erfasst und in einer Matrix aus Eintrittswahrscheinlichkeit und Schadensausmaß eingestuft. Quantitative Verfahren rechnen stattdessen mit Geldwerten und Häufigkeiten; sie lohnen sich dort, wo belastbare Ausfalldaten vorliegen, etwa bei Verfügbarkeitsentscheidungen für kritische IT-Infrastruktur.
Entscheidend ist nicht die Kommastelle, sondern die konsistente Skala: Wenn zwei Teams dasselbe Risiko unterschiedlich einstufen, ist die Risikobewertung keine Entscheidungsgrundlage mehr. Die Skalendefinition — was bedeutet „hoch” in Euro, Ausfallstunden oder betroffenen Nutzern? — ist deshalb wichtiger als die Wahl zwischen qualitativ und quantitativ.
FMEA in der IT: Stärken und Grenzen
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ür abgegrenzte IT-Systeme und Prozesse — etwa eine Storage-Architektur oder einen Zahlungsprozess.
Für breite Change- und Betriebsrisiken ist die FMEA jedoch zu granular. Hier braucht es ein Screening auf höherer Flughöhe, das Bedenken schnell identifiziert und nur dort in die Tiefe geht, wo eine genauere Prüfung nötig ist — genau an dieser Stelle setzt die Potential Problem Analysis an.
Potential Problem Analysis: Risikoanalyse als wiederholbarer Denkprozess
Die Potential Problem Analysis (PPA) ist einer der fünf Kernprozesse der Kepner-Tregoe-Methodik PSDM (Problem Solving & Decision Making) — neben Situation Appraisal, Problem Analysis, Decision Analysis und Potential Opportunity Analysis. Ihre Aufgabe: Risiken vorab managen und die Folgen begrenzen, wenn etwas nicht nach Plan läuft.
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ät wiederholen lässt — dieselben Fragen, in derselben Reihenfolge, im Team. Zur Risikominderung ist sie seit über 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ösung & Entscheidungsfindung.
Die vier Schritte der PPA
Die PPA läuft in vier Schritten ab, deren Logik sich so zusammenfassen lässt:
- Potenzielle Probleme identifizieren: Was könnte bei diesem Vorhaben schiefgehen — konkret, bezogen auf Plan und Umgebung?
- Denkbare Ursachen ermitteln: Woran würde es voraussichtlich liegen? Erst die Ursache macht ein Risiko behandelbar.
- Vorbeugende Maßnahmen ergreifen: Welche präventiven Maßnahmen setzen an den Ursachen an und senken die Eintrittswahrscheinlichkeit?
- Absichernde Maßnahmen vorbereiten: Was tun wir, wenn das Problem trotzdem eintritt — und welcher Auslöser setzt diese Maßnahmen in Gang?
Der vierte Schritt unterscheidet die PPA von vielen Risikoanalysen in der Praxis: Sie liefert pro Risiko nicht nur Prävention, sondern auch eine vorbereitete Reaktion samt definiertem Auslöser — in der IT zum Beispiel den Rollback-Trigger eines Changes.
Was die PPA von der Checklisten-Risikoanalyse unterscheidet
Eine Checkliste prüft bekannte Risiken ab; die PPA fragt systematisch nach dem, was die Checkliste noch nicht kennt. Checklisten sind wertvoll, um Wiederholungsfehler auszuschließen — aber sie sind rückwärtsgewandt: Sie enthalten nur Gefährdungen, die bereits eingetreten sind. Der strukturierte Denkprozess der PPA öffnet den Blick für die Risiken des konkreten Vorhabens in seiner konkreten Umgebung. Und er erzwingt pro Risiko zwei Entscheidungen statt einer: eine Präventions- und eine Reaktionsentscheidung. Beides zusammen macht den Unterschied zwischen „Risiko dokumentiert” und „Risiko beherrscht”.
Change Risk Assessment: Warum Changes der Ernstfall der IT-Risikoanalyse sind
Changes sind der Moment, in dem Risiko konkret wird. Jede Änderung an produktiven IT-Systemen — Fix, Upgrade, Release, Konfigurationsänderung — 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älle gehen auf das Nichtbefolgen von Verfahren oder auf fehlerhafte Prozesse und Verfahren zurück. Menschliches Versagen ist damit in aller Regel kein Personenproblem, sondern ein Verfahrensproblem — und Verfahren lassen sich verbessern.
Hinzu kommt: Ausfälle durch IT- und Netzwerkprobleme stiegen 2024 auf 23 Prozent der folgenreichen Ausfälle. Das Uptime Institute führt diesen Anstieg nach eigener Einschätzung auf gewachsene Komplexität zurück, die zu Problemen beim Change Management und zu Fehlkonfigurationen führt. Nicht Cyberangriffe, sondern die eigenen Changes sind für viele Unternehmen das unterschätzte Betriebsrisiko.
Das Change Management nach ITIL 4 zieht daraus die Konsequenz: Zweck der Practice Change Enablement ist es, die Zahl erfolgreicher Changes zu maximieren — 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ür die Autorisierung.
Genau hier scheitert die Compliance-getriebene IT-Risikoanalyse: Das jährliche ISMS-Dokument kennt den konkreten Change nicht. Ein Change Risk Assessment braucht eine Methode, die schnell genug für den Change-Takt ist und trotzdem systematisch bleibt. Die PPA operationalisiert das Change Risk Assessment als vier Fragen: Was könnte bei diesem Change schiefgehen? Woran würde es liegen?
Welche Maßnahmen verhindern das vorab? Und was tun wir — mit welchem Auslöser —, wenn es trotzdem eintritt? So entsteht je Change eine nachvollziehbare Risikobewertung samt Rollback-Kriterien: Schritt für Schritt, in Minuten statt in Tagen. Wie sich dieses Vorgehen im Team trainieren lässt, zeigt der Workshop Risikominderung für die IT.
Von der Risikoanalyse zum Incident- und Problem-Management: ein Regelkreis
PPA vor dem Change und Problem Analysis nach dem Incident sind derselbe Denkprozess in zwei Richtungen. Vor der Änderung fragt das Team: Was könnte schiefgehen, und woran würde es liegen? Nach dem Incident fragt es:
Was ist schiefgegangen, und woran lag es? Wer beide Prozesse mit derselben Methodik betreibt, schließt den Regelkreis: Erkenntnisse aus dem Incident- und Problem-Management fließen als neue Gefährdungen, Schwachstellen und wahrscheinliche Ursachen in die nächste Risikoanalyse ein — und schärfen die vorbeugenden Maßnahmen. Das gilt unabhängig davon, ob das Unternehmen nach ISO 27001 zertifiziert ist oder dem IT-Grundschutz folgt.
Ohne diese Rückführung bleibt jede Risikoanalyse statisch: Sie bildet den Wissensstand ihres Erstellungsdatums ab, während sich Bedrohungen, Architektur und Prozesse weiterentwickeln. Die Standards fordern Review und Monitoring ausdrücklich — praktikabel wird die Aktualisierung aber erst durch den methodischen Regelkreis im Betrieb. Wie sich Risikomanagement als Gesamtdisziplin dazu verhält, beschreibt unser Beitrag zu effektivem Risikomanagement; hier ging es um die Analyse-Methodik für den IT-Betrieb.
Häufige Fragen zur IT-Risikoanalyse
Was gehört alles in eine IT-Risikoanalyse?
Fünf Bestandteile: der Scope (welche Zielobjekte und IT-Assets betrachtet werden), eine Gefährdungsübersicht je Zielobjekt, die Risikobewertung nach Eintrittswahrscheinlichkeit und Schadensausmaß, die Entscheidung über die Risikobehandlung sowie die Rückführung der Ergebnisse in den Sicherheitsprozess.
Welche Risikostrategien gibt es?
In der Praxis haben sich mehrere Risikobehandlungsoptionen etabliert: ein Risiko vermeiden (die riskante Aktivität unterlassen oder umgestalten), es durch Maßnahmen reduzieren, es transferieren (etwa an Versicherer oder Dienstleister) oder es bewusst und dokumentiert akzeptieren. Welche Option angemessen ist, entscheidet sich am Verhältnis von Risikohöhe zu Behandlungsaufwand.
Ist eine FMEA eine Risikoanalyse?
Ja — die FMEA ist eine formalisierte Risikoanalyse für definierte technische Systeme. Für breite Change- und Betriebsrisiken arbeitet die Potential Problem Analysis als schnelleres Screening auf höherer Ebene und identifiziert die Punkte, die eine tiefere Prüfung — etwa per FMEA — brauchen.
Fazit: Risikoanalyse ist trainierbar
Wer die IT-Risikoanalyse als trainierbaren Denkprozess im Team verankert, statt sie als Audit-Artefakt zu pflegen, senkt die Zahl vermeidbarer Incidents — in der IT-Sicherheit wie im Betrieb. Der eintägige, simulationsbasierte Workshop „Risikominderung für die IT” von Kepner-Tregoe vermittelt dafür einen Fünf-Schritte-Prozess zur Reduzierung und Minderung alltäglicher Risiken — für Teams, die Changes, Fixes, Upgrades, Releases und Wartung verantworten. Vertiefen Sie die zugrunde liegende PSDM-Methodik anschließend im Workshop-Programm von Kepner-Tregoe.
