ISO 27001 A.8.13: Backups und Wiederherstellungstests nachweisen

Drei Wochen vor dem Zertifizierungsaudit kommt die Stichprobe des Auditors: „Bitte zeigen Sie die Sicherung der Produktionsdatenbank vom 12. März und das Protokoll des letzten Wiederherstellungstests.“ Die Sicherung gibt es, der Zeitplan der Datenbank-Instanz macht sie jeden Tag. Der letzte Restore war während eines Vorfalls vor 14 Monaten, aufgeschrieben hat ihn niemand. Genau hier hakt es oft: nicht an fehlenden Backups, sondern an fehlenden Nachweisen.

ISO/IEC 27001:2022 A.8.13 „Information backup“ ist die Maßnahme aus Anhang A, nach der eine Organisation Sicherungen ihrer Informationen, Software und Systeme nach einer festgelegten Backup-Richtlinie anlegt, aufbewahrt und regelmäßig testet. Sie ist eine der 93 Maßnahmen der Ausgabe 2022; in der Ausgabe 2013 entsprach ihr A.12.3.1. Das wichtigste Wort darin ist „testet“.

Was verlangt ISO 27001 unter A.8.13?

Die Maßnahme selbst ist ein Satz. Die Umsetzungshinweise stehen in ISO/IEC 27002:2022 und laufen, sinngemäß zusammengefasst, auf diese Punkte hinaus:

• vollständige Aufzeichnungen, was gesichert wird, und dokumentierte Verfahren zur Wiederherstellung,
• Umfang und Häufigkeit nach dem Bedarf des Geschäfts – also danach, wie viel Datenverlust tragbar ist,
• Kopien an einem getrennten Ort, weit genug weg, dass ein Ereignis nicht Original und Kopie trifft,
• Schutz der Kopien: Zugriff, physischer Schutz, Verschlüsselung nach Risiko,
• regelmäßige Tests, ob die Wiederherstellung in der geplanten Zeit gelingt,
• Aufbewahrungsfristen und eine Überwachung, damit ein fehlgeschlagener Lauf auffällt,
• auch Daten bei Cloud-Diensten, die Sie nicht selbst betreiben.

Der Auditor prüft nicht, ob Sie ein bestimmtes Werkzeug benutzen, sondern ob Richtlinie und Wirklichkeit übereinstimmen – und ob Sie das belegen können.

Was gehört in eine Backup-Richtlinie?

Eine Seite reicht, wenn sie konkret ist. Pro System oder Datenart:

• Umfang: welche Datenbanken, Volumes, Buckets und Konfigurationen gesichert werden – und welche bewusst nicht, mit Begründung.
• Häufigkeit und Ziele: wie oft gesichert wird, wie viel Datenverlust tragbar ist (RPO) und wie schnell die Wiederherstellung stehen muss (RTO).
• Aufbewahrung: wie lange Kopien gehalten und wann sie gelöscht werden.
• Ort und Schutz: wo die Kopien liegen, getrennt wovon, wer Zugriff hat, ob sie gesperrt oder verschlüsselt sind.
• Tests: wie oft, mit welcher Methode, wer prüft und wo das Protokoll abgelegt wird.
• Verantwortung und Fehler: wer Alarme bekommt und was bei einem fehlgeschlagenen Lauf passiert.

Welche Nachweise will der Auditor sehen?

Typischerweise zieht der Auditor eine Stichprobe und lässt sich zeigen, dass die Richtlinie gelebt wird. Halten Sie bereit:

1. die freigegebene Backup-Richtlinie mit Version und Datum der letzten Prüfung,
2. eine Übersicht, welche Systeme wo gesichert werden, mit Region und Projekt,
3. die Historie der Sicherungsläufe im geprüften Zeitraum, mit Ergebnis,
4. Alarme zu fehlgeschlagenen Läufen und was daraufhin passiert ist,
5. die Protokolle der Wiederherstellungstests mit Ergebnis und Abweichungen,
6. Belege der Trennung: Konfiguration der Sperre, Rechte des Backup-Schlüssels, getrenntes Projekt,
7. das Audit-Log, wer Sicherungen heruntergeladen oder wiederhergestellt hat.

Für NIS2 sieht die Liste sehr ähnlich aus; welche Belege sich doppelt nutzen lassen, zeigt der Beitrag NIS2-Nachweise aus dem Betrieb.

Wie sieht ein Protokoll für einen Wiederherstellungstest aus?

Ein Test, der nicht aufgeschrieben ist, hat für das Audit nicht stattgefunden. Diese Felder reichen:

