Business Continuity ManagementBegriffe und Zusammenhänge

Christian Horres

Experte für Business Continuity Management (BCM), Risikomanagement und organisatorische Resilienz, insbesondere im Umfeld kritischer Infrastrukturen. Sein Schwerpunkt liegt auf Business Impact Analysen (BIA), Risikoanalysen sowie dem Aufbau und der Weiterentwicklung von BCM- und Krisenmanagementstrukturen. Im NOVELEDGE-Netzwerk unterstützt er Organisationen bei der praktischen Umsetzung resilienter Strukturen unter Berücksichtigung internationaler Standards wie ISO 22301, ISO 27001 und ISO 31000 und geltender Regulatorik.

Im Business Continuity Management (BCM) existieren zahlreiche Kennzahlen, die häufig synonym verwendet oder miteinander verwechselt werden. Insbesondere die Begriffe

Recovery Time Objective (RTO), 
Recovery Point Objective (RPO), 
Recovery Time Actual (RTA) sowie 
Service Level Agreement (SLA) 

beschreiben unterschiedliche Sachverhalte und erfüllen jeweils eine eigene Funktion innerhalb des BCM.

Eine saubere Trennung dieser Begriffe ist nicht nur für eine qualitativ hochwertige Business Impact Analyse (BIA) erforderlich, sondern auch für die Entwicklung geeigneter Wiederherstellungsstrategien sowie für die Steuerung interner und externer Dienstleister.

Ausgangspunkt

Eine der häufigsten Fehlannahmen besteht darin, dass Wiederherstellungszeiten von der IT oder von Dienstleistern vorgegeben werden.

Tatsächlich verhält es sich genau umgekehrt.

Die maximal zulässigen Wiederherstellungszeiten entstehen aus den Anforderungen des Geschäfts.

Der Ausgangspunkt ist deshalb immer das mit Business mit der Business Impact Analyse.

Diese beantwortet zunächst folgende Fragen:

• Wie lange darf ein Geschäftsprozess maximal ausfallen?
• Welche Auswirkungen entstehen bei zunehmender Ausfalldauer?
• Ab welchem Zeitpunkt entstehen nicht mehr akzeptable Schäden?

Aus diesen Bewertungen ergibt sich die maximale tolerierbare Ausfallzeit eines Geschäftsprozesses. Erst anschließend wird untersucht, welche Ressourcen erforderlich sind, um diese Anforderungen einzuhalten.

Das Business definiert somit die Anforderungen. Die Ressourcen müssen diese Anforderungen erfüllen. Nicht umgekehrt.

Die Abkürzungen auf einen Blick

Deutsch und englisch

In deutschen Projekten treffen zwei Begriffswelten aufeinander: die englischen Kürzel aus ISO 22301^[1] und die deutschen Bezeichnungen aus dem BSI-Standard 200-4^[2]. Gemeint ist dasselbe – gesucht wird aber mal so, mal so. Die folgende Tabelle stellt beides nebeneinander.

Die deutschen Bezeichnungen und ihre Zuordnung zu den englischen Kürzeln stammen aus dem BSI-Standard 200-4: MTPD, RTO, RPO und Notbetriebsniveau aus dem Kapitel zur Business-Impact-Analyse, RTA und RPA aus dem Kapitel zum Soll-Ist-Vergleich.

Auch die deutschen Bezeichnungen sind nicht einheitlich. Die deutsche Fassung der ISO 22301 übersetzt dieselben englischen Kürzel anders als das BSI^[2]:

Wer beide Dokumente nebeneinander legt, sollte das wissen: Dieselbe Kenngröße heißt beim BSI „Wiederanlaufzeit“ und in der deutschen ISO-Fassung „Wiederherstellungszeitpunkt“. In Ausschreibungen und Auditberichten führt das regelmäßig zu Rückfragen.

Noch ein Unterschied: RPO und MBCO kommen in der Norm selbst gar nicht vor. Die ISO 22301 nennt MTPD und RTO nur in zwei Anmerkungen zur Business-Impact-Analyse; ihre Begriffsdefinitionen bezieht sie aus der Vokabularnorm ISO 22300^[2]. Wer also sagt „RPO nach ISO 22301″, verweist auf etwas, das dort nicht steht.

RTO (Recovery Time Objective)

