Root Cause Analysis: Methoden für nachvollziehbare Ursachenbefunde

Root Cause Analysis (RCA) ist die methodische Untersuchung, die eine Störung auf ihre Ursachen zurückführt und diese so belegt, dass Dritte, etwa die interne Revision oder eine Aufsichtsbehörde, den Befund nachvollziehen können.

In regulierten Branchen genügt es nicht, eine Ursache zu kennen. Sie muss begründet, dokumentiert und mit Massnahmen verknüpft sein. Die Wahl der Methode entscheidet darüber, wie belastbar dieser Nachweis ist: Eine Zeitleiste aus Systemprotokollen trägt mehr als die Erinnerung der Beteiligten, eine geprüfte Ist-/Ist-nicht-Abgrenzung mehr als eine plausible Vermutung. Dieser Artikel ordnet sieben verbreitete Methoden nach ihrem Nachweiswert und zeigt, wo ihre Grenzen liegen. Ablauf, Rollen und Berichtsaufbau einer RCA im Problem Management behandelt der Glossarartikel RCA.

Das Wichtigste in Kürze

• Belegende Methoden: Timeline-, Change- und Kepner-Tregoe-Analyse stützen sich auf Protokolle, Änderungsnachweise und überprüfbare Abgrenzungen.
• Strukturierende Methoden: Ishikawa-Diagramm, Fehlerbaum, Pareto und 5 Why ordnen Hypothesen und Schwerpunkte, beweisen allein aber nichts.
• Regulatorischer Bezug: Das FINMA-Rundschreiben 2023/1 verlangt von Banken und Wertpapierhäusern nach erfolgreichen oder teilweise erfolgreichen Cyber-Attacken einen abschliessenden Ursachenbericht, dessen Umfang sich am Schweregrad orientiert.
• Datenhaltung: Logs mit Personendaten unterliegen dem Datenschutzgesetz. Aufbewahrung und Zugriff gehören vorab geregelt.

Stand: November 2026 · Fachlich abgeglichen mit FINMA-RS 2023/1, DSG (Fedlex), AHRQ, NASA, IEC 61025 und Google SRE (Quellen am Ende des Artikels)

Belegende Methoden: Timeline, Change-Analyse, Kepner-Tregoe

Diese drei Methoden erzeugen ihren Befund aus überprüfbaren Daten. Sie eignen sich deshalb als Rückgrat jeder Ursachenanalyse, die später einer Prüfung standhalten soll.

Timeline-Analyse

Einsatzzweck: Die Timeline rekonstruiert den Hergang einer Störung aus zeitgestempelten Quellen. Sie bildet das Gerüst eines Postmortems, das Google SRE als schriftliche Aufzeichnung von Vorfall, Auswirkung, Gegenmassnahmen, Ursachen und Folgemassnahmen beschreibt.

Ablauf: Jeder Eintrag erhält Zeitpunkt, Ereignis und Quelle, etwa SIEM-Meldung, Applikationslog, Ticket-Historie oder Change-Eintrag. Alle Zeiten werden auf eine Referenzzeit normiert. Mündliche Angaben werden als solche gekennzeichnet und, wo möglich, durch Protokolle bestätigt.

Grenzen: Die Timeline belegt eine Abfolge, nicht eine Kausalität. Abweichende Systemuhren und Protokolllücken schwächen sie.

Beispiel: Angenommen, bei einem Vermögensverwalter fällt das Kundenportal am Vormittag für knapp eine Stunde aus. Die Timeline aus Load-Balancer-Log, Datenbankprotokoll und Change-System zeigt, dass ein Index-Neuaufbau ausserhalb des genehmigten Wartungsfensters gestartet wurde. Der Befund ist damit nicht nur technisch, sondern auch kontrollseitig relevant.

Change-Analyse

Einsatzzweck: Die Change-Analyse stellt den gestörten Zustand einem vergleichbaren störungsfreien gegenüber und sucht nach Unterschieden und Änderungen. Laut Google SRE geht ein grosser Teil der Ausfälle, rund 70 Prozent, auf Änderungen an laufenden Systemen zurück.

Ablauf: Referenzzustand festlegen, alle Änderungen im fraglichen Zeitraum aus Change-Register, Deployment-Protokoll und CMDB ziehen und jede auf Wirkmechanismus prüfen. Besonders aufschlussreich ist der Abgleich mit dem genehmigten Änderungsstand: Eine Abweichung ist zugleich ein Befund für das Change Management.

