--- mpf: '0.7' title: Resilienz — ESFI Docs url: https://docs.esfi.eu/de/topics/resilience/ mpf-url: https://docs.esfi.eu/de/topics/resilience/index.mpf organization: European Strategy & Future Infrastructure domain: docs.esfi.eu lang: de updated: '2026-11-03' author: ESFI provenance: human source-hash: bd60eb946c1bb22178e1c3a208cf2593a412d1400a980eff0086db2c1d856bfc toc: - level: 1 text: Resilienz id: resilienz - level: 2 text: Mit der Funktion beginnen, nicht mit dem Inventar id: mit-der-funktion-beginnen-nicht-mit-dem-inventar - level: 2 text: Duplikation ist keine Unabhängigkeit id: duplikation-ist-keine-unabhängigkeit - level: 2 text: Eine absichtliche Art zu degradieren id: eine-absichtliche-art-zu-degradieren - level: 2 text: Jede Resilienzaussage hat eine Grenze id: jede-resilienzaussage-hat-eine-grenze - level: 2 text: Geplant, getestet und bewiesen sind verschiedene Dinge id: geplant-getestet-und-bewiesen-sind-verschiedene-dinge - level: 2 text: Der Test endet, wenn der Normalbetrieb zurück ist id: der-test-endet-wenn-der-normalbetrieb-zurück-ist - level: 2 text: Ausfälle respektieren keine Organigramme id: ausfälle-respektieren-keine-organigramme - level: 2 text: Wissen kann ein Single Point of Failure sein id: wissen-kann-ein-single-point-of-failure-sein - level: 2 text: Wie wir gemeinsam daran arbeiten id: wie-wir-gemeinsam-daran-arbeiten - level: 2 text: Wo wir vorsichtig sind id: wo-wir-vorsichtig-sind - level: 2 text: Weiterführende Literatur id: weiterführende-literatur - level: 2 text: Änderungen an dieser Position id: änderungen-an-dieser-position - level: 2 text: Auf dieser Seite id: auf-dieser-seite spec-origin: esfi.eu content-origin: docs.esfi.eu content-id: esfi:page:topics-resilience content-parity: html: true human-visible-source: true hidden-sections: false summary: Was funktioniert weiter, wenn etwas ausfällt? index: true confidence: probable content-type: analysis companion-footer: ESFI — civilization infrastructure · https://esfi.eu companion-contact: mailto:hermes@esfi.eu preferred-representation: mpf companion-scope: cite: true summarize: true train: true index: true relay: true language-variants: en: https://docs.esfi.eu/topics/resilience/index.mpf fr: https://docs.esfi.eu/fr/topics/resilience/index.mpf nl: https://docs.esfi.eu/nl/topics/resilience/index.mpf de: https://docs.esfi.eu/de/topics/resilience/index.mpf hr: https://docs.esfi.eu/hr/topics/resilience/index.mpf mpf-id: c489f2134575c2a8c111eed54437848f5dc10eeacd3b6a726894722762b2c078 --- Sprache ✕ /de/topics/resilience/index.mpf[Datei öffnen ↗](/de/topics/resilience/index.mpf)[Spezifikation ↗](/de/standards/mpf/0.7)✕ wird geladen… # Resilienz {#resilienz} **Was funktioniert weiter, wenn etwas ausfällt?** Eine Organisation tut alles, was Resilienzplanung verlangt. Zwei Rechenzentren. Zwei Netzwerkanbieter. Ein getestetes Backup. Ein vom Vorstand genehmigter Kontinuitätsplan. Dann tritt ein Vorfall ein. Beide Netzwerkverbindungen verlaufen durch dasselbe Rohr unter derselben Straße. Beide Rechenzentren beruhen auf demselben Identity Service, der zusammen mit der Primärumgebung ausfällt. Das Backup ist intakt, aber das Verfahren zu seiner Aktivierung setzt einen Kommunikationskanal voraus, der mit allem anderen ausgefallen ist. Jede Komponente war dupliziert. Nichts war unabhängig. Den meisten Organisationen, mit denen wir sprechen, fehlen nicht Resilienzmaßnahmen. Was oft fehlt, ist eine klare Antwort auf eine engere Frage: Wenn eine bestimmte Abhängigkeit verschwindet, welche wesentliche Funktion arbeitet weiter, wie lange, auf welchem Niveau, unter wessen Autorität und mit welchem Weg zurück zum Normalbetrieb? Dort hört Resilienz auf, eine Checkliste zu sein, und wird zu einer Engineering-Eigenschaft. Unsere Position ist einfach zu formulieren. **Resilienz ist eine Eigenschaft einer wesentlichen Funktion unter einer benannten Ausfallbedingung.** „Resilient“ allein ist keine Aussage, die jemand testen kann. „Diese Funktion läuft auf diesem Niveau für diese Dauer weiter, wenn diese Abhängigkeit wegfällt“ ist eine. * * * ## Mit der Funktion beginnen, nicht mit dem Inventar {#mit-der-funktion-beginnen-nicht-mit-dem-inventar} Resilienzarbeit beginnt häufig mit einem Inventar: Systeme, Standorte, Leitungen, Backups, Anbieter. Das Inventar ist nützlich. Es sagt nicht, was die Organisation erhalten will. Wir beginnen mit der Funktion, die weiterlaufen muss. Zahlungen ausführen. Eine Notfallreaktion koordinieren. Einen öffentlichen Informationsdienst verfügbar halten. Einen Wasseraufbereitungsprozess betreiben. Jede davon hängt gleichzeitig von vielen Dingen ab: Strom, Kommunikation, Identität, Daten, physischem Zugang, Menschen, Logistik, Fachwissen und externen Diensten. Erst wenn die Funktion benannt ist, lässt sich fragen, welche dieser Abhängigkeiten zählen, welche für eine Weile verloren gehen dürfen und welche überhaupt nicht verloren gehen dürfen. Der Unterschied ist praktisch. Ein Inventar kann zeigen, dass jedes System ein Backup hat. Nur eine funktionsbezogene Sicht kann zeigen, dass all diese Backups von demselben Ding abhängen. ## Duplikation ist keine Unabhängigkeit {#duplikation-ist-keine-unabhängigkeit} Redundanz ist leicht zu zeichnen und leicht zu überschätzen. Ein System kann viele Kopien haben und trotzdem einen einzigen Punkt besitzen, an dem alle gleichzeitig ausfallen. Wir nennen die Menge der Dinge, die durch dasselbe Ereignis entfernt werden können, eine **Failure Domain**. Die erste Frage an jedes Resilienzdesign lautet: **Welches einzelne Ereignis kann sowohl den Primärpfad als auch den Fallback entfernen?** Wenn die Antwort dasselbe Ereignis ist, hat die Organisation Duplikation, keine Unabhängigkeit. Failure Domains nehmen unterschiedliche Formen an, und die gefährlichsten sind oft am wenigsten sichtbar. **Physisch.** Zwei Glasfaserrouten im selben Graben. Zwei Anlagen, die vom selben Transformator gespeist werden. Zwei Standorte, die über dieselbe Brücke erreichbar sind. Redundante Server, die dasselbe Kühlsystem teilen. **Digital.** Ein Identity Provider hinter jeder Anwendung. Eine DNS Authority. Ein Cloud-Account, in dem Produktion und Backup liegen. Eine Deployment-Pipeline, von der jede Wiederherstellung abhängt. **Operativ.** Ein Team, das weiß, wie das System wiederhergestellt wird. Ein Anbieter, der berechtigt ist, es zu reparieren. Ein Administrator, der die Schlüssel zurückholen kann. **Institutionell.** Eine Autorität, deren Zustimmung nötig ist, bevor jemand handeln kann. Eine Übergabe zwischen Organisationen ohne Fallback, wenn sie scheitert. Eine Beschaffungsregel, die Notfallsubstitution unmöglich macht. **Redundanz ohne getrennte Failure Domains ist keine Resilienz.** Die Arbeit besteht nicht darin, Kopien zu zählen, sondern herauszufinden, welche scheinbar unabhängigen Pfade noch gemeinsam ausfallen können. ## Eine absichtliche Art zu degradieren {#eine-absichtliche-art-zu-degradieren} Kontinuität bedeutet nicht immer vollen Service. Manchmal ist das richtige Ergebnis ein reduzierter Dienst, der die wesentliche Funktion am Leben hält, während der Rest wartet. Das funktioniert nur, wenn der degradierte Zustand im Voraus entworfen wurde. Für jede wesentliche Funktion weiß eine resiliente Organisation: - welche Kapazität verfügbar bleiben muss und welche ausgesetzt werden kann; - wie lange der degradierte Zustand tragfähig sein muss; - welche Entscheidungen weiterhin getroffen werden können und von wem; - welche Daten verlässlich bleiben müssen; - welche Sicherheits- oder Schutzbedingungen nicht gelockert werden dürfen; - wer berechtigt ist, den degradierten Zustand zu betreten und zu verlassen. Ohne diese Grenzen kann ein System als „verfügbar“ gemeldet werden, obwohl es die Funktion, auf die es ankommt, nicht mehr erfüllt. **Resilienz ist nicht die Abwesenheit von Degradation. Sie ist die Fähigkeit, absichtlich zu degradieren, ohne die wesentliche Funktion zu verlieren.** ## Jede Resilienzaussage hat eine Grenze {#jede-resilienzaussage-hat-eine-grenze} Ein erfolgreicher Resilienztest beweist etwas. Selten beweist er so viel, wie später angenommen wird. Ein Dienst, der den Verlust eines Netzwerkpfads überlebt, hat nicht gezeigt, dass er einen Stromausfall überlebt. Ein Standort, der eine Stunde auf Notstrom läuft, hat nicht gezeigt, dass er drei Tage durchhält. Eine Wiederherstellungsübung, die bei verfügbaren normalen Kommunikations- und Identitätsdiensten durchgeführt wurde, hat nicht gezeigt, dass Wiederherstellung funktioniert, wenn diese Dienste Teil des Vorfalls sind. Deshalb verbinden wir jede Resilienzaussage mit den Bedingungen, unter denen sie gilt. Wir nennen das die **Failure Envelope**: was zu Beginn verfügbar war, was entfernt wurde, für wie lange, welcher Mindestdienst erwartet wurde, was tatsächlich geschah, wovon das Ergebnis weiterhin abhing und wie der Normalbetrieb wiederhergestellt wurde. Ein erfolgreiches Ergebnis innerhalb einer Envelope beweist keine Resilienz außerhalb davon. Wir bevorzugen eine enge, reproduzierbare Aussage gegenüber einem breiten Label, das es nicht ist. Hier hängt Resilienz auch von Urteilsfähigkeit ab. Testberichte, Anbietergarantien und Zertifizierungen machen alle Aussagen über Resilienz. Eine Organisation, die sie beurteilen kann, stellt jedes Mal die richtige Frage: Unter welchen Bedingungen wurde das gezeigt, und sind das die Bedingungen, mit denen wir tatsächlich zu tun haben? Eine Organisation, die diese Frage nicht stellen kann, vertraut auf ein Label, wie detailliert der Bericht dahinter auch aussieht. ## Geplant, getestet und bewiesen sind verschiedene Dinge {#geplant-getestet-und-bewiesen-sind-verschiedene-dinge} Nicht jede Resilienzevidenz hat dasselbe Gewicht. Wir unterscheiden vier Arten. **Design** beschreibt, was beabsichtigt ist: Architekturdiagramme, Routenpläne, Wiederherstellungsverfahren. Es ist nötig, weil es sagt, was getestet werden soll. Es ist kein Beweis dafür, dass das System sich so verhält. **Konfiguration** beschreibt, wie das System tatsächlich verbunden und eingestellt ist. Sie kann vom Design abweichen, und diese Abweichung ist selbst ein Risiko. **Übung** zeichnet auf, was passiert ist, als eine echte Abhängigkeit absichtlich entfernt oder degradiert wurde. Hier beginnt eine Aussage sich von Absicht zu Demonstration zu bewegen. **Incident-Evidenz** zeigt, was passiert ist, als etwas tatsächlich ausfiel. Sie enthüllt oft Abhängigkeiten, die keine Übung vorhergesehen hatte, aber die Bedingungen sind unkontrolliert und Aufzeichnungen können unvollständig sein. Europäische Regulierung bewegt sich in dieselbe Richtung. DORA verpflichtet Finanzunternehmen, ihre digitale operationale Resilienz zu testen, einschließlich szenariobasierter Tests, statt sich nur auf dokumentierte Pläne zu verlassen. Das Prinzip gilt weit über Finance hinaus: **Geplante Fähigkeit ist keine nachgewiesene Fähigkeit.** ## Der Test endet, wenn der Normalbetrieb zurück ist {#der-test-endet-wenn-der-normalbetrieb-zurück-ist} Ein System, das die erste Phase eines Ausfalls überlebt, aber nicht sauber zum Normalbetrieb zurückkehren kann, hat den Resilienzzyklus nicht abgeschlossen. Wiederherstellung hat ihre eigenen Abhängigkeiten, und das sind oft genau die Abhängigkeiten, die niemand untersucht hat. Wie wird der Ausfall erkannt? Wer ist zum Handeln berechtigt? Welcher Dienst kommt zuerst zurück? Welche Daten sind nach einer Phase gesplitteten oder degradierten Betriebs maßgeblich, und wie werden sie abgeglichen? Welche Credentials und Schlüssel werden gebraucht, und sind sie erreichbar? Hängt Wiederherstellung von demselben Pfad ab, der ausgefallen ist? Ein Backup, das startet, aber seine Daten nicht abgleichen kann, kann Verfügbarkeit bewahren und Integrität beschädigen. Ein Standort, der isoliert arbeiten kann, aber nicht sicher wieder verbunden werden kann, hat den Ausfall nur verschoben. **Der Test endet, wenn die wesentliche Funktion zu ihrem definierten Normalzustand zurückgekehrt ist, nicht wenn der Fallback startet.** ## Ausfälle respektieren keine Organigramme {#ausfälle-respektieren-keine-organigramme} Die folgenschwersten Ausfälle überschreiten die Grenzen, die Organisationen zwischen Abteilungen, Systemen und Zuständigkeiten ziehen. Ein Stromausfall wird zu einem Kommunikationsausfall. Ein Kommunikationsausfall wird zu einem Identitätsausfall. Ein Identitätsausfall hindert Operatoren daran, die Tools zu erreichen, die sie für die Wiederherstellung brauchen. [Der großflächige Stromausfall auf der Iberischen Halbinsel im April 2025](https://www.entsoe.eu/publications/blackout/28-april-2025-iberian-blackout/) zeigte, wie schnell ein Ausfall in einem System auf Verkehr, Telekommunikation und Einzelhandelszahlungen übergreift, die jeweils separat geplant werden. Deshalb ist eine Abhängigkeitskarte, die bei IT-Systemen endet, unvollständig. Sie muss auch Menschen, Autoritäten, Energie, Kommunikation, Logistik und physischen Zugang umfassen, die nötig sind, um eine Funktion zu betreiben und zurückzubringen. Daraus folgen zwei Konsequenzen für unsere Arbeitsweise. **Korrelation ist wichtiger als ein einzelnes Signal.** Eine Kommunikationsanomalie, eine Unregelmäßigkeit in der Stromversorgung oder eine logistische Störung kann einzeln Routine sein. Dieselben drei rund um dieselbe Funktion zur selben Zeit sind es nicht. Resilienz hängt weniger davon ab, mehr Signale zu sammeln, als davon zu sehen, wann Schwächen in verschiedenen Domänen beginnen zusammenzufallen. **Richtung ist ebenso wichtig wie Position.** Ein statischer Score kann verbergen, ob sich ein System verbessert oder verschlechtert. Eine Organisation, die ordentlich funktioniert, aber stetig schwächer wird, kann riskanter sein als eine, die schlecht dasteht, sich aber schnell verbessert. Dieselbe Logik gilt für Funktionen, die nationale Grenzen überschreiten. Autorität verändert sich an der Grenze, Verfahren unterscheiden sich, und Ausrüstung oder Daten können schneller über die Grenze gelangen als rechtliche Zuständigkeit. Grenzüberschreitende Resilienz kann nicht vollständig innerhalb einer einzigen Verwaltung bewiesen werden. Die Übung muss die Grenze selbst einschließen. ## Wissen kann ein Single Point of Failure sein {#wissen-kann-ein-single-point-of-failure-sein} Bei Resilienz geht es nicht nur um Assets. Eine Funktion kann fragil werden, weil die Fähigkeit, sie wiederherzustellen, bei einer Person, einem Auftragnehmer oder einem Team liegt. Sichtbar ändert sich nichts, wenn diese Person in Rente geht oder der Vertrag endet. Das erste Signal ist meist der nächste Vorfall, wenn niemand mehr weiß, warum das System so konfiguriert wurde. Deshalb nehmen wir Wissen, Fachfähigkeit und institutionelles Gedächtnis in Resilienzarbeit auf, wenn sie für Kontinuität oder Wiederherstellung wesentlich sind. Wer weiß, wie diese Funktion wiederhergestellt wird? Wurde dieses Wissen von mehr als einer Person in der Praxis ausgeübt? Könnte die Organisation es wieder aufbauen, wenn es verloren ginge? Hier berührt Resilienz unsere Arbeit an [Fähigkeitstransfer](/de/topics/capability-transfer). Ein System, das einen technischen Ausfall überlebt, aber nicht den Weggang eines einzigen Spezialisten, ist nicht resilient. Es hat Glück. ## Wie wir gemeinsam daran arbeiten {#wie-wir-gemeinsam-daran-arbeiten} Unser Ansatz zur Resilienz folgt derselben Reihenfolge wie der Rest unserer Arbeit: zuerst verstehen, dann entwerfen, dann unter Bedingungen testen, die zählen. **Die Funktion benennen.** Vereinbaren, was weiterlaufen muss und auf welchem Mindestniveau. **Die Abhängigkeiten kartieren.** Über physische, digitale, operative, institutionelle und menschliche Ebenen hinweg, und die Failure Domains finden, die sie teilen. **Den degradierten Zustand und den Wiederherstellungspfad entwerfen.** Im Voraus entscheiden, was ausgesetzt werden kann, was bleiben muss, wer entscheidet und wie der Normalbetrieb zurückkehrt. **Innerhalb einer benannten Envelope testen.** Eine echte Abhängigkeit entfernen oder degradieren, aufzeichnen, was passiert, und genau sagen, was das Ergebnis beweist und was nicht. **Urteilsfähigkeit hinterlassen.** Die Organisation soll mit Menschen enden, die den nächsten Testbericht, die nächste Anbietergarantie oder den nächsten Vorfall selbst beurteilen können. Wenn wir gemeinsam mit einem Partner eine wesentliche Funktion betrachten, arbeiten wir typischerweise diese Fragen durch: | Frage | Was sie sichtbar macht | | --- | --- | | Welche Funktion muss weiterlaufen, und auf welchem Mindestniveau? | Wofür Resilienz tatsächlich da ist. | | Wovon hängt sie auf jeder Ebene ab? | Der vollständige Dependency Graph, nicht nur IT. | | Welche davon können gemeinsam ausfallen? | Die tatsächlichen Failure Domains. | | Welches Szenario testen wir, und wie lange? | Die Envelope der Aussage. | | Wer kann während des Ausfalls handeln? | Ob Autorität den Vorfall überlebt. | | Was geschah tatsächlich, als wir es testeten? | Der Unterschied zwischen Design und Verhalten. | | Wie wurde der Normalbetrieb wiederhergestellt? | Ob der Zyklus abgeschlossen wurde. | | Welche Änderung würde dieses Ergebnis ungültig machen? | Wann die Evidenz abläuft. | Die letzte Frage ist wichtiger, als sie scheint. Eine geänderte Route, ein Identity Provider, eine Stromregelung, ein Anbieter oder ein Verfahren kann ein früheres Ergebnis ungültig machen, ohne dass sich der Name des Dienstes ändert. Resilienzevidenz hat einen Lebenszyklus und muss überprüft werden, wenn sich das zugrunde liegende System ändert. ## Wo wir vorsichtig sind {#wo-wir-vorsichtig-sind} Wir halten uns an einige Verpflichtungen darüber, was wir behaupten. Wir nennen ein System nicht resilient, weil es ein Backup hat, und wir nennen zwei Systeme nicht unabhängig, bevor wir verstehen, was sie teilen. Wir verallgemeinern einen erfolgreichen Komponententest nicht zu einer Aussage über das gesamte System und behandeln eine Simulation nicht als Beweis physischen Verhaltens. Wir präsentieren geplante Fähigkeit nicht als erreichte Fähigkeit. Wo etwas entworfen, aber noch nicht getestet ist, sagen wir das. Wir behandeln Wiederherstellung nicht als Nachgedanken und ersetzen ein Gefühl für Richtung nicht durch einen einzigen Score. Und wir nennen nichts resilient, ohne Funktion, Ausfallbedingung, Grenze und Evidenz zu benennen. * * * ## Weiterführende Literatur {#weiterführende-literatur} - [Richtlinie (EU) 2022/2557 (CER)](https://eur-lex.europa.eu/eli/dir/2022/2557/oj), über die Resilienz kritischer Einrichtungen. - [Verordnung (EU) 2022/2554 (DORA)](https://eur-lex.europa.eu/eli/reg/2022/2554/oj), über digitale operationale Resilienz im Finanzsektor. **Verwandte Themen:** [Souveränität](/de/topics/sovereignty) · [Fähigkeitstransfer](/de/topics/capability-transfer) · [Frühwarnung](/de/topics/early-warning) * * * ## Änderungen an dieser Position {#änderungen-an-dieser-position} - 24. September 2026 — Erstmals veröffentlicht. Materielle Änderungen werden hier mit Datum aufgeführt. Korrekturen an Formulierungen oder Links nicht. ## Auf dieser Seite {#auf-dieser-seite} ESFI — civilization infrastructure · https://esfi.eu