Das Recovery Time Objective beschreibt die maximal zulässige Wiederherstellungszeit eines Geschäftsprozesses.

Das RTO beantwortet somit die Frage:

„Wie lange darf dieser Geschäftsprozess maximal unterbrochen sein?”

Dabei handelt es sich um eine Zielvorgabe des Business.

Das RTO orientiert sich ausschließlich an den Auswirkungen auf:

• Finanzen
• Kunden
• Produktion
• Lieferfähigkeit
• Rechtliche Anforderungen
• Reputation
• Sicherheit von Menschen
• Umwelt
• weitere geschäftsspezifische Auswirkungen

Das RTO ist somit keine technische Kennzahl, sondern orientiert sich an den Anforderungen der Business Prozesse. Es entsteht aus der Business Impact Analyse und wird aus der MTA (Maximal tolerierbaren Ausfallzeit) des zeitkritischen Prozesses abgeleitet.

RPO (Recovery Point Objective)

Während das RTO die Zeit bis zur Wiederherstellung beschreibt, beantwortet das RPO eine völlig andere Fragestellung. Es beschreibt den maximal zulässigen Datenverlust und beantwortet damit die Frage:

„Bis zu welchem Zeitpunkt dürfen Daten verloren gehen?”

Beispiele:

• RPO = 15 Minuten
• RPO = 1 Stunde
• RPO = 4 Stunden
• RPO = 24 Stunden

Das RPO richtet sich nach den Informationsobjekten einer Ressource die für den zeitkritischen Prozess erforderlich ist.

Dabei ist entscheidend,

• wie häufig Daten entstehen oder geändert werden,
• wie kritisch deren Verlust wäre,
• ob Daten rekonstruiert werden können,
• welche gesetzlichen Anforderungen bestehen.

Hier besteht ein enger Zusammenhang mit

• Backup-Strategien,
• Replikation,
• Datenbanken,
• Speichertechnologien,
• Hochverfügbarkeitslösungen.

Das RPO bestimmt letztlich, wie aktuell die wiederhergestellten Informationen sein müssen.

RTO und RPO beschreiben ausschließlich die Verfügbarkeit: wie lange ein Ausfall dauern darf und wie viele Daten dabei verloren gehen dürfen. Ob dieselben Daten auch vertraulich und unversehrt bleiben, beantworten die Schutzziele der Informationssicherheit.

Unterschied zwischen RTO und RPO

RTO und RPO werden häufig verwechselt. Dabei beantworten sie zwei vollkommen unterschiedliche Fragestellungen.

RTO: “Wie lange darf der Prozess ausfallen?”

RPO: “Wie viele Daten dürfen verloren gehen?”

Ein Prozess muss beispielsweise innerhalb von vier Stunden wieder laufen (RTO), gleichzeitig dürfen jedoch maximal fünf Minuten an Daten verloren gehen (RPO).

Umgekehrt kann ein Prozess erst nach 48 Stunden wieder verfügbar sein, während überhaupt kein Datenverlust akzeptiert wird.

Beide Werte müssen daher unabhängig voneinander bestimmt werden.

RTA (Recovery Time Actual)

Während das RTO eine Anforderung des Business darstellt, beschreibt die Recovery Time Actual die tatsächlich erreichbare Wiederherstellungszeit einer Ressource und beantwortet die Frage:

„Wie schnell kann diese Ressource tatsächlich wieder bereitgestellt werden?”

Dabei kann es sich beispielsweise handeln um:

• IT-Systeme
• Anwendungen
• Gebäude
• Produktionsanlagen / OT (Operation Technology)
• Personal
• Dienstleister
• Lieferanten
• Betriebsmittel oder Energieversorgung
• Kommunikationssysteme

Die RTA beschreibt somit keine Zielvorgabe, sondern eine tatsächlich erreichbare Wiederherstellungszeit.

Diese kann

• technisch,
• organisatorisch,
• personell oder
• vertraglich

begrenzt sein.

Grundregel im BCM

Eine der wichtigsten Regeln lautet:

RTA ≤ RTO

Die Wiederherstellungszeit einer Ressource darf niemals größer sein als die maximal zulässige Wiederherstellungszeit des unterstützten Geschäftsprozesses.

Ist die RTA größer als das RTO,

entsteht unmittelbar eine Versorgungslücke.

Diese muss geschlossen werden durch