• Datum, durchführende Person, System und Umfang – eine Datenbank, ein Bucket, ein Volume,
• der verwendete Wiederherstellungspunkt: Kennung und Zeitpunkt der Sicherung,
• das Ziel: eine neue Datenbank oder ein neuer Bucket, nie die laufende Produktion,
• Start und Ende, gemessen am RTO, und das Alter der Daten, gemessen am RPO,
• die Prüfung: Zeilenzahlen, Prüfsummen, eine Anmeldung in der Anwendung gegen die Kopie,
• das Ergebnis, Abweichungen und Maßnahmen mit Verantwortlichen,
• das Aufräumen: die wiederhergestellte Kopie gelöscht, mit Datum.

Ein Rhythmus, den Sie halten, ist besser als ein ehrgeiziger, den Sie verpassen – etwa monatlich automatisch per Stichprobe und einmal im Quartal ein vollständiger Restore der wichtigsten Datenbank.

Datenbanken, Volumes, Object Storage: was heißt das in der Cloud?

• Datenbanken: Ein Snapshot der ganzen Managed-Database-Instanz ist schnell gemacht, sichert aber alles auf einmal; ein logisches Backup einer einzelnen Datenbank lässt sich gezielt herunterladen und prüfen. Getestet wird in eine neue Datenbank daneben.
• Volumes: Ein Block-Storage-Snapshot eines laufenden Dienstes ist absturzkonsistent – was die Anwendung noch im Speicher hatte, fehlt. Und er liegt in derselben Zone und demselben Projekt wie das Volume: eine Kopie, aber keine getrennte.
• Object Storage: Versionierung liegt im selben Bucket und ist deshalb kein getrenntes Backup. Getrennt ist erst eine gesperrte Kopie in einem anderen Projekt.
• Konfiguration: Helm-Werte, Umgebungsvariablen und Cluster-Einstellungen gehören zu „Software und Systemen“ – ohne sie dauert eine Wiederherstellung Tage statt Stunden.

Welche Sicherung für welche Daten passt, beschreibt die Seite Backups & Wiederherstellung.

Wie Clusterward die Nachweise liefert

Clusterward zertifiziert nichts und macht Sie nicht konform; es liefert Belege aus dem Betrieb. Die Seite Compliance im Cockpit zeigt Live-Prüfungen mit ihrer Annex-A-Maßnahme, unter A.8.13 drei: Bucket-Backups (kein gutes Backup seit 36 Stunden?), Restore-Tests (fehlgeschlagen oder in diesem Monat noch nicht getestet?) und, als Information, Datenbank-Backups. Nichts wird von Hand abgehakt; jede Prüfung liest, was gerade gespeichert ist.

Für den Auditor gibt es CSV-Berichte für einen wählbaren Zeitraum: Backup-Nachweise (jeder Lauf, jede Wiederherstellung, jeder Restore-Test mit Zeit, Ergebnis und Auslöser), ein Inventar, wo Ihre Daten liegen, das Audit-Log und die geltenden Sicherheitseinstellungen. Das Compliance-Paket bündelt die Berichte in einer ZIP-Datei mit SHA-256-Prüfsummen, und jeder Download steht selbst im Audit-Log. Bucket-Backups testet Clusterward jeden Monat automatisch per Stichprobe (S3-Backups). Datenbanken stellen Sie aus einem Backup in eine neue Datenbank wieder her, Volumes aus einem Snapshot mit einem Sicherheits-Snapshot vorher; diese Tests protokollieren Sie selbst, die Wiederherstellungen stehen im Audit-Log. BitKollegen GmbH, das Unternehmen hinter Clusterward, ist selbst nach ISO 27001 zertifiziert.

Fazit

A.8.13 prüft nicht, ob Sie Backups haben, sondern ob Sie zeigen können, dass sie laufen, getrennt liegen und sich zurückholen lassen. Eine konkrete Richtlinie, eine Laufhistorie, Alarme mit Reaktion und Testprotokolle mit Ergebnis decken die typische Stichprobe ab. Wer erst kurz vor dem Audit testet, testet unter Zeitdruck – und oft zum ersten Mal.

Steht Ihr nächstes ISO-27001-Audit an? Erzählen Sie uns, was Sie heute sichern und wie Sie es belegen. Wir zeigen, welche Nachweise Clusterward aus dem Betrieb liefert. Frage stellen →

Quellen und weiterführende Links

• ISO: ISO/IEC 27001:2022 (englisch)
• ISMS.online: Annex A 8.13 erklärt (englisch)
• High Table: Annex A 8.13 und das Audit (englisch)
• Wikipedia: ISO/IEC 27001 (englisch)
• Scaleway-Doku: Backups von Datenbank-Instanzen (englisch)