Kriterienkatalog · Backup und Disaster Recovery
Backup- und DR-Auswahl: die Kriterien, die unter NIS2 und DORA zählen
Die meisten Backup-Bewertungen prüfen Kapazität, Preis und ein grünes Dashboard. Unter NIS2 und DORA lautet die Frage anders: Kannst du wiederherstellen, nachdem ein Angreifer mit Admin-Rechten sein Schlimmstes getan hat, wie schnell, und kannst du es belegen?
Unabhängige Kriterienreferenz · 23 Kriterien · Stand August 2026 · Von keinem Anbieter gesponsert
Eine Backup-Entscheidung sieht aus wie eine Storage-Entscheidung. Unter NIS2 und DORA ist sie eine Resilienzentscheidung mit Nachweispflicht. Das Produkt mit der schönsten Konsole kann die falsche Wahl sein, wenn seine Kopien mit denselben Zugangsdaten gelöscht werden können, die der Angreifer schon hat, wenn niemand je daraus wiederhergestellt hat, wenn die Wiederherstellungszeit an einer Demo statt an deinen Daten gemessen wurde, oder wenn die Kopien unter einer Jurisdiktion liegen, die deine Aufsicht hinterfragen wird. Die Kriterien unten sind die, die DecisionOS für einen Backup- und DR-Fall auf den Bewertungsbogen setzt, in derselben Reihenfolge und Gruppierung, damit du hier prüfst, was du dort bewertest.
Backup-Fähigkeiten
Kriterium 01
RPO-Granularität (kleinstmögliches Intervall je Workload-Typ)
Warum es zählt
Das Recovery Point Objective ist, wie viel Arbeit du verlierst. Ein nächtlicher Job heißt ein voller Tag Transaktionen weg; eine Datenbank, die sich jede Sekunde ändert, braucht Minuten, nicht Stunden. Das Intervall, das ein Produkt wirklich durchhält, hängt vom Workload-Typ ab: Was bei einem Fileserver klappt, kann bei einer belasteten Datenbank oder einem SaaS-Postfach unmöglich sein, und die Marketingzahl ist der beste Fall über alle.
Was du fragst
Frag pro Workload-Typ in deinem Bestand nach dem kleinsten Backup-Intervall, das das Produkt im Produktivbetrieb durchhält, ohne die Quelle zu bremsen, wie es Änderungen zwischen Vollsicherungen erfasst, und ob die Anwendungskonsistenz bei diesem Intervall erhalten bleibt.
Die Falle
"RPO im Minutenbereich" gilt für snapshotfähige virtuelle Maschinen. Die Datenbank mit fachlicher Fünf-Minuten-Anforderung und die SaaS-Plattform, die alle 24 Stunden abgefragt wird, sind der Ort, an dem die echte RPO steht. Frag nach dem Intervall pro Quelle, nicht pro Produkt.
Kriterium 02
RTO im Skalierungsbetrieb (Restore-Durchsatz, parallele Recovery-Streams)
Warum es zählt
Die Wiederherstellungszeit skaliert mit Datenvolumen, Netzdurchsatz und der Zahl der Systeme, die parallel zurückkommen müssen. Eine Demo stellt eine kleine virtuelle Maschine in Minuten wieder her. Deine Tier-1-Systeme sind Terabytes mit Abhängigkeiten, und fünfzig davon stehen hinter einer Appliance Schlange. DORA erwartet Wiederherstellungsziele, die das Unternehmen tatsächlich einhalten kann, also an deinem Maßstab gemessen, nicht auf einer Folie.
Was du fragst
Lass den Vendor im Proof of Concept einen repräsentativen Workload in deiner echten Größe über deine echte Anbindung wiederherstellen und die Zeit protokollieren. Frag nach dem Restore-Durchsatz pro Stream, der Zahl paralleler Recovery-Streams und der Zeit bis zum ersten nutzbaren System gegenüber dem gesamten Bestand.
Die Falle
Die RTO im Angebot gilt pro Workload und unter Idealbedingungen. Niemand rechnet die Warteschlange zusammen: fünfzig Systeme nacheinander über eine Appliance ergeben eine ganz andere Zahl als die auf der Folie.
Kriterium 03
Unveränderliches Backup & Air-Gap-Architektur (Ransomware-Resilienz)
Warum es zählt
Moderne Ransomware-Gruppen verschlüsseln nicht zuerst die Produktion. Sie suchen die Backup-Konsole, löschen oder verkürzen mit gestohlenen Admin-Zugangsdaten die Kopien und verschlüsseln erst danach. Ein Backup, das ein Administrator verkürzen, löschen oder überschreiben kann, ist nicht unveränderbar, und eine isolierte Kopie ist nur isoliert, wenn Weg, Zugangsdaten und die verwaltende Konsole außerhalb des Wirkungsradius einer Produktionskompromittierung liegen. NIS2 Artikel 21 nennt Backup-Management als Pflichtmaßnahme, und ein Backup, das der Angreifer löschen kann, erfüllt diesen Zweck nicht.
Was du fragst
Lass dir live zeigen, was passiert, wenn ein Nutzer mit der höchsten Rolle im Produkt die Aufbewahrung einer bestehenden unveränderbaren Kopie verkürzen oder sie löschen will, und wer das aufheben kann. Frag dann, welche Zugangsdaten aus welchem Verzeichnis die Air-Gap-Kopie erreichen, und was ausfallen muss, damit beide Kopien gleichzeitig verloren sind.
Die Falle
"Immutable Backups" heißt oft: unveränderbar, bis ein Admin die Richtlinie ändert, und genau das tut der Angreifer mit dem Admin-Konto. Und "air-gapped" steht für alles von der getrennten Tape-Library bis zum zweiten Bucket im selben Cloud-Konto hinter demselben Login. Echte Unveränderbarkeit wird unterhalb der Admin-Ebene erzwungen; ein echter Air Gap hat eine eigene Identitätsdomäne.
Kriterium 04
Breite der Workload-Abdeckung (VMs, Container, SaaS, Datenbanken, Bare Metal)
Warum es zählt
Ein Backup-Produkt, das einen deiner Workload-Typen nicht abdeckt, lässt diesen Typ ganz ohne Backup. Virtuelle Maschinen sind der einfache Fall; Datenbanken mit Anwendungskonsistenz, Container mit persistenten Volumes, physische Hosts und vor allem SaaS-Plattformen sind der Punkt, an dem die Abdeckung dünn wird. SaaS läuft unter geteilter Verantwortung: Der Anbieter hält den Dienst verfügbar, für deine Daten bist du zuständig, und ein gelöschtes Postfach oder ein kompromittiertes Konto kann Daten löschen, die der Anbieter nicht zurückbringen muss.
Was du fragst
Gib dem Vendor deinen Workload-Bestand (Hypervisoren, Datenbanken, Container-Plattformen, physische Hosts, SaaS-Anwendungen) und frag pro Typ, was nativ erfasst wird, mit welcher Konsistenz, und wie die granulare Wiederherstellung eines einzelnen Objekts funktioniert. Bei SaaS frag konkret, was pro Quelle erfasst wird: Mail, Dateien, Berechtigungen, Konfiguration, Chatverläufe.
Die Falle
"Das sichert der Cloud-Anbieter" ist die häufigste Annahme der ganzen Kategorie, und sie ist falsch: Papierkörbe und Versionsverläufe sind Komfortfunktionen mit Aufbewahrungsgrenzen. Und "unterstützt alle Workloads" heißt meist, dass es einen Agenten gibt; die Datenbank, die inkonsistent zurückkommt, und die letztes Jahr eingeführte SaaS-Quelle sind die Stellen zum Prüfen.
Kriterium 05
Storage-Effizienz (globale Deduplizierung + Kompressionsrate im Zielmaßstab)
Warum es zählt
Backup-Daten wachsen schneller als Produktionsdaten, weil die Aufbewahrung sie vervielfacht. Globale Deduplizierung und Kompression entscheiden, ob drei Jahre Kopien in den budgetierten Speicher passen oder in das Dreifache. Die vom Vendor genannte Rate wurde an einem günstigen Datenmix gemessen; verschlüsselte, komprimierte oder medienlastige Daten deduplizieren kaum, und eine im Kleinen gemessene Rate bricht im Großen oft ein.
Was du fragst
Frag nach der Deduplizierungs- und Kompressionsrate, gemessen im Proof of Concept an einer Stichprobe deiner eigenen Daten im Zielvolumen, ob Deduplizierung global über alle Quellen und Standorte greift oder pro Job, und was die Rate mit der Restore-Geschwindigkeit macht.
Die Falle
"Bis zu 50:1 Reduktion" ist ein Marketingmaximum aus einem Labor-Datensatz. Deine Rate ist die an deinen Daten gemessene, und der Unterschied zwischen 4:1 und 20:1 ist der Unterschied zwischen der angebotenen und der echten Speicherrechnung.
Recovery & DR-Tests
Kriterium 06
Automatisierter DR-Test & Recovery-Validierung (unterbrechungsfrei, geplant)
Warum es zählt
Ein Backup, aus dem nie wiederhergestellt wurde, ist eine Hoffnung. Stille Korruption, fehlende Anwendungskonsistenz, abgelaufene Schlüssel und vergessene Abhängigkeiten zeigen sich erst, wenn jemand tatsächlich wiederherstellt. DORA Artikel 11 erwartet, dass Pläne zur Geschäftsfortführung getestet werden, und NIS2 Artikel 21 erwartet wirksames Backup-Management, was sich bei einem ungetesteten Backup nicht belegen lässt. Tests, die die Produktion stören, werden nicht gefahren, also muss der Test unterbrechungsfrei und geplant laufen.
Was du fragst
Frag, wie das Produkt automatisierte Restore-Tests plant, ausführt und dokumentiert, ohne die Produktion zu berühren, was es über "die Datei ist zurück" hinaus prüft (Anwendung startet, Datenbank öffnet, Prüfsummen stimmen), und was ein Auditor als Nachweis der letzten erfolgreichen Vollwiederherstellung bekommt.
Die Falle
"Backup-Verifikation" heißt oft nur, dass die Backup-Datei lesbar ist, nicht dass der Workload startet. Der grüne Haken im Dashboard sagt, dass der Job durchgelaufen ist, nicht, dass du mit dem Ergebnis arbeiten könntest.
Kriterium 07
Standort- / cloud-übergreifende Replikation (async/sync, Failover-Automatisierung)
Warum es zählt
Eine Kopie im selben Gebäude, in derselben Cloud-Region oder im selben Konto teilt das Schicksal des Originals. Standort- oder cloud-übergreifende Replikation macht einen Standortverlust, einen Regionsausfall oder eine Kontoübernahme überlebbar. Ob synchron oder asynchron repliziert wird, entscheidet, wie viel du beim Failover verlierst, und ob das Failover automatisiert ist, entscheidet, ob es um drei Uhr nachts passiert oder nachdem jemand das Runbook gefunden hat.
Was du fragst
Frag, welche Replikationsmodi das Produkt zwischen deinen Standorten und Clouds unterstützt, mit welchem Verzug du bei deiner Änderungsrate rechnen musst, wie ein Failover ausgelöst und zurückgenommen wird, und was das Replikat vom Primärsystem trennt, damit eine Kompromittierung nicht mit den Daten mitrepliziert.
Die Falle
"Auf einen zweiten Standort repliziert" mit denselben Zugangsdaten, derselben Policy-Engine und derselben Aufbewahrung, sodass die Löschung, die der Angreifer an Standort eins auslöst, in Sekunden an Standort zwei ankommt. Replikation ist kein Backup; sie ist eine Kopie dessen, was gerade passiert ist.
Kriterium 08
Geschwindigkeit granularer Wiederherstellung (Datei, E-Mail-Objekt, DB-Tabelle, VM-Snapshot-Mount)
Warum es zählt
Die meisten Restores sind keine Katastrophen. Es sind eine gelöschte Datei, ein E-Mail-Objekt, eine verlorene Tabelle, eine virtuelle Maschine, die in zehn Minuten laufen muss. Wenn jeder kleine Restore ein ganzes Volume oder eine ganze Datenbank zurückholen muss, frisst die tägliche Wiederherstellung Betriebszeit, und der kleine Vorfall wird zum großen Ausfall. Das direkte Mounten eines Snapshots als laufendes System macht granulare Wiederherstellung schnell.
Was du fragst
Lass in der Demo eine einzelne Datei, ein einzelnes E-Mail-Objekt, eine einzelne Datenbanktabelle und eine direkt aus dem Backup gemountete virtuelle Maschine wiederherstellen und stopp jede Zeit. Frag, welche davon vorher den ganzen Container brauchen.
Die Falle
"Granularer Restore", der zuerst die komplette 2-TB-Datenbank in einen Staging-Bereich zurückholt und dich dann eine Tabelle auswählen lässt. Die Granularität ist echt, die Geschwindigkeit nicht. Stopp die Zeit bis zum Objekt, nicht bis zum Klick.
Kriterium 09
Ransomware-Recovery-Workflow (Identifikation sauberer Wiederherstellungspunkte, Staging-Isolation)
Warum es zählt
Nach einem Angriff kannst du nicht ins kompromittierte Netz zurückspielen, weil die Persistenz des Angreifers mitkommt, und nicht die jüngste Kopie nehmen, weil sie die Malware schon enthalten kann. Du musst den letzten sauberen Wiederherstellungspunkt finden und eine isolierte Umgebung haben, in die du zurückspielst, scannst, prüfst und erst dann verbindest. DORA Artikel 12 erwartet, dass die Wiederherstellung über Systeme läuft, die vom Quellsystem getrennt sind, und NIS2 Artikel 21 erwartet Krisenmanagement, das in der Praxis funktioniert, nicht auf dem Papier.
Was du fragst
Frag, wie das Produkt den letzten sauberen Wiederherstellungspunkt findet (Anomalieerkennung auf Backup-Daten, Indikator-Scans, Entropieanalyse), ob es die Wiederherstellung in eine isolierte Recovery-Umgebung unterstützt, wie es wiederhergestellte Daten vor der Wiederanbindung scannt, und ob du diese Umgebung selbst bauen und bezahlen musst.
Die Falle
"Ransomware-Schutz" im Datenblatt heißt meist, dass die Kopien unveränderbar sind. Das ist nötig, sagt dir aber nicht, welche Kopie sauber ist, und gibt dir keinen sauberen Ort zum Zurückspielen. Der Clean Room ist eine Betriebsfähigkeit, kein Feature zum Einschalten.
Kriterium 10
Failover-Orchestrierung & Runbook-Automatisierung
Warum es zählt
Eine Disaster Recovery sind Dutzende Systeme, die in der richtigen Reihenfolge zurückkommen müssen, mit den richtigen Netzeinstellungen, IP-Adressen und Abhängigkeiten. Steht diese Reihenfolge nur in jemandes Kopf oder in einem Dokument von vor zwei Jahren, dauert die Wiederherstellung Tage. Orchestrierung macht aus dem Runbook etwas, das das Produkt ausführt und testet, und sie ist der Unterschied zwischen der Wiederherstellungszeit für ein System und der für den gesamten Bestand.
Was du fragst
Frag, ob das Produkt Recovery-Pläne mit Bootreihenfolge, Abhängigkeiten, Netzwerk-Mapping und Post-Restore-Skripten definieren kann, ob diese Pläne planmäßig und ohne Störung der Produktion getestet werden können, und wie der Testbericht für einen Auditor aussieht.
Die Falle
"Orchestrierung", die eine Liste virtueller Maschinen in Reihenfolge wiederherstellt, während Netzumadressierung, Verzeichnisabhängigkeit und Datenbank-Startreihenfolge dem Bereitschafts-Engineer um drei Uhr nachts bleiben. Lass dir einen vollständigen Plan Ende zu Ende ausführen, nicht eine Liste.
Integration & Betrieb
Kriterium 11
Monitoring, Alerting & SLA-Reporting (Backup-Erfolgsquote, Trend)
Warum es zählt
Ein Backup-Job, der seit drei Wochen still fehlschlägt, fällt an dem Tag auf, an dem du ihn brauchst. Monitoring muss dir fehlgeschlagene und ausgelassene Jobs, sinkende Erfolgsquoten und wachsende Restore-Zeiten melden, bevor sie zählen, und der Bericht muss einem Auditor belegen, dass die Backup-Richtlinie über die Zeit tatsächlich eingehalten wurde. NIS2 und DORA verlangen beide Nachweise, und der Nachweis ist der Trend, nicht das heutige Dashboard.
Was du fragst
Frag, worauf das Produkt von Haus aus alarmiert (fehlgeschlagene Jobs, verpasste Fenster, Verstöße gegen die Unveränderbarkeit, auffällige Änderungsraten), wie Alarme deine Bereitschaft und dein SIEM erreichen, und was der Monatsbericht über Backup-Erfolgsquote sowie RPO- und RTO-Einhaltung pro Workload-Klasse im Zeitverlauf zeigt.
Die Falle
Ein Dashboard, das grün ist, weil fehlgeschlagene Jobs automatisch wiederholt werden und der letzte Versuch zählt, während der Workload seit einer Woche kein erfolgreiches Backup hat. Frag nach der Erfolgsquote pro geschütztem Objekt, nicht pro Joblauf.
Kriterium 12
Hybrid- & Multi-Cloud-Abdeckung (AWS, Azure, GCP, einheitliche On-Prem-Policy)
Warum es zählt
Die meisten Bestände sind hybrid: virtuelle Maschinen vor Ort, Workloads bei zwei Hyperscalern, SaaS obendrauf. Braucht jede Umgebung ihr eigenes Backup-Tool mit eigener Policy-Engine, kannst du keine einheitliche Aufbewahrungsrichtlinie über das Unternehmen belegen, und die zuletzt hinzugekommene Umgebung bekommt den schwächsten Schutz. Eine Richtlinie, einheitlich angewendet, macht die Compliance-Geschichte einfach.
Was du fragst
Frag, ob eine Richtliniendefinition aus einer Konsole auf On-Prem-, AWS-, Azure- und GCP-Workloads angewendet werden kann, was pro Cloud nativ gesichert wird (Instanzen, Managed Databases, Object Storage, Kubernetes), und wo die Kopien der Cloud-Workloads liegen, in derselben Cloud oder außerhalb.
Die Falle
"Multi-Cloud-Unterstützung", die eine eigene Appliance, einen eigenen Agenten und eine eigene Richtlinie pro Cloud bedeutet, zusammengehalten von einem Dashboard. Und Cloud-Backups im selben Konto wie der Workload, wo die Kontoübernahme, die die Produktion trifft, auch das Backup trifft.
Kriterium 13
Schlüsselverwaltung & Verschlüsselung (BYOK, HSM-Integration)
Warum es zählt
Backups sind die vollständigste Kopie deiner Organisation an einem Ort. DSGVO Artikel 32 erwartet angemessene technische Maßnahmen, und Verschlüsselung ist die naheliegende. Aber Verschlüsselung schützt dich nur, wenn der Vendor deine Kopien nicht ohne dich entschlüsseln kann, und sie hilft in der Wiederherstellung nur, wenn du die Schlüssel noch erreichst, nachdem dein Key-Management-System selbst Teil des Verlusts ist.
Was du fragst
Frag, wo Schlüssel erzeugt und gespeichert werden, ob du eigene Schlüssel oder ein eigenes HSM einbringen kannst, ob der Vendor oder sein Cloud-Anbieter deine Daten technisch entschlüsseln kann, und wie die Schlüsselwiederherstellung funktioniert, wenn das Key-Management-System ausgefallen ist.
Die Falle
"Verschlüsselt im Ruhezustand und bei der Übertragung" sagt nichts darüber, wer den Schlüssel hält. Hält ihn der Vendor, können der Vendor und jeder, der ihn dazu zwingen kann, deine Backups lesen. Und ein Schlüssel, der nur in der Umgebung liegt, die du gerade wiederherstellen willst, ist ein Aussperren mit Ansage.
Kriterium 14
Betriebsaufwand & FTE-Bedarf im Zielmaßstab
Warum es zählt
Jedes Backup-Produkt kostet Menschen. Richtlinien pflegen, Agenten aktualisieren, Speicher erweitern, fehlgeschlagenen Jobs nachlaufen, Restore-Anfragen bedienen. Im Kleinen ist das eine Nebenaufgabe; bei tausend Workloads ist es ein Team, und das Produkt, das Speicher spart, aber zwei zusätzliche Administratoren braucht, ist nicht billiger. Die Besetzung, die das Produkt in deinem Zielmaßstab braucht, gehört zu seinem Preis.
Was du fragst
Frag Referenzkunden deiner Größe, wie viele FTE die Plattform im Alltag betreiben, welche Aufgaben ihre Zeit dominieren, und wie viel von Richtlinienpflege, Agentenwartung und Kapazitätsplanung das Produkt automatisiert. Frag, was sich geändert hat, als sie ihren geschützten Bestand verdoppelt haben.
Die Falle
Der Proof of Concept mit 20 Workloads und einem Vendor-Engineer in der Leitung sagt nichts darüber, wie 2.000 Workloads mit dem eigenen Team laufen. Frag nach dem Betriebsaufwand im Maßstab, den du in Jahr drei erreichst, nicht im Maßstab des Piloten.
Kriterium 15
ITSM-Integration & Berücksichtigung von Change-Windows
Warum es zählt
Backups kollidieren mit Änderungen. Eine Vollsicherung während einer Datenbankmigration, eine Restore-Anfrage ohne Ticket, eine Aufbewahrungsänderung, die nicht im Change-Log steht: Jede ist eine kleine Lücke in der Nachweiskette, die ein Auditor findet. Die Integration in dein ITSM macht aus Restore-Anfragen Tickets mit Freigaben und lässt das Backup-System Change- und Wartungsfenster kennen, statt hineinzulaufen.
Was du fragst
Frag, ob Restore-Anfragen, fehlgeschlagene Jobs und Richtlinienänderungen als Tickets in deinem ITSM angelegt und verfolgt werden können, ob das Produkt Wartungs- und Change-Fenster lesen kann, um sie zu meiden oder darum herum zu planen, und ob Freigaben für destruktive Aktionen wie Aufbewahrungsänderungen über das Ticket erzwungen werden können.
Die Falle
"ITSM-Integration", die heißt: Eine E-Mail an ein Sammelpostfach erzeugt ein Ticket. Die interessante Richtung ist die andere: das Produkt weiß, dass ein System im Change-Fenster ist und dass eine Aufbewahrungsänderung ein freigegebenes Ticket braucht, bevor sie läuft.
Wirtschaftlichkeit & Compliance
Kriterium 16
TCO (3 Jahre inkl. Storage-Wachstum + Egress)
Warum es zählt
Backup-Daten wachsen schneller als Produktionsdaten, weil die Aufbewahrung sie vervielfacht, und die Speicherrechnung wächst mit. Die Dreijahreskosten sind die Lizenz plus der Speicher beim Volumen in Jahr drei, plus die unveränderbare Stufe, plus die isolierte Kopie, plus die Egress-Gebühren für den großen Restore, den du eines Tages fährst. Das billigste Angebot heute ist in Jahr drei oft der teuerste Vertrag.
Was du fragst
Bitte um ein Dreijahres-Kostenmodell auf Basis deiner eigenen Wachstumsrate und deiner geplanten Aufbewahrung, inklusive unveränderbarem und Archivspeicher, isolierter Kopie, SaaS-Quellen, Restore- und Egress-Gebühren und Support. Frag, was mit dem Preis passiert, wenn du die nächste Stufe überschreitest.
Die Falle
Cloud-Speicher für Backups wirkt pro Gigabyte billig, bis zum ersten großen Restore, wenn Abruf- und Egress-Gebühren auftauchen. Kalkulier die Katastrophe, nicht nur die ruhigen Monate.
Kriterium 17
DSGVO / Data Residency für Backup- & Replikatdaten
Warum es zählt
Wo die Kopien liegen, ist nur die halbe Frage. Die Steuerungsebene, die Jobs plant, Metadaten hält, Dateinamen katalogisiert und Restore-Befehle absetzt, ist oft ein globaler Dienst, auch wenn Kopien und Replikate in einer EU-Region liegen. Backups enthalten jeden personenbezogenen Datensatz, den du hast, also gelten DSGVO Artikel 28 und die Übermittlungsregeln für die Kopien, die Replikate, den Katalog und den Supportzugriff auf alle drei.
Was du fragst
Frag getrennt: Wo liegen Backup-Kopien und Replikate, wo läuft die Verwaltungsebene, wo liegt der Metadatenkatalog, und von wo kann der Vendor-Support auf eines davon zugreifen? Verlang den Auftragsverarbeitungsvertrag und die Antwort auf jede Frage im Vertrag, nicht auf einer Folie.
Die Falle
"EU-Rechenzentrum" meint in der Regel die Speicherung der Kopien. Die Konsole, in der du dich anmeldest, der Katalog, der jeden Dateinamen deines Bestands kennt, und das Supportteam mit Zugriff darauf können alle woanders sein.
Kriterium 18
Anbieterabhängigkeit (proprietäres Datenformat, Egress-Kosten beim Ausstieg)
Warum es zählt
Backups müssen so lange wiederherstellbar bleiben, wie deine Aufbewahrungspflichten laufen, und das kann Jahre nach dem Vendor-Wechsel sein. Liegen die Kopien in einem proprietären Format, das nur die Software des Vendors lesen kann, sind deine Exit-Kosten das ganze Aufbewahrungsfenster, nicht nur die Migration, und die Egress-Rechnung für Petabytes ist das zweite Schloss. DORA Artikel 28 erwartet Exit-Strategien für IKT-Dienste, die wichtige Funktionen stützen; Backup ist einer davon.
Was du fragst
Frag, ob historische Backups ohne aktive Lizenz gelesen und wiederhergestellt werden können, in welchem Format sie exportiert werden können, was der Auszug deines gesamten Datenbestands an Egress und Zeit kosten würde, und wozu sich der Vendor vertraglich bei Exit-Unterstützung, Datenrückgabe und Löschung verpflichtet.
Die Falle
"Offenes Format" heißt oft, dass der Container dokumentiert ist, nicht, dass außer der Vendor-Software in der Praxis irgendetwas daraus wiederherstellen kann. Lass dir einen Restore mit abgelaufener Lizenz zeigen.
Kriterium 19
Anbieter-Roadmap (ransomware-spezifische Funktionen, cloud-natives Backup)
Warum es zählt
Die Angriffe auf Backups ändern sich jedes Jahr, und mit ihnen die Workloads, die du schützen musst. Ein Vendor, dessen Roadmap sich um Dashboards dreht, während Angreifer Backup-Konsolen ins Visier nehmen, oder dessen cloud-native und SaaS-Abdeckung hinter dem herhinkt, was du einführst, ist in zwei Jahren das falsche Produkt, auch wenn es heute das richtige ist. Die Roadmap gehört zur Bewertung, weil der Vertrag drei Jahre läuft.
Was du fragst
Frag nach der Roadmap für ransomware-spezifische Fähigkeiten (Anomalieerkennung, Identifikation sauberer Wiederherstellungspunkte, isolierte Wiederherstellung, Unveränderbarkeit über alle Stufen) und für cloud-native und SaaS-Abdeckung, mit Terminen, und prüf, was die Roadmap der letzten zwei Jahre tatsächlich geliefert hat.
Die Falle
Eine Roadmap-Folie voller KI-Funktionen, und ein Workload-Typ, den du schon betreibst, der seit drei Quartalen "nächstes Quartal" kommt. Beurteil die Roadmap nach dem Gelieferten, nicht nach dem Angekündigten.
Kriterium 20
Vertragliches Recovery-SLA & Ransomware-Wiederherstellungsgarantie
Warum es zählt
Die im Piloten gemessenen Wiederherstellungszeiten sind dein Nachweis; was der Vendor schriftlich zusagt, ist dein Schutz. DORA erwartet Wiederherstellungsziele, die das Unternehmen einhalten kann, und eine Aufsicht wird fragen, was der Anbieter dir schuldet, wenn der Restore scheitert oder dreimal so lange dauert. Eine Ransomware-Wiederherstellungsgarantie mit Auszahlungsdeckel und einer Seite Ausschlüsse ist ein Marketinginstrument, keine Zusage.
Was du fragst
Bitte um die Vertragsklausel, die garantierte Wiederherstellungszeit und Wiederherstellungserfolg für deine Workload-Klassen definiert, die Bedingungen, die du dafür erfüllen musst, was der Vendor bei Verfehlung schuldet, und wie eine Ransomware-Garantie bei einem bestehenden Kunden tatsächlich ausgezahlt wurde.
Die Falle
"Wiederherstellung garantiert" mit einer Bedingungsliste, die eine Konfiguration voraussetzt, die niemand in der Praxis fährt, und einem Ausgleich, der bei einem Monat Abogebühr gedeckelt ist. Ist die Garantie weniger wert als der Ausfall, ist sie ein Rabatt, keine Garantie.
Preis
Kriterium 21
Passung des Preismodells (Kapazität vs. Workload vs. pro VM)
Warum es zählt
Backup-Lizenzen werden pro geschütztem Terabyte, pro Workload oder pro virtueller Maschine bepreist, und jedes Modell belohnt einen anderen Bestand. Kapazitätspreise bestrafen Wachstum und lange Aufbewahrung; Preise pro VM bestrafen viele kleine Systeme; Preise pro Workload sind nur günstig, wenn die Workload-Definition zu deiner passt. Das Modell, das beim heutigen Bestand am billigsten ist, ist beim Bestand in Jahr drei oft das teuerste.
Was du fragst
Bitte um dasselbe Angebot in jedem Preismodell, das der Vendor anbietet, gerechnet auf deinen heutigen Bestand und auf den in Jahr drei mit deinem Wachstum und deiner Aufbewahrung, und frag, in welches Modell du während der Laufzeit wechseln kannst und zu welchem Preis.
Die Falle
Ein Preis pro VM, der billig wirkt, bis sich herausstellt, dass Container-Plattform, SaaS-Quellen und Datenbanken separat pro geschütztem Terabyte lizenziert werden. Frag, was in deinem Bestand nicht von der Haupteinheit abgedeckt ist.
Kriterium 22
Preisplanbarkeit (Egress-Gebühren, Snapshot-Storage, Aufbewahrungsstufen)
Warum es zählt
Die Lizenz ist der planbare Teil einer Backup-Rechnung. Die unplanbaren Teile sind Egress-Gebühren beim Wiederherstellen oder Ausstieg, Snapshot-Speicher, der sich im Cloud-Konto außerhalb der Buchhaltung des Backup-Produkts ansammelt, und Aufbewahrungsstufen, deren Preis pro Gigabyte sich ändert, wenn Daten altern. Ein Budget, das nur die Lizenz enthält, ist im ersten Jahr falsch.
Was du fragst
Bitte um die vollständige Liste der nutzungsabhängigen Kosten jenseits der Lizenz: Egress und Abruf, Snapshot- und cloud-nativer Speicher, Archiv- und unveränderbare Stufen, regionsübergreifende Replikation, API-Aufrufe. Bitte um die Rechnung eines Referenzkunden deiner Größe der letzten zwölf Monate, Posten für Posten.
Die Falle
"All-inclusive-Abo" vom Backup-Vendor, und eine separate Cloud-Rechnung für Speicher, Snapshots und Egress, die das Produkt in deinem Konto verbraucht. Das Abo ist planbar; die Rechnung, die es woanders erzeugt, nicht.
Kriterium 23
Angebotener jährlicher Lizenzpreis (aktuelles Datenvolumen)
Warum es zählt
Der angebotene Jahrespreis beim aktuellen Datenvolumen ist die Zahl, die die Geschäftsführung vergleicht. Sie ist zwischen Vendoren nur vergleichbar, wenn jedes Angebot denselben Umfang abdeckt: dasselbe geschützte Volumen, dieselbe Aufbewahrung, dieselben unveränderbaren und isolierten Kopien, dieselben SaaS-Quellen und dasselbe Supportlevel. Ein Angebot, das 30 Prozent billiger ist, schützt meist 30 Prozent weniger.
Was du fragst
Bitte jeden Vendor um einen Jahrespreis auf einen identischen schriftlichen Umfang: aktuelles geschütztes Volumen pro Workload-Klasse, Aufbewahrung pro Klasse, unveränderbare und Air-Gap-Kopien, SaaS-Quellen, Supportstufe und Einführung. Frag, was in diesem Umfang optional ist und separat bepreist wird.
Die Falle
Das niedrigste Angebot lässt die isolierte Kopie, das SaaS-Modul und den Premium-Support weg, die alle nach Vertragsunterschrift als Zusatzmodule auftauchen. Vergleich die Umfänge, bevor du die Preise vergleichst.
Welche Pflicht welches Kriterium abdeckt
Die Regulatorik-Karte dieses Katalogs: die Pflicht, ihre Quelle und die Kriterien, die sie abdecken. Damit zeigst du dem Auditor, dass die Anforderungsliste aus den Regeln kommt, nicht aus einer Anbieterpräsentation.
Der Fragebogen
Alle Anbieterfragen dieses Katalogs in einer Liste, in der Reihenfolge der Kriterien. Stell jedem Anbieter dieselben Fragen im selben Wortlaut und schreib die Antworten nebeneinander.
- RPO-Granularität (kleinstmögliches Intervall je Workload-Typ)
Frag pro Workload-Typ in deinem Bestand nach dem kleinsten Backup-Intervall, das das Produkt im Produktivbetrieb durchhält, ohne die Quelle zu bremsen, wie es Änderungen zwischen Vollsicherungen erfasst, und ob die Anwendungskonsistenz bei diesem Intervall erhalten bleibt.
- RTO im Skalierungsbetrieb (Restore-Durchsatz, parallele Recovery-Streams)
Lass den Vendor im Proof of Concept einen repräsentativen Workload in deiner echten Größe über deine echte Anbindung wiederherstellen und die Zeit protokollieren. Frag nach dem Restore-Durchsatz pro Stream, der Zahl paralleler Recovery-Streams und der Zeit bis zum ersten nutzbaren System gegenüber dem gesamten Bestand.
- Unveränderliches Backup & Air-Gap-Architektur (Ransomware-Resilienz)
Lass dir live zeigen, was passiert, wenn ein Nutzer mit der höchsten Rolle im Produkt die Aufbewahrung einer bestehenden unveränderbaren Kopie verkürzen oder sie löschen will, und wer das aufheben kann. Frag dann, welche Zugangsdaten aus welchem Verzeichnis die Air-Gap-Kopie erreichen, und was ausfallen muss, damit beide Kopien gleichzeitig verloren sind.
- Breite der Workload-Abdeckung (VMs, Container, SaaS, Datenbanken, Bare Metal)
Gib dem Vendor deinen Workload-Bestand (Hypervisoren, Datenbanken, Container-Plattformen, physische Hosts, SaaS-Anwendungen) und frag pro Typ, was nativ erfasst wird, mit welcher Konsistenz, und wie die granulare Wiederherstellung eines einzelnen Objekts funktioniert. Bei SaaS frag konkret, was pro Quelle erfasst wird: Mail, Dateien, Berechtigungen, Konfiguration, Chatverläufe.
- Storage-Effizienz (globale Deduplizierung + Kompressionsrate im Zielmaßstab)
Frag nach der Deduplizierungs- und Kompressionsrate, gemessen im Proof of Concept an einer Stichprobe deiner eigenen Daten im Zielvolumen, ob Deduplizierung global über alle Quellen und Standorte greift oder pro Job, und was die Rate mit der Restore-Geschwindigkeit macht.
- Automatisierter DR-Test & Recovery-Validierung (unterbrechungsfrei, geplant)
Frag, wie das Produkt automatisierte Restore-Tests plant, ausführt und dokumentiert, ohne die Produktion zu berühren, was es über "die Datei ist zurück" hinaus prüft (Anwendung startet, Datenbank öffnet, Prüfsummen stimmen), und was ein Auditor als Nachweis der letzten erfolgreichen Vollwiederherstellung bekommt.
- Standort- / cloud-übergreifende Replikation (async/sync, Failover-Automatisierung)
Frag, welche Replikationsmodi das Produkt zwischen deinen Standorten und Clouds unterstützt, mit welchem Verzug du bei deiner Änderungsrate rechnen musst, wie ein Failover ausgelöst und zurückgenommen wird, und was das Replikat vom Primärsystem trennt, damit eine Kompromittierung nicht mit den Daten mitrepliziert.
- Geschwindigkeit granularer Wiederherstellung (Datei, E-Mail-Objekt, DB-Tabelle, VM-Snapshot-Mount)
Lass in der Demo eine einzelne Datei, ein einzelnes E-Mail-Objekt, eine einzelne Datenbanktabelle und eine direkt aus dem Backup gemountete virtuelle Maschine wiederherstellen und stopp jede Zeit. Frag, welche davon vorher den ganzen Container brauchen.
- Ransomware-Recovery-Workflow (Identifikation sauberer Wiederherstellungspunkte, Staging-Isolation)
Frag, wie das Produkt den letzten sauberen Wiederherstellungspunkt findet (Anomalieerkennung auf Backup-Daten, Indikator-Scans, Entropieanalyse), ob es die Wiederherstellung in eine isolierte Recovery-Umgebung unterstützt, wie es wiederhergestellte Daten vor der Wiederanbindung scannt, und ob du diese Umgebung selbst bauen und bezahlen musst.
- Failover-Orchestrierung & Runbook-Automatisierung
Frag, ob das Produkt Recovery-Pläne mit Bootreihenfolge, Abhängigkeiten, Netzwerk-Mapping und Post-Restore-Skripten definieren kann, ob diese Pläne planmäßig und ohne Störung der Produktion getestet werden können, und wie der Testbericht für einen Auditor aussieht.
- Monitoring, Alerting & SLA-Reporting (Backup-Erfolgsquote, Trend)
Frag, worauf das Produkt von Haus aus alarmiert (fehlgeschlagene Jobs, verpasste Fenster, Verstöße gegen die Unveränderbarkeit, auffällige Änderungsraten), wie Alarme deine Bereitschaft und dein SIEM erreichen, und was der Monatsbericht über Backup-Erfolgsquote sowie RPO- und RTO-Einhaltung pro Workload-Klasse im Zeitverlauf zeigt.
- Hybrid- & Multi-Cloud-Abdeckung (AWS, Azure, GCP, einheitliche On-Prem-Policy)
Frag, ob eine Richtliniendefinition aus einer Konsole auf On-Prem-, AWS-, Azure- und GCP-Workloads angewendet werden kann, was pro Cloud nativ gesichert wird (Instanzen, Managed Databases, Object Storage, Kubernetes), und wo die Kopien der Cloud-Workloads liegen, in derselben Cloud oder außerhalb.
- Schlüsselverwaltung & Verschlüsselung (BYOK, HSM-Integration)
Frag, wo Schlüssel erzeugt und gespeichert werden, ob du eigene Schlüssel oder ein eigenes HSM einbringen kannst, ob der Vendor oder sein Cloud-Anbieter deine Daten technisch entschlüsseln kann, und wie die Schlüsselwiederherstellung funktioniert, wenn das Key-Management-System ausgefallen ist.
- Betriebsaufwand & FTE-Bedarf im Zielmaßstab
Frag Referenzkunden deiner Größe, wie viele FTE die Plattform im Alltag betreiben, welche Aufgaben ihre Zeit dominieren, und wie viel von Richtlinienpflege, Agentenwartung und Kapazitätsplanung das Produkt automatisiert. Frag, was sich geändert hat, als sie ihren geschützten Bestand verdoppelt haben.
- ITSM-Integration & Berücksichtigung von Change-Windows
Frag, ob Restore-Anfragen, fehlgeschlagene Jobs und Richtlinienänderungen als Tickets in deinem ITSM angelegt und verfolgt werden können, ob das Produkt Wartungs- und Change-Fenster lesen kann, um sie zu meiden oder darum herum zu planen, und ob Freigaben für destruktive Aktionen wie Aufbewahrungsänderungen über das Ticket erzwungen werden können.
- TCO (3 Jahre inkl. Storage-Wachstum + Egress)
Bitte um ein Dreijahres-Kostenmodell auf Basis deiner eigenen Wachstumsrate und deiner geplanten Aufbewahrung, inklusive unveränderbarem und Archivspeicher, isolierter Kopie, SaaS-Quellen, Restore- und Egress-Gebühren und Support. Frag, was mit dem Preis passiert, wenn du die nächste Stufe überschreitest.
- DSGVO / Data Residency für Backup- & Replikatdaten
Frag getrennt: Wo liegen Backup-Kopien und Replikate, wo läuft die Verwaltungsebene, wo liegt der Metadatenkatalog, und von wo kann der Vendor-Support auf eines davon zugreifen? Verlang den Auftragsverarbeitungsvertrag und die Antwort auf jede Frage im Vertrag, nicht auf einer Folie.
- Anbieterabhängigkeit (proprietäres Datenformat, Egress-Kosten beim Ausstieg)
Frag, ob historische Backups ohne aktive Lizenz gelesen und wiederhergestellt werden können, in welchem Format sie exportiert werden können, was der Auszug deines gesamten Datenbestands an Egress und Zeit kosten würde, und wozu sich der Vendor vertraglich bei Exit-Unterstützung, Datenrückgabe und Löschung verpflichtet.
- Anbieter-Roadmap (ransomware-spezifische Funktionen, cloud-natives Backup)
Frag nach der Roadmap für ransomware-spezifische Fähigkeiten (Anomalieerkennung, Identifikation sauberer Wiederherstellungspunkte, isolierte Wiederherstellung, Unveränderbarkeit über alle Stufen) und für cloud-native und SaaS-Abdeckung, mit Terminen, und prüf, was die Roadmap der letzten zwei Jahre tatsächlich geliefert hat.
- Vertragliches Recovery-SLA & Ransomware-Wiederherstellungsgarantie
Bitte um die Vertragsklausel, die garantierte Wiederherstellungszeit und Wiederherstellungserfolg für deine Workload-Klassen definiert, die Bedingungen, die du dafür erfüllen musst, was der Vendor bei Verfehlung schuldet, und wie eine Ransomware-Garantie bei einem bestehenden Kunden tatsächlich ausgezahlt wurde.
- Passung des Preismodells (Kapazität vs. Workload vs. pro VM)
Bitte um dasselbe Angebot in jedem Preismodell, das der Vendor anbietet, gerechnet auf deinen heutigen Bestand und auf den in Jahr drei mit deinem Wachstum und deiner Aufbewahrung, und frag, in welches Modell du während der Laufzeit wechseln kannst und zu welchem Preis.
- Preisplanbarkeit (Egress-Gebühren, Snapshot-Storage, Aufbewahrungsstufen)
Bitte um die vollständige Liste der nutzungsabhängigen Kosten jenseits der Lizenz: Egress und Abruf, Snapshot- und cloud-nativer Speicher, Archiv- und unveränderbare Stufen, regionsübergreifende Replikation, API-Aufrufe. Bitte um die Rechnung eines Referenzkunden deiner Größe der letzten zwölf Monate, Posten für Posten.
- Angebotener jährlicher Lizenzpreis (aktuelles Datenvolumen)
Bitte jeden Vendor um einen Jahrespreis auf einen identischen schriftlichen Umfang: aktuelles geschütztes Volumen pro Workload-Klasse, Aufbewahrung pro Klasse, unveränderbare und Air-Gap-Kopien, SaaS-Quellen, Supportstufe und Einführung. Frag, was in diesem Umfang optional ist und separat bepreist wird.
Diese Kriterien sind der Anfang. Nicht die Entscheidung.
Eine Kriterienliste sagt dir, worauf du schauen musst. Sie gewichtet die Kriterien nicht gegen deine Situation, prüft sie nicht gegen deine harten Grenzen und macht kein Memo daraus, das dein Vorstand und dein Auditor lesen können. DecisionOS nimmt diese Kriterien, gewichtet sie für deine Entscheidung und baut daraus eine belastbare Akte. In Tagen, nicht Monaten.
Weiter mit dem Entscheidungs-Guide
Verwandte Kriterienkataloge
- Souveräne Cloud und Cloud-PlattformenSouveräne Cloud: die Auswahlkriterien, die unter NIS2, DORA und DSGVO zählen23 Kriterien
- Endpoint Detection and ResponseEDR-Auswahl: die Kriterien, die unter NIS2 und DORA zählen23 Kriterien
- Managed Detection and ResponseMDR-Auswahl: die Kriterien, die unter NIS2 und DORA zählen23 Kriterien
Diesen Katalog drucken oder als PDF fürs Meeting sichern