• technische Maßnahmen,
• organisatorische Maßnahmen,
• Redundanzen,
• alternative Standorte,
• zusätzliche Dienstleister,
• Notfallverfahren oder
• Anpassung der BCM-Strategie.

Noveledge RPO von NOVELEDGE

SLA (Service Level Agreement)

Ein Service Level Agreement beschreibt die vertraglich zugesicherte Servicequalität.

Typische Inhalte sind:

• Verfügbarkeit
• Supportzeiten
• Reaktionszeiten
• Entstörzeiten
• Wartungsfenster
• Eskalationsprozesse

Ein SLA beschreibt jedoch nicht zwangsläufig die tatsächliche Wiederherstellungszeit nach einem Ausfall. Ein Dienstleister kann ein SLA vollständig erfüllen und dennoch die Anforderungen des BCM verletzen.

Beispielsweise:

Vertraglich zugesicherte Verfügbarkeit: 99,5 % Dies entspricht rund 44 Stunden Ausfall pro Jahr.

Ein zusammenhängender Ausfall von zwei Tagen könnte somit vertragskonform sein. Der unterstützte Geschäftsprozess besitzt jedoch ein RTO von lediglich 24 Stunden. Damit wäre das SLA zwar eingehalten, das BCM-Ziel in Form seiner RTO jedoch eindeutig verfehlt.

Deshalb ersetzt ein SLA niemals eine RTA.

Unterschied zwischen RTA und SLA

Aus BCM-Sicht muss bekannt sein, wann eine Ressource tatsächlich wieder verfügbar ist. Das SLA beantwortet lediglich, welche Leistungen der Dienstleister grundsätzlich zusichert.

Die RTA beantwortet hingegen, ob diese Ressource innerhalb der durch das Business geforderten Wiederherstellungszeit tatsächlich verfügbar gemacht werden kann.

Deshalb sollten in einer Business Impact Analyse beide Werte getrennt dokumentiert werden.

Im Rahmen einer Business Impact Analyse (BIA) sowie bei der Definition von Wiederherstellungsanforderungen ist zwischen einem Service Level Agreement (SLA) und einer Recovery Time Actual (RTA) zu unterscheiden. Beide Kennzahlen beziehen sich zwar auf die Verfügbarkeit einer Ressource oder Dienstleistung, beschreiben jedoch unterschiedliche Aspekte.

Ein SLA definiert vertraglich vereinbarte Leistungsmerkmale eines Dienstleisters. Hierzu gehören beispielsweise Verfügbarkeitswerte (z. B. 99,5 % pro Jahr), Reaktionszeiten, Supportzeiten oder Entstörungsfristen. Die Einhaltung eines SLA bedeutet jedoch nicht automatisch, dass die Anforderungen eines zeitkritischen Geschäftsprozesses erfüllt werden.

Die RTA beschreibt dagegen die tatsächliche bzw. zugesicherte Wiederherstellungszeit einer Ressource oder eines Services nach einem Ausfall. Die RTA dient aus BCM-Sicht als zentrale Kenngröße zur Bewertung, ob eine Ressource innerhalb der für den Geschäftsprozess erforderlichen Zeit wieder verfügbar gemacht werden kann.

Ein typisches Beispiel verdeutlicht den Unterschied:

Ein Dienstleister garantiert vertraglich eine jährliche Verfügbarkeit von 99,5 %. Rechnerisch entspricht dies einer zulässigen Ausfallzeit von rund 44 Stunden pro Jahr. Das SLA würde somit auch einen zusammenhängenden Ausfall von nahezu zwei Tagen erlauben, sofern die vertraglichen Bedingungen dies zulassen.

Der betroffene Geschäftsprozess besitzt jedoch einen Recovery Time Objective (RTO) von 24 Stunden. Damit muss die unterstützende Ressource spätestens innerhalb von 24 Stunden wieder verfügbar sein. In diesem Fall wäre das SLA allein nicht ausreichend, da es keine Aussage darüber trifft, wie lange ein einzelner Ausfall andauern darf. Zusätzlich muss daher eine RTA vereinbart werden, die sicherstellt, dass die Ressource innerhalb des geforderten Zeitraums wiederhergestellt wird.

Für BCM-Zwecke sollten daher sowohl SLA als auch RTA getrennt erfasst und bewertet werden:

• SLA: Vertragliche Leistungs- und Verfügbarkeitszusagen des Dienstleisters.
• RTA: Tatsächliche bzw. zugesicherte Wiederherstellungszeit nach einem Ausfall.
• RTO: Maximale tolerierbare Wiederherstellungszeit aus Sicht des Geschäftsprozesses.

Grundsätzlich gilt:

Die RTA einer Ressource muss kleiner oder gleich dem RTO des unterstützten Geschäftsprozesses sein.

Ein gutes SLA ersetzt daher keine BCM-Betrachtung. Erst die Kombination aus SLA und RTA ermöglicht die Bewertung, ob eine Ressource die Anforderungen eines zeitkritischen Geschäftsprozesses tatsächlich erfüllt.

MTPD und MTA

Der Wert, aus dem alles andere folgt

Bevor über RTO und RPO gesprochen werden kann, muss eine andere Frage beantwortet sein: Wie lange hält die Organisation den Ausfall überhaupt aus? Diese Grenze heißt im BSI-Standard 200-4 Maximal Tolerierbare Ausfallzeit (MTA), international Maximum Tolerable Period of Disruption (MTPD).

Sie legt fest, wie lange ein Geschäftsprozess maximal ausfallen darf, bevor nicht tolerierbare Auswirkungen für die Institution auftreten^[1]. Ermittelt wird sie in der Business Impact Analyse über die Bewertung des Schadenspotenzials je Geschäftsprozess – nicht über die Frage, was technisch machbar wäre.

Aus der MTPD wird anschließend das RTO abgeleitet. Dabei gilt eine Regel, die in der Praxis regelmäßig übersehen wird:

Das RTO muss zwingend kürzer sein als die MTPD.^[1]

Der Grund ist einfach: Zwischen dem Eintritt der Störung und dem Ausrufen des Notfalls vergeht Zeit – Detektion, Meldung, Entscheidung. Diese Reaktionszeit wird von der MTPD abgezogen. Wer RTO und MTPD gleichsetzt, hat die Grenze bereits gerissen, bevor der Wiederanlauf überhaupt beginnt. Der BSI-Standard 200-4 empfiehlt darüber hinaus einen zusätzlichen zeitlichen Puffer, weil gerade die Detektion zeitlich schwer vorhersagbar ist.

RPA (Recovery Point Actual)

Der tatsächliche Datenverlust

Das RPO ist eine Anforderung. Ob sie eingehalten wird, sagt es nicht. Dafür gibt es die Gegengröße: Recovery Point Actual (RPA), im BSI-Standard 200-4 als tatsächlicher Datenverlust bezeichnet.

Das Verhältnis ist dasselbe wie zwischen RTO und RTA:

• RTO und RPO sind Soll-Werte aus der Business Impact Analyse.
• RTA und RPA sind Ist-Werte aus der Realität der jeweiligen Ressource.
• Der Abgleich beider Seiten heißt im BSI-Standard 200-4 Soll-Ist-Vergleich^[1].

Eine Anforderung ist erst dann erfüllt, wenn RTA kleiner oder gleich RTO ist, RPA kleiner oder gleich RPO – und zusätzlich das festgelegte Notbetriebsniveau erreicht wird. Zwei von drei genügen nicht.

MBCO und Notbetriebsniveau

Wie viel Leistung der Notbetrieb braucht

Wiederanlauf heißt nicht Normalbetrieb. Was im Notbetrieb tatsächlich geleistet werden muss, legt das Notbetriebsniveau fest – englisch Minimum Business Continuity Objective (MBCO).

Der BSI-Standard 200-4 beschreibt es als die Festlegung, wie leistungsfähig der Notbetrieb sein soll, um einen sinnvollen Geschäftsbetrieb zu gewährleisten^[1]. Festgelegt wird es je Geschäftsprozess einzeln, entweder als Prozentwert der Normalleistung oder über eine Priorisierung einzelner Tätigkeiten.

Diese Größe entscheidet über den Aufwand. Ein Prozess, der im Notbetrieb 30 Prozent der Normallast tragen muss, braucht eine völlig andere Lösung als einer, der 90 Prozent braucht – bei identischem RTO. Wer das Notbetriebsniveau nicht festlegt, verhandelt am Ende über Kosten, ohne die Anforderung zu kennen.

MAO, WRT, MTN und MTW

Begriffe aus anderen Quellen

