Verfügbarkeit

Kurzdefinition

Verfügbarkeit beschreibt im Kontext der Informationssicherheit den Zustand, dass Informationen, Anwendungen und unterstützende Ressourcen zum benötigten Zeitpunkt nutzbar sind. Sie umfasst technische, organisatorische und vertragliche Vorkehrungen, um Ausfälle zu vermeiden, Auswirkungen zu begrenzen und einen definierten Wiederanlauf sicherzustellen.

Einordnung auf einen Blick

Detaillierte Erklärung

Verfügbarkeit ist neben Vertraulichkeit und Integrität ein Grundpfeiler der Informationssicherheit (CIA-Triade). Während Vertraulichkeit unbefugten Zugriff verhindert und Integrität Unversehrtheit sicherstellt, adressiert Verfügbarkeit die rechtzeitige Nutzbarkeit. Sie betrifft Menschen, Prozesse, Technologie und Lieferketten gleichermaßen.

Im ISMS-Kontext wird Verfügbarkeit nicht nur als „Uptime“ technischer Systeme verstanden. Sie umfasst Anforderungen der Geschäftsprozesse (z. B. Bestellannahme, Produktion, Kundenservice), die durch IT-Services, Daten, Netzwerke, Gebäudeinfrastruktur, Stromversorgung und Dienstleister ermöglicht werden. Ein System kann technisch laufen, aber ohne Schlüsselpersonal, Netzwerkzugang oder Drittanbieter-Schnittstelle faktisch nicht verfügbar sein.

Verfügbarkeit wird durch Anforderungen konkretisiert, häufig als Service-Level (z. B. maximale Ausfallzeit je Monat) und als Wiederanlauf- (RTO) sowie Wiederherstellungspunkte (RPO). RTO beschreibt die Zielzeit bis zur Wiederaufnahme eines Dienstes, RPO den maximal tolerierbaren Datenverlust durch zeitliche Nähe des letzten konsistenten Wiederherstellungspunkts.

Maßnahmen (engl. „Controls“) zur Verfüg­barkeit reichen von Redundanz, Clustering, Lastverteilung, Datenreplikation und Backups über Kapazitäts- und Patch-Management bis zu organisatorischen Regelungen wie Wartungsfenstern, Betriebsbereitschaft (Standby/On-Call), Eskalationswegen und Lieferanten-SLAs. Entscheidend ist die Eignung der Maßnahmen zur Risikobehandlung und die Wirksamkeit im Betrieb.

Verfügbarkeit ist dynamisch: Releases, Lastspitzen, neue Abhängigkeiten oder Lieferantenwechsel verändern das Risikoprofil. Daher sind Monitoring, Ereignis- und Problemmanagement, Testen/Üben sowie kontinuierliche Verbesserung integrale Bestandteile einer tragfähigen Verfügbarkeitssteuerung.

Relevanz für ISO 27001:2022

Verfügbarkeit zieht sich durch mehrere ISMS-Bausteine. Anforderungen werden idealerweise aus einer Business Impact Analysis (BIA) oder vergleichbaren Prozesskritikalitätsbewertungen abgeleitet und in Richtlinien, SLAs und Betriebsverfahren verankert. In der Risikobeurteilung werden verfügbarkeitsbezogene Bedrohungen (Hardwarefehler, menschliche Fehler, Cyberangriffe, Lieferantenausfall, Naturereignisse) identifiziert und mit geeigneten Maßnahmen behandelt.

Die SoA (Erklärung zur Anwendbarkeit) dokumentiert, welche Maßnahmen zum Schutz der Verfügbarkeit gewählt wurden und warum. Im Betrieb unterstützen Konfigurations-, Änderungs- und Patch-Management die Stabilität; Backup-, Wiederherstellungs- und Notfallmaßnahmen adressieren Daten- und Dienstverfügbarkeit. Lieferanten- und Cloud-Management sind relevant, da Verfügbarkeit oft von externen Services abhängt. Interne Audits und Managementbewertungen prüfen, ob Anforderungen erfüllt, Kennzahlen erreicht und Lessons Learned umgesetzt werden.

Umsetzung in der Praxis

Schritt-für-Schritt

1. Kritikalität bestimmen: Geschäftsprozesse und unterstützende Assets erfassen; Kritikalitätsklassen definieren (z. B. hoch/mittel/niedrig).
2. Anforderungen ableiten: Für kritische Services RTO, RPO, zulässige Ausfallfenster und Uptime-Ziele festlegen; Wartungsfenster definieren.
3. Risiken analysieren: Bedrohungen, Schwachstellen und Auswirkungen für die Verfügbarkeit bewerten; Abhängigkeiten (Personal, Gebäude, Netz, Lieferanten) berücksichtigen.
4. Maßnahmen planen: Redundanz/Faulover, Backup- und Replikationskonzepte, Kapazitäts- und Patch-Strategie, Härtung, physische Infrastruktur (USV, Klimatisierung) sowie organisatorische Regelungen (SLAs, Bereitschaften).
5. Lieferanten steuern: Verfügbarkeitsanforderungen vertraglich regeln; Leistungskennzahlen, Support-Zeiten, Eskalationen und Exit-Szenarien festlegen.
6. Implementieren & dokumentieren: Architektur- und Betriebsdokumente, Standard Operating Procedures (SOP), Wiederanlauf- und Wiederherstellungspläne, Notfallkontakte.
7. Überwachen: Telemetrie/Monitoring, synthetische Tests, Alerting, Incident-/Problemmanagement, Kapazitätsberichte.
8. Üben & testen: Restore-Tests, Failover-Übungen, Notfallübungen, Lieferantentests; Ergebnisse nachverfolgen.
9. Verbessern: Kennzahlen und Incidents auswerten; Maßnahmen, SLAs und Pläne anpassen; Managementreview speist neue Ziele.