Grenzen: Undokumentierte Eingriffe bleiben unsichtbar. Zudem kann eine Änderung lediglich der Auslöser sein, während die eigentliche Schwachstelle älter ist.

Beispiel: Angenommen, nach einem Zertifikatswechsel lehnt eine Schnittstelle zum Zahlungsverkehr Verbindungen ab. Der Vergleich mit dem Testsystem zeigt, dass dort die vollständige Zertifikatskette hinterlegt wurde, in der Produktion nur das Endzertifikat.

Kepner-Tregoe-Problemanalyse

Einsatzzweck: Die Methode nach Charles H. Kepner und Benjamin B. Tregoe trennt konsequent Fakten von Annahmen. Die Ist-/Ist-nicht-Matrix der AHRQ hält für Was, Wo, Wann und Ausmass fest, was betroffen ist und was vergleichbar wäre, aber nicht betroffen ist.

Ablauf: Aus der Gegenüberstellung folgen Unterscheidungsmerkmale, zu denen zugehörige Änderungen gesucht werden. Jede mögliche Ursache wird gegen alle Einträge geprüft. Bestehen bleibt nur, was jede Zeile erklärt. Die anschliessende Verifikation per Test schliesst die Analyse ab.

Grenzen: Hoher Zeitbedarf und Abhängigkeit von präzisen Angaben. Bei mehreren gleichzeitig wirkenden Ursachen verliert die Abgrenzung an Schärfe.

Beispiel: Angenommen, in einem Spitalverbund melden nur die Stationen eines Standorts verzögerte Laborbefunde, und das nur in der Nacht. Die Abgrenzung lenkt den Blick auf einen nächtlichen Synchronisationsjob, der nur für diesen Standort über eine separate Leitung läuft.

Strukturierende Methoden: Ishikawa, Fehlerbaum, Pareto, 5 Why

Die folgenden Methoden ordnen Hypothesen, zeigen Abhängigkeiten oder setzen Schwerpunkte. Ihr Ergebnis wird erst durch die Prüfung mit Daten zum Befund.

Ishikawa-Diagramm

Das Ursache-Wirkungs-Diagramm nach Kaoru Ishikawa sammelt mögliche Einflussfaktoren entlang von Kategorien. Laut Institute for Healthcare Improvement eignet es sich, um zu zeigen, dass viele Ursachen zu einer Wirkung beitragen. Für Governance-Zwecke empfiehlt sich eine Kategorie «Kontrollen», die fehlende oder wirkungslose Prüfschritte sichtbar macht. Grenze: Das Diagramm dokumentiert Hypothesen, nicht deren Bestätigung. Beispiel: Bei fehlerhaften Stammdaten in einem Fachverfahren einer Verwaltung landen Schnittstelle, Erfassungsmaske, Schulung und fehlende Plausibilitätsprüfung auf den Gräten.

Fehlerbaumanalyse

Die in IEC 61025 genormte Fehlerbaumanalyse leitet ein unerwünschtes Top-Ereignis deduktiv über UND- und ODER-Verknüpfungen auf Basisereignisse zurück. Das NASA Fault Tree Handbook bezeichnet die minimalen Schnittmengen, die kleinsten zum Top-Ereignis führenden Kombinationen, als wichtigstes qualitatives Ergebnis. Grenze: Der Baum umfasst nur Ausfälle, die zum gewählten Top-Ereignis beitragen, und verlangt fundierte Architekturkenntnis. Beispiel: Angenommen, zwei redundante Leitungen zum Rechenzentrum fallen gemeinsam aus. Der Fehlerbaum zeigt, dass beide über denselben Hausanschluss geführt werden: eine Schnittmenge mit einem einzigen Ereignis.

Pareto-Analyse

Die Pareto-Analyse sortiert Störungen nach Häufigkeit oder Auswirkung und zeigt, welche wenigen Kategorien den Grossteil ausmachen. J. M. Juran übertrug das Prinzip auf die Qualitätssicherung. Die Werte 80 und 20 sind laut Oregon State University nicht absolut zu verstehen. Grenze: Pareto beantwortet das Wo, nicht das Warum, und hängt von einer konsistenten Kategorisierung ab. Beispiel: Die Auswertung der Störungen eines Halbjahres nach betroffenem Service legt fest, welche drei Services zuerst in die vertiefte Analyse gehen.

5 Why

