Beispieldokument: Diese Regelung beschreibt den Sollprozess für die fiktive „Muster GmbH“. Reale Sicherungsumfänge, Systeme, Datenmengen, Aufbewahrungsfristen, RTO/RPO, Backup-Architekturen, Berechtigungen, Schlüssel, Dienstleister, Sicherungsläufe und Restore-Ergebnisse sind noch nicht vollständig erfasst oder bestätigt. Die Seite allein belegt keine funktionsfähige Datensicherung oder Wiederherstellung.
Nachweisregel: Ein erfolgreicher Backup-Job, ein vorhandener Snapshot oder die Anzeige „geschützt“ belegt nicht, dass Daten vollständig, unverändert, rechtzeitig und innerhalb bestätigter Ziele wiederhergestellt werden können. Restore, Konsistenz, Sicherheitszustand, Schnittstellen und fachliche Verwendbarkeit müssen angemessen praktisch geprüft werden.
TISAX-Hinweis: Die Kontrollfragen zur Betriebssicherheit sind Bestandteil der 46 Informationssicherheitsfragen. Alle 46 Fragen werden umgesetzt und bewertet; eine individuelle Auswahl „anwendbar/nicht anwendbar“ wie in der Statement of Applicability ist nicht vorgesehen. Diese Spezialregelung unterstützt mehrere Kontrollfragen, ersetzt aber nicht deren einzelne Bewertung in der VDA-ISA-Selbsteinschätzung.
| Feld | Wert |
|---|---|
| Dokumenten-ID | ISMS-MA-04-06 |
| Dokumentenart | Regelung / Datensicherung und Wiederherstellung |
| Wiki.js-Pfad | /ISMS/04-Sicherheitsregelungen/Datensicherung-und-Wiederherstellung |
| Verantwortlich | IT-Leitung |
| Fachlich geprüft durch | ISMS-Beauftragte/r, IT-/OT-Betrieb, BCM, Datenschutz, betroffene Prozess-, Service-, System- und Information Owner |
| Freigabe durch | Geschäftsführung |
| Status | Entwurf – Sicherungsabdeckung, Trennung und Restore-Wirksamkeit nicht bestätigt |
| Version | 0.1 |
| Stand | 23.07.2026 |
| Gültig ab | Nach Freigabe |
| Nächste Prüfung | Spätestens zwölf Monate nach Freigabe sowie anlassbezogen |
| Schutzklasse | Intern; Sicherungsarchitektur, Zugangsdaten, Schlüssel und Wiederherstellungsdetails Vertraulich bis Streng vertraulich |
| ISO-Bezug | ISO/IEC 27001:2022, insbesondere Annex A 5.29, A 5.30, A 8.13 und A 8.14; ergänzend A 5.23, A 8.15, A 8.16 und A 8.24 |
| VDA-ISA-Bezug | ISA 6.0.3, insbesondere Kapitel 5.2 Betriebssicherheit; Schnittstellen zu 1.3, 1.4, 1.5, 1.6, 5.1 und 6.1 |
Diese Regelung legt fest, wie Informationen, Konfigurationen, Anwendungen und weitere Wiederherstellungsquellen risikobasiert gesichert, geschützt, überwacht, aufbewahrt, zurückgesichert und auf Wirksamkeit geprüft werden.
Sie soll insbesondere sicherstellen, dass:
Die Regelung gilt für:
Der konkrete Umfang wird mit Geltungsbereich und Standorte, Asset-Inventar, Informationsklassifizierung, Notfallvorsorge und BCM und Wiederanlaufplanung abgeglichen.
| Begriff | Bedeutung in dieser Regelung |
|---|---|
| Backup/Datensicherung | Zusätzliche, kontrollierte Kopie von Daten oder Wiederherstellungsinformationen |
| Restore | Rücksicherung von Daten, Konfigurationen oder Systemständen aus einer Sicherung |
| Recovery/Wiederherstellung | Wiederherstellen eines nutzbaren, sicheren und freigegebenen Zustands |
| Wiederanlauf | Geordnete Wiederaufnahme eines Dienstes oder Prozesses einschließlich Abhängigkeiten und Freigaben |
| RPO | Ziel für den maximal tolerierbaren Datenverlust, ausgedrückt als Wiederherstellungspunkt |
| RTO | Zielzeit, innerhalb derer eine Aktivität, Ressource oder Leistung wieder verfügbar sein soll |
| Aufbewahrungszeit | Zeitraum, in dem ein Sicherungsstand verfügbar und geschützt gehalten wird |
| Version | Eindeutig identifizierbarer Sicherungsstand |
| Immutable/unveränderbar | Innerhalb festgelegter Bedingungen nicht änder- oder löschbarer Sicherungsstand |
| Offline | Nach Erstellung nicht dauerhaft über die normale Produktivumgebung erreichbar |
| Air Gap | Technische oder organisatorische Trennung, die unmittelbaren Zugriff aus der Produktivumgebung verhindert |
| Clean Recovery | Wiederherstellung in einer als vertrauenswürdig geprüften beziehungsweise neu aufgebauten Umgebung |
| Full/Incremental/Differential | Vollständige, inkrementelle oder differenzielle Sicherungsmethode |
| Snapshot | Zustandsaufnahme eines Systems oder Speichers zu einem bestimmten Zeitpunkt |
| Replikation | Übertragung beziehungsweise Spiegelung von Daten in ein anderes System oder einen anderen Standort |
| Rolle | Verantwortung |
|---|---|
| Geschäftsführung | Ressourcen, wesentliche Restrisiken, Abweichungen und Wiederherstellungsprioritäten entscheiden |
| IT-Leitung | Sicherungsstrategie, Architektur, Werkzeuge, Verfahren, Ressourcen und Berichterstattung verantworten |
| BCM-/Notfallverantwortung | BIA, MTPD, RTO, RPO, Mindestbetriebsniveau, Tests und Wiederanlauf abstimmen |
| Prozess Owner | Geschäftskritikalität, tolerierbaren Datenverlust und fachliche Wiederherstellungsanforderungen bestimmen |
| Information Owner | Schutzbedarf, Aufbewahrung, Löschung und fachliche Integrität der Informationen festlegen |
| Service Owner | Dienstumfang, Abhängigkeiten, RTO/RPO-Kompatibilität und Wiederanlaufabnahme verantworten |
| System-/Application Owner | technische Sicherungsobjekte, Verfahren, Konsistenz und Restore-Fähigkeit steuern |
| Backup-Administration | freigegebene Jobs, Medien, Kataloge, Überwachung, Restore und technische Nachweise betreiben |
| IT-/OT-Betrieb | Systeme anbinden, Fehler behandeln, Konfigurationen sichern und Wiederherstellungen unterstützen |
| Informationssicherheitsfunktion | Schutzarchitektur, Angriffsresilienz, Ausnahmen, Kontrollen und Cyber-Recovery prüfen |
| Datenschutz | Personenbezug, Löschung, Aufbewahrung, Testdaten und Datenschutzvorfälle beraten |
| Kryptografie-/Schlüsselverantwortung | Verschlüsselung, Schlüsseltrennung, Recovery und Widerruf steuern |
| Einkauf/Lieferantenmanagement | Backup-, Restore-, Standort-, Support-, Exit- und Nachweispflichten vertraglich steuern |
| Fachbereich | wiederhergestellte Daten und Funktionen fachlich prüfen und freigeben |
| Interne Revision/Audit | Prozess, Stichproben und Wirksamkeit angemessen unabhängig prüfen |
Die Person, die einen Sicherungsjob betreibt, bestätigt nicht ohne geeignete Gegenprüfung allein die vollständige End-to-End-Wiederherstellbarkeit eines kritischen Dienstes.
Für jedes Sicherungsobjekt werden mindestens berücksichtigt:
| Anforderung | Prüffrage |
|---|---|
| Schutzbedarf | Welche Vertraulichkeit, Integrität und Verfügbarkeit sind erforderlich? |
| Geschäftsbedarf | Welche Prozesse und Mindestleistungen hängen von den Daten ab? |
| RPO | Welcher Datenverlust ist fachlich und vertraglich höchstens tolerierbar? |
| RTO | Wie viel Zeit steht für Infrastruktur, Restore, Prüfung und Freigabe zur Verfügung? |
| Fehlererkennung | Wie lange kann eine Löschung, Manipulation oder Korruption unbemerkt bleiben? |
| Aufbewahrung | Welche Zeitstände werden betrieblich, rechtlich oder vertraglich benötigt? |
| Konsistenz | Welche Transaktionen, Datenbanken und Systemgruppen müssen zusammenpassen? |
| Wiederaufbau | Welche Software, Images, Konfigurationen, Lizenzen und Schlüssel werden benötigt? |
| Cyberbedrohung | Wie wird gleichzeitige Verschlüsselung, Löschung oder Kontenübernahme begrenzt? |
| Standorte/Provider | Welche regionalen, vertraglichen oder technischen Abhängigkeiten bestehen? |
| Datenschutz | Welche Lösch-, Berichtigungs-, Zugriffsschutz- und Testdatenanforderungen gelten? |
| Kunden/Prototypen | Welche besonderen Schutz-, Standort- oder Nachweisanforderungen gelten? |
RTO und RPO werden aus bestätigten Geschäftsanforderungen abgeleitet. Technische Möglichkeiten können die Zielsetzung beeinflussen, dürfen sie aber nicht ohne dokumentierte Managemententscheidung ersetzen.
| Feld | Mindestinhalt |
|---|---|
| Backup-ID | Eindeutige Kennung |
| Asset-/Service-ID | Verbindung zu Inventar und Wiederanlaufkatalog |
| Owner | Prozess-, Information-, Service- und technischer Owner |
| Sicherungsobjekt | Daten, Datenbank, VM, Konfiguration, Code, Schlüsselreferenz oder sonstige Quelle |
| Schutzbedarf | Klassifizierung und Sicherheitsanforderungen |
| RTO/RPO | Bestätigte Ziele oder offener Status |
| Methode | Full, inkrementell, differenziell, Snapshot, Export oder Kombination |
| Frequenz | Sicherungs- und gegebenenfalls Replikationsintervall |
| Ziel und Trennung | Speicherort, Konto, Zone, Region und Schutzmodell |
| Aufbewahrung | Versionen, Zeiträume und Löschregel |
| Verschlüsselung | Verfahren und Schlüsselverantwortung |
| Job/Tool | Technische Referenz |
| Monitoring | Alarm, Empfänger und Eskalation |
| Restore-Verfahren | Runbook und benötigte Abhängigkeiten |
| letzter Test | Datum, Umfang und Ergebnis |
| nächste Prüfung | Termin und Verantwortliche |
| Status | Aktiv, Lücke, in Änderung, ausgenommen oder außer Betrieb |
| Backup-ID | Asset/Service | Sicherungsobjekt | RPO | Methode/Frequenz | getrennte Option | letzter Restore-Test | Status |
|---|---|---|---|---|---|---|---|
| BAK-001 | Noch zu erfassen | Noch festzulegen | Nicht bestätigt | Nicht freigegeben | Nicht nachgewiesen | Nicht durchgeführt | Offen |
Der Beispieleintrag ist keine reale Systemfestlegung und kein Nachweis einer eingerichteten Sicherung.
Je System oder Dienst werden mindestens geprüft:
Nicht jedes Asset benötigt dieselbe Sicherungsmethode. Ein Ausschluss wird aber mit Datenfluss, Wiederaufbauweg, Owner, Risiko und Wiederherstellungsnachweis begründet.
| Verfahren | Nutzen | Zu prüfendes Risiko |
|---|---|---|
| Vollsicherung | vollständiger Stand in einem Sicherungssatz | Dauer, Kapazität und Aktualität |
| inkrementelle Sicherung | geringere Laufzeit und Datenmenge | Abhängigkeit von vollständiger Kette |
| differenzielle Sicherung | Restore mit Basissicherung und letztem Differenzial | wachsende Datenmenge |
| anwendungs-/datenbankkonsistente Sicherung | koordinierter konsistenter Stand | korrekte Integration und Logs |
| Snapshot | schneller lokaler Zustandspunkt | gleiche Plattform, Löschbarkeit und Abhängigkeit |
| Export | portable Daten- oder Konfigurationskopie | Vollständigkeit, Format, Schlüssel und Importfähigkeit |
| Image/Golden Image | schneller Systemneuaufbau | Aktualität, Vertrauenswürdigkeit und Hardware-/Plattformbindung |
| Replikation | kurze Umschalt- oder Datenübertragungszeit | Übertragung unerwünschter Änderungen |
| unveränderbare Kopie | Schutz gegen Änderung/Löschung innerhalb definierter Frist | Fehlkonfiguration, privilegierte Umgehung und falsche Daten |
| Offline-Kopie | verringerte Erreichbarkeit durch Angreifer | Aktualität, Transport, physischer Schutz und Wiederanbindung |
Die gewählte Kombination muss den vollständigen Wiederherstellungsweg tragen. Eine lange inkrementelle Kette wird beispielsweise auf Vollständigkeit, Abhängigkeiten und praktikable Restore-Zeit geprüft.
Die Architektur berücksichtigt risikobasiert:
| Prüffrage | Status Entwurf |
|---|---|
| Kann ein kompromittiertes Produktivkonto Sicherungen löschen oder verschlüsseln? | Nicht geprüft |
| Sind Backup- und Produktivadministration getrennt? | Nicht bestätigt |
| Besteht eine unveränderbare oder offline verfügbare Option? | Nicht nachgewiesen |
| Ist ein einzelner Standortausfall berücksichtigt? | Nicht geprüft |
| Sind Katalog, Schlüssel und Konfiguration separat wiederherstellbar? | Nicht getestet |
| Ist die Wiederherstellung ohne normale Domäne beziehungsweise Cloud-Identität möglich? | Nicht getestet |
Das verbreitete 3-2-1-Prinzip kann die Architekturplanung unterstützen. Die bloße Zählung von Kopien, Medien und Standorten beweist jedoch weder logische Trennung noch Integrität oder Wiederherstellbarkeit.
Mindestens werden geprüft:
Eine unveränderbare Sicherung schützt nicht automatisch vor bereits gesicherter Malware, unbemerkter Datenmanipulation, falscher Aufbewahrung oder fehlenden Schlüsseln.
Für Backup und Restore gelten:
Die Umsetzung wird mit Zugriff und Berechtigungen abgestimmt.
Sicherungsdaten werden entsprechend Schutzbedarf, Standort, Medium und Übertragungsweg verschlüsselt.
Dabei wird sichergestellt, dass:
Die Details werden über Kryptografie und Schlüssel gesteuert.
Je nach Risiko werden eingesetzt:
Ein Prüfsummenvergleich belegt die unveränderte Kopie des gesicherten Zustands, aber nicht, dass dieser Zustand fachlich richtig, vollständig oder frei von Schadsoftware war.
Die Sicherungsfrequenz wird aus RPO, Änderungshäufigkeit, Datenmenge, Fehlererkennungszeit, Betriebsfenster und technischen Abhängigkeiten abgeleitet.
| Objektklasse | RPO | Sicherungsmethode | Frequenz | Konsistenzpunkt | Verantwortlich | Status |
|---|---|---|---|---|---|---|
[Kritischer Dienst] |
[Bestätigter Wert] |
[Methode] |
[Aus RPO abgeleitet] |
[Verfahren] |
[Rolle] |
Offen |
Wenn die Dauer eines Sicherungslaufs das geplante Intervall überschreitet, Jobs dauerhaft kollidieren oder Änderungsraten die Kapazität übersteigen, wird die Architektur neu bewertet.
Aufbewahrung berücksichtigt:
| Sicherungsklasse | kurzfristige Stände | Langzeitstände | Rechts-/Vertragsgrund | Löschung | Status |
|---|---|---|---|---|---|
| Noch festzulegen | Nicht festgelegt | Nicht festgelegt | Nicht geprüft | Nicht definiert | Offen |
Pauschale Aufbewahrung „für immer“ ist ebenso zu vermeiden wie eine zu kurze Aufbewahrung, die erst spät erkannte Korruption nicht abdeckt.
Bei personenbezogenen und sonstigen löschpflichtigen Daten werden geregelt:
Ein Restore darf rechtmäßig gelöschte oder gesperrte Daten nicht unkontrolliert wieder produktiv verfügbar machen.
Neue oder geänderte Sicherungsjobs werden über IT-Betrieb und Änderungen gesteuert.
Vor Freigabe werden mindestens geprüft:
Änderungen an Retention, Löschschutz, Ausschlusslisten, Verschlüsselung, Zielen oder privilegierten Zugängen werden besonders geprüft.
Nach jedem vorgesehenen Lauf werden risikobasiert überwacht:
| Monitoringfeld | Soll | Ist | Abweichung | Ticket | Owner | Status |
|---|---|---|---|---|---|---|
| Noch festzulegen | Noch festzulegen | Nicht erhoben | Nicht bewertet | – | Noch zu benennen | Offen |
| Ereignis | Mindestreaktion |
|---|---|
| einzelner fehlgeschlagener Job | Ursache prüfen, erneut ausführen oder Risiko bewerten |
| mehrere fehlgeschlagene Läufe | Owner und IT-Leitung eskalieren; RPO-Auswirkung bestimmen |
| keine aktuelle getrennte Kopie | Schutzlücke sofort bewerten und Zwischenmaßnahme festlegen |
| Katalog- oder Repositoryfehler | Integrität, letzte nutzbare Stände und Wiederherstellbarkeit prüfen |
| Kapazitätsgrenze | Wachstum, Retention und Infrastruktur behandeln |
| ungewöhnliche Löschung/Änderung | Sicherheitsvorfall prüfen und Zugang begrenzen |
| Schlüssel oder Zugang nicht verfügbar | Recovery-Verfahren auslösen und Risiko eskalieren |
| Restore-Test fehlgeschlagen | Ursache, ähnliche Sicherungen und tatsächliche Notfallfähigkeit prüfen |
| Cloud-/Providerstatus unklar | Anbieter eskalieren und eigene Export-/Alternativfähigkeit bewerten |
Ein nachträglich erfolgreicher Job beseitigt nicht automatisch die zwischenzeitliche RPO-Verletzung oder die Ursache des Fehlers.
Geplant und überwacht werden:
Kapazität wird nicht nur für die Erstellung, sondern auch für parallele Wiederherstellungen und eine sichere Zielumgebung vorgesehen.
Ein Restore kann durch Fehler, Benutzeranforderung, Test, Vorfall oder Notfall ausgelöst werden.
| Restore-Feld | Mindestinhalt |
|---|---|
| Restore-ID | Eindeutige Referenz |
| Anlass | Fehler, Test, Vorfall, Notfall oder fachliche Anforderung |
| anfordernde und genehmigende Rolle | Berechtigung und Zweck |
| Quellobjekt | Asset, Daten, System oder Konfiguration |
| Zielumgebung | Original, Ersatz, Test oder Clean-Recovery |
| Recovery Point | ausgewählter Stand mit Begründung |
| Schutzbedarf | Zugriff, Übertragung, Testdaten und Löschung |
| Abhängigkeiten | Schlüssel, Anwendungen, Schnittstellen und Identitäten |
| Prüfkriterien | technische, sicherheitsbezogene und fachliche Ergebnisse |
| Rückfall/Bereinigung | Vorgehen bei Fehler sowie Löschung temporärer Kopien |
| Nachweis | Protokoll, Zeiten, Ergebnis, Abweichungen und Freigabe |
Ungeplante Restores in Produktivsysteme werden nicht ohne ausreichende Autorisierung und Prüfung durchgeführt.
| Prüfkriterium | Dokumentation |
|---|---|
| technisch verfügbarer Stand | [Zeitpunkt/Version] |
| erwartete Vollständigkeit | [Objekte, Kette, Katalog] |
| bestätigter vertrauenswürdiger Stand | [Prüfung/Unsicherheit] |
| Einhaltung des RPO | [Ja/Nein/Abweichung] |
| erwarteter Datenverlust | [Zeitraum und Datentypen] |
| Konsistenz mit abhängigen Systemen | [Prüfung/Abgleich] |
| notwendige Nacherfassung | [Verfahren und Owner] |
| rechtliche/fachliche Bindungen | [Aufbewahrung, Abschluss, Nachweis] |
| Auswahl und Freigabe | [Rolle, Zeitpunkt und Begründung] |
Der neueste Sicherungsstand ist nicht automatisch der beste Wiederherstellungspunkt, wenn Manipulation, Korruption oder Malware bereits enthalten sein können.
| Testart | Aussage | Grenze |
|---|---|---|
| Lesbarkeits-/Integritätstest | Sicherungsobjekt ist technisch lesbar beziehungsweise unverändert | keine vollständige Wiederherstellung |
| Datei-/Objekt-Restore | einzelnes Objekt kann zurückgesichert werden | keine Anwendungskonsistenz |
| Datenbank-Restore | Datenbank kann konsistent geöffnet und geprüft werden | abhängige Dienste fehlen möglicherweise |
| Konfigurations-Restore | Gerät oder Dienst kann rekonfiguriert werden | Hardware, Schlüssel und Schnittstellen können fehlen |
| System-Restore | System oder VM kann wiederhergestellt und gestartet werden | End-to-End-Geschäftsfunktion nicht belegt |
| Service-Restore | Dienst einschließlich wesentlicher Komponenten funktioniert | abhängige Geschäftsprozesse können fehlen |
| End-to-End-Wiederanlauf | technische und fachliche Leistung mit Abhängigkeiten wird geprüft | gilt nur für Scope und Szenario |
| Clean-Recovery-Test | Wiederaufbau in vertrauenswürdiger Umgebung nach Cyberlage | hoher Aufwand und besondere Vorbereitung |
| Provider-/Exit-Test | externe Daten und Konfigurationen können exportiert und verwendet werden | vollständiger Providerersatz eventuell nicht belegt |
Die Testfrequenz richtet sich nach Kritikalität, Änderungsrate, Technik, bisherigen Fehlern, Kundenanforderungen und Risiko.
| Test | Beispielrhythmus zur Freigabe | Auswahl |
|---|---|---|
| automatisierte Job- und Integritätskontrolle | nach jedem Lauf | alle vorgesehenen Jobs |
| Datei-/Objekt-Restore-Stichprobe | monatlich | wechselnde Systeme und Sicherungsklassen |
| Komponenten-/Datenbank-Restore | vierteljährlich bei kritischen Systemen | risikobasiert |
| vollständiger Service-Restore | mindestens jährlich oder nach wesentlicher Änderung | priorisierte kritische Services |
| End-to-End-Wiederanlauf | nach BCM-Testplan | Prozesse und kritische Abhängigkeiten |
| Clean-Recovery-/Ransomware-Szenario | risikobasiert | besonders exponierte und kritische Dienste |
| Provider-Export und Wiederverwendung | risikobasiert und vor wesentlicher Bindung | kritische Cloud-/SaaS-Dienste |
Statushinweis: Die genannten Intervalle sind fiktive Beispielwerte, keine pauschalen Vorgaben aus ISO/IEC 27001 oder TISAX und noch nicht von der Muster GmbH freigegeben. Der reale Testplan wird aus bestätigtem Risiko und Geschäftsbedarf abgeleitet.
| Feld | Eintrag |
|---|---|
| Test-ID und Datum | [ID/Datum] |
| Anlass und Testart | [Plan/Änderung/Vorfall; Art] |
| Scope | [Daten/System/Service/Abhängigkeiten] |
| Quelle und Recovery Point | [Backup-ID/Version/Zeitpunkt] |
| Zielumgebung | [isoliert/Test/Ersatz/produktiv] |
| bestätigtes RTO/RPO | [Werte oder offen] |
| Start-/Endzeit | [Zeitpunkte] |
| gemessene Wiederherstellungszeit | [Dauer] |
| tatsächlicher Datenstand | [Zeitpunkt/Datenverlust] |
| Integritätsprüfung | [Methode/Ergebnis] |
| Sicherheitsprüfung | [Methode/Ergebnis] |
| technische Funktion | [Kriterien/Ergebnis] |
| Schnittstellen | [Kriterien/Ergebnis] |
| fachliche Abnahme | [Rolle/Kriterien/Ergebnis] |
| Abweichungen | [Feststellungen] |
| Bereinigung der Testdaten | [Nachweis] |
| Entscheidung | [bestanden/teilweise/nicht bestanden] |
| Maßnahmen und Wiederholung | [Owner/Termin] |
| Freigabe/Nachweis | [Rolle/Referenz] |
Ein Test wird nicht allein deshalb als bestanden bewertet, weil Daten kopiert oder ein System gestartet werden konnte.
Die gemessene Wiederherstellungszeit umfasst bei einem vollständigen Service mindestens:
Das RPO wird anhand des tatsächlich wiederhergestellten Datenstands und notwendiger Nacherfassung bewertet, nicht allein anhand des geplanten Sicherungsintervalls.
| Bewertung | Ergebnis |
|---|---|
| bestätigtes RTO | Nicht freigegeben |
| gemessene End-to-End-Zeit | Nicht erhoben |
| bestätigtes RPO | Nicht freigegeben |
| tatsächlich wiederhergestellter Datenstand | Nicht erhoben |
| fachliche Nutzbarkeit | Nicht geprüft |
| Zielerreichung | Nicht bewertbar |
Nach Cyberangriff oder Kompromittierungsverdacht gelten zusätzlich:
Das bloße Einspielen eines Backups beendet keinen Cybervorfall. Eine kompromittierte Identität oder Anwendung kann die wiederhergestellte Umgebung erneut gefährden.
Für externe Dienste wird geklärt:
Native Providerfunktionen oder Versionierung werden nicht ungeprüft als vollständiges Backup übernommen. Eigene Sicherungen oder Exporte werden risikobasiert geprüft.
Zusätzlich werden berücksichtigt:
Ein Export der Steuerungskonfiguration ohne passende Engineering-Umgebung, Lizenz, Firmware oder Hardware ist kein vollständiger Wiederherstellungsnachweis.
Geschäftsrelevante Daten werden möglichst in zentral gesicherten Diensten gespeichert. Soweit lokale Daten erforderlich sind, werden:
Eine Dateisynchronisation allein ist kein Schutz vor versehentlicher Löschung oder Ransomware, wenn Änderungen ohne ausreichende Versionierung übernommen werden.
Bei Datenbanken und transaktionalen Anwendungen werden geprüft:
Ein technisch startender Datenbankdienst beweist nicht automatisch vollständige Transaktions- oder Geschäftsprozesskonsistenz.
Zusätzlich zu Daten werden risikobasiert gesichert:
Geheimnisse und private Schlüssel werden nur in dafür geeigneten, besonders geschützten Verfahren gesichert und nicht ungeschützt im Wiki, Quellcode oder allgemeinen Backup-Runbook hinterlegt.
Verträge und Leistungsbeschreibungen regeln risikobasiert:
Die Steuerung erfolgt mit Lieferanten und Dienstleister und dem Rechts- und Vertragskataster.
Sicherungs- und Restore-Ereignisse werden als möglicher Sicherheitsvorfall geprüft, wenn beispielsweise:
Es gelten Meldeweg für Sicherheitsvorfälle, Incident Response und Wiederanlaufplanung.
Für Sicherungsmedien und -systeme werden geregelt:
Die Außerbetriebnahme eines Quellsystems wird erst abgeschlossen, wenn erforderliche Aufbewahrung, Wiederherstellbarkeit, Datenmigration, Rechtsanforderungen und sichere Löschung geklärt sind.
Mindestens aufbewahrt werden, soweit relevant:
Konkrete Zugangsdaten, private Schlüssel, vollständige Netzdetails und besonders sensible Recovery-Informationen werden nicht ungeschützt im Wiki abgelegt. Das Wiki enthält Referenzen auf geschützte, auch im Notfall erreichbare Ablagen.
| Kennzahl | Berechnung/Interpretation |
|---|---|
| Sicherungsabdeckung | ausreichend gesicherte relevante Assets / bestätigte backup-pflichtige Assets |
| erfolgreiche Jobs | erfolgreiche vorgesehene Läufe / fällige Läufe |
| RPO-Verletzungen | Zeiträume oder Systeme ohne ausreichenden Wiederherstellungspunkt |
| getrennte Sicherungsabdeckung | relevante Assets mit geprüfter getrennter Option / hierfür vorgesehene Assets |
| Restore-Testabdeckung | gemäß Testplan geprüfte Assets/Services / fällige Assets/Services |
| Restore-Erfolgsquote | vollständig bestandene Tests / durchgeführte Tests |
| RTO-Erreichung | vollständige Tests innerhalb bestätigter RTO / bewertbare Tests |
| RPO-Erreichung | Tests mit Datenstand innerhalb bestätigter RPO / bewertbare Tests |
| offene kritische Fehler | nicht behobene Sicherungs- und Restore-Abweichungen |
| Alter letzter erfolgreicher Test | Zeit seit letztem geeignetem Restore-/Service-Test |
| EOL-/Kapazitätsrisiken | offene Risiken zu Support, Medien, Speicher und Durchsatz |
| Kennzahl | Stand Entwurf |
|---|---|
| bestätigte backup-pflichtige Assets | Nicht vollständig erfasst |
| Sicherungsabdeckung | Nicht berechenbar |
| getrennte Sicherungsabdeckung | Nicht nachgewiesen |
| erfolgreiche Jobs | Nicht organisationsweit erhoben |
| Restore-Testabdeckung | Nicht berechenbar |
| RTO-/RPO-Erreichung | Nicht bewertbar |
| offene kritische Fehler | Nicht vollständig erhoben |
Eine hohe Job-Erfolgsquote darf nicht als hohe Wiederherstellungsfähigkeit bezeichnet werden, wenn Scope, Vollständigkeit oder Restore-Tests fehlen.
Die Regelung behandelt insbesondere:
RIS-2026-002 – Ransomware beeinträchtigt ERP, Produktion und Dateidienste,RIS-2026-003 – Cloud-Dienstausfall unterbricht Kommunikation und Dokumentzugriff,RIS-2026-006 – Sicherungen sind unvollständig oder nicht wiederherstellbar,RIS-2026-009 – Standort- oder Versorgungsausfall,RIS-2026-011 – Geräteverlust und unvollständige Wiederherstellung.Das Beispielrisiko RIS-2026-006 und die Beispielmaßnahme M-006 bleiben offen, bis vollständige Restore-Protokolle, getrennte Wiederherstellungsoptionen sowie der Abgleich mit bestätigten RTO-/RPO-Zielen vorliegen.
Wesentliche Lücken werden im Risikoregister, Risikobehandlungsplan und gegebenenfalls über Ausnahmen und Risikoakzeptanzen gesteuert.
Diese Seite unterstützt insbesondere die Anforderungen an Sicherung, Wiederherstellung, Betriebssicherheit, Schutz von Informationen, externe Dienste und Nachweise.
Für TISAX gilt:
| TISAX-Prüfaspekt | Nachweisstatus |
|---|---|
| relevante Kontrollfragen einzeln bewertet | Nein; Kapitel 5.2: 0 von 9 |
| Sicherungsumfang und Verantwortungen bestätigt | Nicht vollständig |
| Schutz und Trennung nachgewiesen | Nein |
| Restore- und Wiederanlaufziele freigegeben | Nein |
| Restore-Tests erfolgreich durchgeführt | Nicht vollständig nachgewiesen |
| RTO/RPO praktisch bestätigt | Nein |
| Gesamtumfang Informationssicherheit | 0 von 46 Fragen bewertet |
Die Regelung unterstützt insbesondere Annex A 8.13 „Datensicherung von Informationen“ sowie verbundene Controls zu Kontinuität, Redundanz, Cloud-Diensten, Protokollierung und Kryptografie.
Die Statement of Applicability dokumentiert Anwendbarkeit, Begründung und Umsetzungsstatus der Annex-A-Controls. Sie ersetzt weder das Sicherungsregister noch die operativen Sicherungs- und Restore-Nachweise.
Die SoA-Logik wird nicht auf TISAX-Informationssicherheitsfragen übertragen:
| Kontrolle/Test | Prüfinhalt | Rhythmus | Status |
|---|---|---|---|
| Jobüberwachung | Erfolg, Fehler, Umfang, Dauer und Alter | nach jedem Lauf | Nicht organisationsweit belegt |
| Abdeckungsabgleich | Assetregister gegen Backupregister | regelmäßig und bei Änderung | Nicht durchgeführt |
| Berechtigungsreview | Admin-, Service-, Restore- und Lieferantenzugänge | risikobasiert | Nicht nachgewiesen |
| Retention-/Löschschutzprüfung | Aufbewahrung, Unveränderbarkeit und Löschrechte | risikobasiert | Nicht durchgeführt |
| Schlüssel-Recovery | Verfügbarkeit und Lesbarkeit verschlüsselter Sicherungen | nach Testplan | Nicht getestet |
| Objekt-Restore | Daten, Metadaten und Berechtigungen | nach freizugebendem Testplan | Nicht vollständig nachgewiesen |
| System-/Service-Restore | System, Daten, Sicherheit und Schnittstellen | nach Kritikalität | Nicht vollständig nachgewiesen |
| End-to-End-Wiederanlauf | Technik, Fachfunktion, RTO und RPO | nach BCM-Testplan | Nicht durchgeführt |
| Cyber-Recovery | vertrauenswürdige Quelle und sichere Zielumgebung | risikobasiert | Nicht getestet |
| Provider-/Exit-Test | Export, Vollständigkeit und Wiederverwendung | risikobasiert | Nicht durchgeführt |
Datensicherung und Wiederherstellung werden risikobasiert über das Auditprogramm und Interne Audits geprüft.
Geeignete Stichproben sind:
Ein positives Auditergebnis gilt nur für den dokumentierten Scope, Zeitraum und die geprüfte Stichprobe.
Mögliche Abweichungen sind:
Sie werden über Abweichungen und Korrekturmaßnahmen behandelt. Eine Abweichung gilt erst als wirksam geschlossen, wenn Ursache, vergleichbare Systeme, Umsetzung und erneute Prüfung angemessen berücksichtigt sind.
| Offener Punkt | Verantwortung | Status |
|---|---|---|
| reale backup-pflichtige Assets und Datenbestände erfassen | Asset-/Information Owner / IT | Offen |
| Schutzbedarf, BIA, RTO und RPO bestätigen | Prozess-/Service Owner / BCM | Offen |
| Sicherungs- und Wiederherstellungsregister vervollständigen | IT-Leitung / Backup-Administration | Offen |
| Architektur, Konten, Regionen und Abhängigkeiten dokumentieren | IT / Informationssicherheit | Offen |
| getrennte, unveränderbare oder offline verfügbare Option nachweisen | IT-Leitung | Offen |
| Berechtigungen, MFA, Notfallzugänge und Funktionstrennung prüfen | IT / Informationssicherheit | Offen |
| Verschlüsselungs- und Schlüssel-Recovery-Verfahren testen | Kryptografie-/Backup-Verantwortung | Offen |
| Frequenz, Aufbewahrung und Löschung freigeben | Owner / Recht / Datenschutz / IT | Offen |
| Monitoring, Fehlerbehandlung und Eskalation operationalisieren | Backup-Administration | Offen |
| Restore-Runbooks je kritischem System erstellen | System-/Application Owner | Offen |
| Testplan und Auswahlverfahren freigeben | IT / BCM / Fachbereiche | Offen |
| Komponenten-, Service- und End-to-End-Tests durchführen | IT / Fachbereiche / BCM | Offen |
| Clean-Recovery-Verfahren erproben | IT / Incident / Informationssicherheit | Offen |
| Cloud-, SaaS- und Lieferantennachweise bestätigen | Einkauf / Service Owner | Offen |
| RIS-2026-006 und M-006 mit realen Nachweisen bearbeiten | IT-Leitung | Offen |
| Kapitel 5.2 kontrollfragenbezogen bewerten | TISAX / IT / ISMS | Offen |
| Prüffrage | Status Entwurf |
|---|---|
| Sind relevante Assets, Daten, Owner und Abhängigkeiten vollständig? | Nein |
| Sind Schutzbedarf, RTO, RPO und Aufbewahrung bestätigt? | Nein |
| Ist die Sicherungsabdeckung mit belastbarem Nenner messbar? | Nein |
| Sind Snapshots, Replikation und Backup angemessen abgegrenzt? | Ja als Sollregel; Umsetzung nicht geprüft |
| Besteht mindestens eine angemessen getrennte Wiederherstellungsoption? | Nicht nachgewiesen |
| Sind Backup-Identitäten und Löschrechte besonders geschützt? | Nicht bestätigt |
| Sind Verschlüsselung und Schlüssel-Recovery praktisch getestet? | Nein |
| Werden Fehler, Auslassungen, Kapazität und RPO-Verletzungen eskaliert? | Nicht organisationsweit belegt |
| Sind Restore-Runbooks vollständig und erreichbar? | Nicht vollständig |
| Wurden Daten, Systeme, Schnittstellen und Fachfunktion getestet? | Nicht vollständig nachgewiesen |
| Sind RTO und RPO tatsächlich gemessen und erreicht? | Nein |
| Ist Clean Recovery nach Cybervorfällen vorbereitet? | Nicht getestet |
| Sind Cloud-, OT- und Lieferantenleistungen einbezogen? | Teilweise als Soll beschrieben |
| Sind alle neun Kontrollfragen aus Kapitel 5.2 bewertet? | Nein; 0 von 9 |
| Sind alle 46 Informationssicherheitsfragen berücksichtigt? | Ja als Sollumfang; 0 von 46 bewertet |
| Version | Datum | Änderung | Erstellt/geändert durch | Freigabe | Freigabedatum |
|---|---|---|---|---|---|
| 0.1 | 23.07.2026 | Regelung für Sicherungsumfang, Schutz, Überwachung, Restore, RTO/RPO und Wirksamkeitsprüfung angelegt | IT-Leitung / BCM / ISMS | Ausstehend | – |
| Funktion | Name | Entscheidung | Datum |
|---|---|---|---|
| Geschäftsführung | – | Ausstehend | – |
| IT-Leitung | – | Fachliche Prüfung ausstehend | – |
| BCM-/Notfallverantwortliche/r | – | RTO-/RPO- und Testschnittstelle ausstehend | – |
| ISMS-Beauftragte/r | – | Sicherheitsprüfung ausstehend | – |
| Datenschutz/Information Owner | – | Aufbewahrungs- und Schutzprüfung ausstehend | – |
Maßgeblich bleiben die lizenzierten Normtexte, die für das konkrete Assessment gültige offizielle ISA-Arbeitsmappe, der bestätigte TISAX Assessment Scope sowie die freigegebenen BIA-, Rechts-, Vertrags-, Kunden-, Datenschutz-, Hersteller-, Provider-, Betriebs- und Sicherheitsanforderungen.