Mindestumfang (Checkliste)

• RTO/RPO für kritische Services definiert und freigegeben.
• Regelmäßige, protokollierte Backup-/Restore-Tests.
• Monitoring mit definierten Grenzwerten und Alarmwegen.
• Geklärte Betriebsbereitschaft (Bereitschaftsdienst/Eskalation).
• Vereinbarte Wartungsfenster und Downtime-Kommunikation.
• Lieferanten-SLAs mit messbaren KPIs und Reports.
• Dokumentierte Wiederanlauf- und Wiederherstellungsverfahren.
• Periodische Notfallübungen mit Lessons Learned.

Beispiel aus der Praxis

Ausgangslage: Ein mittelständisches Handelsunternehmen betreibt ein zentrales ERP mit Lagerverwaltung. Bereits kurze Ausfälle führen zu Lieferverzögerungen und Vertragsstrafen. Bisher existieren tägliche Backups, aber keine klaren RTO/RPO, keine geprüften Wiederanlaufpläne und keine formalen SLAs mit dem Hosting-Partner.

Entscheidung/Umsetzung:

• BIA identifiziert ERP/LVS als hochkritisch (RTO 4 h, RPO 15 min).
• Architektur wird auf aktives Failover mit Datenbankreplikation erweitert; Netzwerk-Redundanz und USV ergänzt.
• Wartungsfenster samstags 22–24 Uhr, Kommunikation über Standard-Template.
• Lieferantenvertrag um Verfügbarkeits-SLA (99,9 %), Reaktions-/Behebungszeiten und Pönalen erweitert.
• Restore- und Failover-Tests halbjährlich, Notfallübung jährlich.

Dokumentation/Nachweise im ISMS:

• Anforderungsprofil inkl. RTO/RPO, SoA mit ausgewählten Maßnahmen, Betriebs- und Notfallhandbuch, Monitoring-Dashboards und Monatsreports, Testprotokolle, Lieferantenreporting.

Typische Audit-Fragen:

• Wie wurden RTO/RPO bestimmt und genehmigt?
• Welche Nachweise belegen die Wirksamkeit der gewählten Maßnahmen (z. B. Restore-/Failover-Tests)?
• Wie wird die Erfüllung der Verfügbarkeits-SLAs überwacht und bei Abweichungen eskaliert?
• Welche Single Points of Failure bestehen und wie sind sie adressiert?
• Wie werden Änderungen (Releases) auf Verfügbarkeitseinflüsse bewertet?

Häufige Fehler & Missverständnisse

• Nur Uptime betrachten. Problem: Prozessverfügbarkeit ignoriert Abhängigkeiten. Besser: Ende-zu-Ende-Sicht inkl. Personal, Netz, Lieferanten.
• RTO/RPO nicht definiert. Problem: Maßnahmen sind beliebig und teuer. Besser: Geschäftliche Anforderungen zuerst festlegen.
• Backups ohne Restore-Test. Problem: Scheinsicherheit. Besser: Regelmäßige, protokollierte Wiederherstellungen.
• Kein Änderungsmanagement. Problem: Releases verursachen Ausfälle. Besser: Risiko-/Rollback-Bewertung, Wartungsfenster, Freigaben.
• Unklare Lieferanten-SLAs. Problem: Lücken in Verantwortung und KPIs. Besser: Präzise SLAs inkl. Messung, Eskalation, Pönalen.
• Single Point of Failure übersehen. Problem: Totalausfall bei Komponentendefekt. Besser: Redundanz, Failover, regelmäßige Resilienz-Reviews.
• Monitoring ohne klare Grenzwerte. Problem: Späte Erkennung, Alarmmüdigkeit. Besser: SLOs/SLIs, Triage, runbooks.
• Keine Kommunikationspläne. Problem: Chaos bei Ausfällen. Besser: Templates, Verantwortlichkeiten, Stakeholder-Listen.

Abgrenzung zu ähnlichen Begriffen

Abgrenzung: Verfügbarkeit vs. Zuverlässigkeit