Die aus dem Toyota-Produktionssystem stammende Fragekette führt vom Symptom zur beseitigbaren Ursache. Das Lean Enterprise Institute hält fest, dass die Zahl fünf nicht massgeblich ist. Grenze: Die Kette ist linear und subjektiv. Ohne Belege je Schritt hat sie geringen Nachweiswert. Beispiel: Ein abgelaufenes Zertifikat führt über fehlende Ablaufüberwachung zur eigentlichen Ursache: Zertifikate sind keinem Verantwortlichen zugeordnet.

Nachweiswert der Methoden

Ursachenanalyse in regulierten Umgebungen

Für Banken und Wertpapierhäuser konkretisiert das FINMA-Rundschreiben 2023/1 «Operationelle Risiken und Resilienz – Banken» die Erwartungen. Im Vorfallmanagement verlangt es Verfahren, Prozesse und Kontrollen für wesentliche IKT-Vorfälle über deren gesamten Lebenszyklus sowie definierte Aufgaben, Kompetenzen und Verantwortlichkeiten. Nach einer erfolgreichen oder teilweise erfolgreichen Cyber-Attacke ist nach Abschluss der Fallbearbeitung ein dem Schweregrad entsprechender abschliessender Ursachenbericht bei der FINMA einzureichen. Welche Analysemethode verwendet wird, schreibt das Rundschreiben nicht vor. Der Bericht muss den Befund aber nachvollziehbar begründen.

Was das für die Methodenwahl bedeutet

• Timeline als Pflichtbestandteil: Ohne belegte Abfolge lässt sich weder die Meldekette noch die Wirksamkeit der Gegenmassnahmen beurteilen.
• Change-Analyse gegen das genehmigte Register: Abweichungen zwischen geplantem und tatsächlichem Zustand sind für die Revision ein eigener Befund.
• Vier-Augen-Prinzip: Wer die Analyse durchführt, sollte den Befund nicht allein freigeben, gerade wenn das eigene Team an der Störung beteiligt war.
• Strukturierende Methoden als Anhang: Ishikawa-Diagramm oder Fehlerbaum dokumentieren, welche Hypothesen geprüft und verworfen wurden.

Datenhaltung und Datenschutz

Protokolle, Chatverläufe und Ticket-Historien enthalten häufig Personendaten. Nach dem Datenschutzgesetz (DSG) muss ihre Bearbeitung verhältnismässig und zweckgebunden sein, und sie sind zu vernichten oder zu anonymisieren, sobald sie für den Zweck nicht mehr erforderlich sind. Legen Sie deshalb fest, welche Belege für eine Ursachenanalyse wie lange aufbewahrt werden und wer darauf zugreift. Wo die Daten physisch liegen, ist für viele Institute ebenfalls eine Governance-Frage: ky2help^® läuft als SaaS oder On-Premises, mit eigener Instanz in einem Rechenzentrum in der Schweiz oder in Deutschland.

Nachvollziehbarkeit in der Praxis

Angenommen, eine Privatbank in Zürich analysiert einen Ausfall des E-Banking. Analyse, Freigabe und Massnahmenverfolgung laufen als dokumentierter Workflow, jeder Schritt wird automatisch historisiert. Bei der Prüfung durch die Revision liegt der Befund samt Belegen an einer Stelle vor. Wie das in der öffentlichen Verwaltung aussehen kann, zeigt das Personalamt des Kantons Thurgau: Dort sind die HR-Prozesse mit ky2help^® lückenlos nachvollziehbar, dokumentiert und archiviert.

Funktionsumfang ansehen

Qualitätskriterien für einen belastbaren Ursachenbefund

Ob ein Befund einer Prüfung standhält, lässt sich an sechs Kriterien festmachen:

1. Präzise Problembeschreibung: betroffene Services, Zeitraum, Ausmass und nicht betroffene Vergleichsfälle.
2. Belege je Aussage: Jede Ursache verweist auf ein Protokoll, einen Änderungseintrag oder einen Test.
3. Geprüfte Alternativen: Verworfene Hypothesen sind mit Begründung dokumentiert.
4. Trennung von Auslöser und Ursache: Der Befund benennt, was die Störung möglich gemacht hat, nicht nur, was sie ausgelöst hat.
5. Keine Schuldzuweisung: Auch Microsoft Learn empfiehlt eine Nachbetrachtung, die auf Erkenntnisse statt auf Schuld zielt. Organisatorische Ursachen wie fehlende Kontrollen werden benannt.
6. Massnahmen mit Verantwortung und Frist: Jede Massnahme ist einer Person zugeordnet und wird bis zur Wirksamkeitsprüfung verfolgt.