In Projekten tauchen weitere Kürzel auf, die im Text des BSI-Standards 200-4 nicht vorkommen. Wer sie verwendet, sollte dazusagen, worauf er sich bezieht.

• MAO (Maximum Acceptable Outage): begegnet in englischsprachiger Literatur als Bezeichnung für dieselbe Grenze wie MTPD. Weder die DIN EN ISO 22301 noch der BSI-Standard 200-4 führen den Begriff.^[1][2]
• WRT (Work Recovery Time): die Zeit nach dem technischen Wiederanlauf, bis fachlich wieder gearbeitet werden kann – Nacherfassung, Abgleich, Freigaben. Ein Praxisbegriff aus dem IT-Notfallmanagement; in keiner der hier herangezogenen Normen ist er definiert. Der amerikanische NIST-Leitfaden führt an vergleichbarer Stelle die Maximum Tolerable Downtime (MTD).^[3]
• MTN (maximal tolerierbare Notbetriebszeit) und MTW (maximal tolerierbare Wiederherstellungszeit): beides Begriffe aus dem älteren BSI-Standard 100-4. Dort ergibt sich die MTW als Summe aus Wiederanlaufzeit und MTN.^[4]

Für die eigene Dokumentation empfiehlt es sich, einen Begriffssatz festzulegen und ihn durchzuhalten. Die meisten Missverständnisse in BCM-Projekten entstehen nicht an den Zahlen, sondern daran, dass zwei Beteiligte dasselbe Kürzel unterschiedlich verstehen.

Woher die Begriffe kommen

BSI-Standard 200-4 und ISO 22301

Zwei Quellen prägen die Begriffe im deutschsprachigen Business Continuity Management:

• BSI-Standard 200-4: liefert die deutschen Bezeichnungen und ordnet sie den englischen Kürzeln zu. MTPD, RTO, RPO und das Notbetriebsniveau werden im Kapitel zur Business-Impact-Analyse eingeführt, RTA und RPA im Kapitel zum Soll-Ist-Vergleich.
• ISO 22301: die internationale Norm für Business-Continuity-Managementsysteme. Sie arbeitet durchgängig mit den englischen Begriffen.
• NIST SP 800-34: der amerikanische Leitfaden zur Notfallplanung. Er definiert RTO und RPO ebenfalls und führt zusätzlich die Maximum Tolerable Downtime (MTD)^[3]. Frei verfügbar – deshalb stammen viele englischsprachige Erklärungen im Netz letztlich von dort.
• ISO 22316: beschreibt organisatorische Resilienz mit Grundsätzen und Attributen, ohne eigene Zeitkennzahlen. Der BSI-Standard 200-4 verweist selbst auf sie^[5]. Sie liefert den Rahmen, in dem die Kennzahlen überhaupt einen Zweck haben.

Wie ähnlich sich die Quellen sind, zeigt der Blick in den NIST-Leitfaden. Dort heißt die Ausfallgrenze des Geschäftsprozesses Maximum Tolerable Downtime (MTD): die Zeit, die die verantwortliche Stelle für eine Unterbrechung insgesamt hinzunehmen bereit ist. Das RTO ist dort die Zeit, die eine einzelne Systemressource ausfallen darf, bevor andere Ressourcen, die gestützten Geschäftsprozesse und damit die MTD beeinträchtigt werden. Und weil das RTO sicherstellen muss, dass die MTD nicht überschritten wird, muss es in aller Regel kürzer sein als die MTD – dieselbe Ableitungsregel wie zwischen MTPD und RTO im BSI-Standard 200-4, nur mit anderen Namen. Das RPO beschreibt NIST als den Zeitpunkt vor der Störung, auf den sich die Daten mit der jüngsten vorhandenen Sicherung zurückholen lassen.

Beide beschreiben dieselbe Logik. Wer nach „RPO Abkürzung“ sucht und wer nach „maximal zulässiger Datenverlust“ sucht, meint denselben Wert.

Erhoben werden diese Kenngrößen nicht am Schreibtisch, sondern in der Business Impact Analyse. Wie das strukturiert abläuft, zeigen die Business Impact Analyse Vorlage als Excel-Template und die Variante Business Impact Analyse durchführen lassen. Fachlicher Ansprechpartner ist Christian Horres.

Typische Fehler

In der Praxis treten regelmäßig dieselben Fehler auf:

• RTO wird durch die IT vorgegeben.
• SLA wird mit Wiederherstellungszeit gleichgesetzt.
• RPO wird als Backup-Intervall verstanden, ohne den tatsächlichen Datenverlust zu betrachten.
• Ressourcen werden bewertet, bevor die Geschäftsprozesse analysiert wurden.
• Wiederherstellungszeiten werden geschätzt, anstatt sie technisch nachzuweisen.
• Abhängigkeiten zwischen Ressourcen bleiben unberücksichtigt.

Diese Fehler führen häufig dazu, dass Business Continuity Pläne zwar formal vorhanden sind, im Ernstfall jedoch die eigentlichen Geschäftsanforderungen nicht erfüllen.

Die richtige Reihenfolge

Ein methodisch sauberes BCM folgt stets derselben Reihenfolge:

1. Geschäftsprozesse identifizieren.
2. Abhängigkeiten bewerten.
3. MTPD/MTA bestimmen.
4. RTO aus den Business-Anforderungen ableiten.
5. Benötigte Ressourcen identifizieren.
6. Für jede Ressource RTA und – soweit relevant – RPO ermitteln.
7. SLA und RTA mit den Business-Anforderungen vergleichen.
8. Abweichungen identifizieren.
9. Recovery-Strategien entwickeln.
10. Business Continuity Plans erstellen und regelmäßig testen.

Diese Reihenfolge stellt sicher, dass sich technische und organisatorische Maßnahmen konsequent an den Anforderungen des Geschäfts orientieren und nicht umgekehrt.

Fazit

Das Business definiert die Anforderungen. Die Ressourcen müssen diese Anforderungen erfüllen.

Das RTO entsteht aus den Auswirkungen eines Prozessausfalls und beschreibt die maximal zulässige Wiederherstellungszeit eines Geschäftsprozesses. Das RPO legt fest, wie viel Datenverlust akzeptabel ist und dient als Grundlage für Backup- und Replikationsstrategien. Die RTA beschreibt die tatsächlich erreichbare Wiederherstellungszeit einer Ressource und muss stets kleiner oder gleich dem RTO des unterstützten Prozesses sein. Das SLA regelt schließlich die vertragliche Leistungserbringung eines Dienstleisters, ersetzt jedoch weder die RTA noch garantiert es automatisch die Einhaltung der BCM-Anforderungen.

Ein reifes Business Continuity Management betrachtet diese Kennzahlen daher nicht isoliert, sondern verbindet sie systematisch mit den Ergebnissen der Business Impact Analyse. Erst durch diese Verknüpfung lassen sich belastbare Recovery-Strategien entwickeln und die tatsächliche Resilienz einer Organisation bewerten.

Quellen

Die Begriffe und Zusammenhänge in diesem Beitrag stützen sich auf die folgenden Quellen. Aus kostenpflichtigen Normen wird nicht wörtlich zitiert; ihre Inhalte sind sinngemäß wiedergegeben.

1. DIN EN ISO 22301:2020-06 – Sicherheit und Resilienz – Business Continuity Management System – Anforderungen (ISO 22301:2019). Deutsche Fassung EN ISO 22301:2019. Herausgeber: DIN Deutsches Institut für Normung e. V., Berlin. Kostenpflichtig über den Normenhandel. ↑
2. Bundesamt für Sicherheit in der Informationstechnik: BSI-Standard 200-4 – Business Continuity Management. Version 1.0, Mai 2023. Herangezogen: Kapitel 7 (Business-Impact-Analyse) und Kapitel 8 (Soll-Ist-Vergleich). Frei verfügbar beim BSI. ↑
3. National Institute of Standards and Technology: NIST Special Publication 800-34 Rev. 1 – Contingency Planning Guide for Federal Information Systems. 2010. Frei verfügbar bei NIST. ↑
4. Bundesamt für Sicherheit in der Informationstechnik: Online-Kurs Notfallmanagement, Abschnitt 3.4 „Wiederanlaufparameter bestimmen“ und Glossar, auf Grundlage des BSI-Standards 100-4. Frei verfügbar beim BSI. ↑
5. ISO 22316:2017 – Security and resilience – Organizational resilience – Principles and attributes. Herausgeber: International Organization for Standardization, Genf. Kostenpflichtig über den Normenhandel. ↑