Compliance-Lexikon · Grundbegriff
Availability
[əˌveɪləˈbɪlɪti] · auch: Verfuegbarkeit, Betriebsbereitschaft
Availability bezeichnet die Eigenschaft eines Systems, Dienstes oder einer Information, fuer autorisierte Benutzer zum erforderlichen Zeitpunkt zugreifbar und nutzbar zu sein – als drittes Element der CIA-Triad neben Confidentiality und Integrity.
Warum Availability ein Grundbegriff der IT-Compliance ist
Availability ist das am haeufigsten unterschaetzte Element der CIA-Triad. Waehrend Vertraulichkeit und Integritaet intuitive Schutzgueter sind, wird Verfuegbarkeit oft als Betriebsthema betrachtet – bis ein Ausfall eintritt und Regulatoren nach Massnahmen fragen. NIS-2 und DORA haben Verfuegbarkeit explizit in den Compliance-Rahmen gehoben: Wer kritische Dienste betreibt, muss Verfuegbarkeitsziele definieren und deren Einhaltung nachweisen.
Wo Availability gefordert wird
| Framework | Referenz | Anforderung |
|---|---|---|
| ISO 27001:2022 | A.8.6 / A.8.14 | Kapazitaetsmanagement und Redundanz: Systeme muessen so ausgelegt sein, dass Verfuegbarkeitsanforderungen erfuellt werden. |
| NIS-2 / BSIG | § 30 Abs. 2 | Business Continuity und Verfuegbarkeit kritischer Dienste als explizite Schutzanforderung fuer wesentliche Einrichtungen. |
| DORA | Art. 11 | Wiederherstellung kritischer IKT-Funktionen: RTO und RPO muessen definiert, dokumentiert und jaehrlich getestet werden. |
| BSI IT-Grundschutz | ORP.4 / CON.3 | Verfuegbarkeitsklassen und Datensicherung: Schutzbedarf nach Verfuegbarkeit klassifizieren und entsprechende Massnahmen ableiten. |
| ISO 22301 | vollstaendig | Business Continuity Management: Internationaler Standard fuer Verfuegbarkeit kritischer Geschaeftsprozesse. |
BAM-Objektreferenz
Haeufige Audit-Fehler
- RTO und RPO definiert, aber nie getestet
- Keine Verfuegbarkeitsklassen fuer verschiedene Systemkategorien
- Single Points of Failure nicht identifiziert und nicht adressiert
- Backups vorhanden, aber keine dokumentierten Wiederherstellungstests
RTO und RPO als operative Kernkennzahlen
Recovery Time Objective (RTO) definiert die maximale tolerierbare Ausfallzeit – wie lange ein System ausser Betrieb sein darf, bevor der Schaden inakzeptabel wird. Recovery Point Objective (RPO) definiert den maximalen Datenverlust – wie alt die zuletzt wiederherstellbare Datensicherung sein darf. Beide Werte muessen pro System differenziert festgelegt und jaehrlich durch Tests verifiziert werden. DORA Art. 11 und NIS-2 verlangen diesen Nachweis explizit. Wer RTO und RPO nur auf dem Papier hat, hat keine Verfuegbarkeitskontrolle.
Hoch- vs. Niedrig-Verfuegbarkeit: Was wann noetig ist
Nicht alle Systeme benoetigen maximale Verfuegbarkeit. Eine Schutzbedarfsfeststellung nach BSI IT-Grundschutz unterscheidet normale (Ausfall tolerierbar bis 72 Stunden), hohe (Ausfall tolerierbar bis 4 Stunden) und sehr hohe Verfuegbarkeit (Ausfall nicht tolerierbar – Redundanz und Failover erforderlich). Die Klassifizierung bestimmt die Architekturanforderungen: Redundante Systeme, geografisch verteilte Rechenzentren, automatische Failover-Mechanismen sind nur fuer die hoechste Stufe wirtschaftlich sinnvoll.
Naechste Ebene
Availability in der Praxis: RTO, RPO, Tests und Evidence
Wie Verfuegbarkeitsziele operativ umgesetzt und im Audit nachgewiesen werden.