Typische Schwachstellen

Häufig fehlt die Verbindung zwischen Ursachenbefund und Change Management: Die Analyse empfiehlt eine Anpassung, die nie als Change beantragt wird. Ebenso häufig bleibt die Wirksamkeitsprüfung aus, weil das Problem bereits geschlossen ist. Beides lässt sich vermeiden, wenn Problem und Change verknüpft sind und das Problem erst nach bestätigter Wirkung geschlossen wird. Mehr dazu unter ITIL Change Management und im Glossarartikel ISO 27001.

Häufige Fragen zu RCA-Methoden und Nachweis

Welche RCA-Methoden liefern prüfbare Belege?

Am belastbarsten sind Timeline-Analyse, Change-Analyse und Kepner-Tregoe-Problemanalyse, weil sie sich auf Protokolle, Änderungsnachweise und überprüfbare Abgrenzungen stützen. Ishikawa-Diagramm, Pareto und 5 Why ordnen Hypothesen und Schwerpunkte, brauchen aber zusätzliche Belege.

Wie funktioniert die Kepner-Tregoe-Problemanalyse?

Für Was, Wo, Wann und Ausmass wird festgehalten, was betroffen ist und was vergleichbar wäre, aber nicht betroffen ist. Aus den Unterschieden und den zugehörigen Änderungen werden mögliche Ursachen abgeleitet. Bestehen bleibt nur die Ursache, die alle Einträge erklärt, und sie wird anschliessend getestet.

Warum sollten verworfene Hypothesen dokumentiert werden?

Weil sie zeigen, dass die Analyse Alternativen ernsthaft geprüft hat. Wer nachvollziehen kann, welche Ursachen mit welchem Beleg ausgeschlossen wurden, kann den Befund beurteilen, ohne die Analyse zu wiederholen. Ishikawa-Diagramm und Fehlerbaum eignen sich dafür als Anhang.

Wie wird eine Timeline nachvollziehbar dokumentiert?

Jeder Eintrag enthält Zeitpunkt, Ereignis und Quelle. Alle Zeiten werden auf eine Referenzzeit normiert, mündliche Angaben werden gekennzeichnet und möglichst durch Protokolle bestätigt. Lücken werden ausdrücklich vermerkt, statt sie zu überbrücken.

Wann lohnt sich eine Fehlerbaumanalyse?

Wenn ein kritischer Service trotz Redundanz ausfällt oder wenn vorab geklärt werden soll, welche Kombinationen von Ausfällen einen Service lahmlegen. Die Analyse zeigt gemeinsame Abhängigkeiten, ist aber aufwendig und verlangt fundierte Kenntnis der Architektur.

Welche ky2help®-Funktionen stützen den Nachweis einer Ursache?

ky2help® verknüpft Incidents, Probleme und Changes, historisiert Änderungen automatisch und dokumentiert revisionssicher mit integriertem Daten-Audit. Problem Management gehört zu den 13 von PeopleCert akkreditierten ITIL®-Practices. Betrieben wird ky2help® als SaaS oder On-Premises, auf Wunsch mit eigener Instanz in einem Rechenzentrum in der Schweiz.

Quellen und weiterführende Artikel

Quellen

• FINMA: Rundschreiben 2023/1 «Operationelle Risiken und Resilienz – Banken» (PDF)
• Fedlex: Bundesgesetz über den Datenschutz (DSG)
• AHRQ: Kepner-Tregoe Matrix
• IEC: IEC 61025:2006 Fault tree analysis
• NASA: Fault Tree Handbook with Aerospace Applications (PDF)
• Google SRE: Postmortem Culture und Introduction
• Institute for Healthcare Improvement: Cause and Effect Diagram
• Oregon State University Extension: Pareto Analysis and Check Sheets
• Lean Enterprise Institute: 5 Whys
• Microsoft Learn: Entwicklung einer Incident-Management-Praxis (Azure Well-Architected Framework)

Weiterlesen im Glossar und auf kyberna.ch

• RCA und Problem Management nach ITIL
• Change Management und CMDB
• ISO 27001 und DSGVO
• ky2help® für Finanzdienstleister und Cybersecurity Services
• Referenz Personalamt Kanton Thurgau