Zuverlässigkeit beschreibt störungsarmen Betrieb über Zeit (Fehlerfreiheit). Verfügbarkeit fokussiert die rechtzeitige Nutzbarkeit; auch ein häufig ausfallendes System kann durch schnelles Failover „verfügbar“ erscheinen. Kriterien: mittlere Reparaturzeit (MTTR) und mittlere Zeit zwischen Ausfällen (MTBF) beeinflussen beide, aber Zielgrößen unterscheiden sich.

Abgrenzung: Verfügbarkeit vs. Resilienz

Resilienz meint die Fähigkeit, Störungen zu absorbieren und sich zu erholen. Verfügbarkeit ist ein Zielzustand, Resilienz ein Mittel dahin. Maßnahmen wie Redundanz, Chaos-Tests und georedundante Replikation stärken Resilienz und sichern dadurch Verfügbarkeit.

Abgrenzung: Verfügbarkeit vs. Kapazität

Kapazität betrifft Leistungsfähigkeit (z. B. Transaktionen pro Sekunde). Ein Dienst kann verfügbar, aber wegen Kapazitätsengpässen praktisch unbenutzbar sein. Daher gehören Kapazitätsplanung und -überwachung zur Verfügbarkeitssteuerung, sind jedoch nicht identisch.

Abgrenzung: Verfügbarkeit vs. Business Continuity

Business Continuity fokussiert die Aufrechterhaltung kritischer Prozesse bei gravierenden Störungen oder Katastrophen. Verfügbarkeit ist Bestandteil hiervon, insbesondere im operativen Tagesgeschäft; Business Continuity deckt zudem Strategien, Alternativprozesse und Wiederanlauf auf Organisationsebene ab.

Abgrenzung: Verfügbarkeit vs. „Uptime“

„Uptime“ misst Betriebszeit eines Systems. Verfügbarkeit meint Nutzbarkeit für den beabsichtigten Zweck. Geplante Wartungsfenster, Abhängigkeiten und Datenkonsistenz (RPO) fließen in die Verfügbarkeitsbewertung ein.

FAQ

Was bedeutet Verfügbarkeit im ISMS-Kontext?
Verfügbarkeit ist die Fähigkeit, Informationen und Dienste zum benötigten Zeitpunkt bereitzustellen. Sie wird aus Geschäftsanforderungen abgeleitet, in Kennzahlen messbar gemacht und durch technische sowie organisatorische Maßnahmen erreicht. Sie umfasst nicht nur IT-Systeme, sondern auch Personal, Gebäudeinfrastruktur und Lieferanten.

Wie wird Verfügbarkeit nachgewiesen oder dokumentiert?
Nachweise umfassen Anforderungsdokumente (RTO/RPO, SLAs), Risikobehandlung, SoA, Betriebs- und Notfallhandbücher, Monitoring-Reports, Incident-/Problem-Tickets sowie Protokolle von Restore-, Failover- und Notfallübungen. Für ausgelagerte Leistungen dienen Lieferantenreports und Service-Reviews als Nachweis.

Wie hängt Verfügbarkeit mit Risiko zusammen?
Verfügbarkeit ist von Bedrohungen wie Hardwaredefekten, Angriffen, Fehlkonfigurationen oder Lieferantenausfällen betroffen. In der Risikobeurteilung werden Eintrittswahrscheinlichkeiten und Auswirkungen bewertet; daraus resultieren Maßnahmen wie Redundanz, Patching, Härtung, Backup/Recovery und organisatorische Regelungen, die das Restrisiko auf akzeptables Niveau senken.

Welche Kennzahlen sind üblich?
Typisch sind Uptime in Prozent, Mean Time to Detect (MTTD), Mean Time to Restore/Repair (MTTR), Anzahl und Dauer von Incidents, Erfolgsquote von Restore-Tests, Einhaltung von RTO/RPO sowie Verfügbarkeits-SLIs/SLOs. Wartungsfenster und geplante Downtime werden getrennt ausgewiesen.

Wie werden RTO und RPO bestimmt?
Aus der Kritikalität der Geschäftsprozesse (BIA) und regulatorischen/vertraglichen Anforderungen. RTO richtet sich nach tolerierbarer Unterbrechungsdauer, RPO nach akzeptablem Datenverlust. Technik folgt dem Bedarf: erst Zielwerte festlegen, dann passende Maßnahmen und Architekturen auswählen.

Welche Rolle spielen Cloud- und Lieferantenbeziehungen?
Externe Services sind oft verfügbarkeitskritisch. Anforderungen sollten vertraglich fixiert werden (SLAs, Supportzeiten, Eskalationen), ergänzt um Reporting, Audit-Rechte und Exit-Szenarien. Multi-Region-Optionen, Replikation und Provider-Resilienz erhöhen Verfügbarkeit, erfordern jedoch Kosten-Nutzen-Abwägung.

Wie oft sollten Tests stattfinden?
Mindestens jährlich für Notfall- und Wiederherstellungsübungen, häufiger für Backups/Restores und automatisierte Failover-Tests. Nach wesentlichen Änderungen (z. B. Plattformwechsel, neue kritische Schnittstellen) sind zusätzliche Tests sinnvoll, um Annahmen zu verifizieren.